Los errores de la nube

Esta semana han estado todas las miradas puestas en el cielo. En España la mayoría pendientes del tiempo para hacer su estación de penitencia las cofradías de Semana Santa y en todo internet varios sercicios como FourSquare, Reddit, HootSuite han estado caídos por los errores que se han producido en la Cloud de Amazon. El popular blog de tecnología TechCrunch se hacía eco de esta noticia este mismo jueves y el New York Times publica la noticia ayer.

Amazon continua reportando el estado del problema que aún no parece resuelto. En http://status.aws.amazon.com se pueden ver los distintos informes sobre el estado del problema que Amazon ofrece. Los primeros indicios parecen apuntar a que el fallo ha sido debido a una copia de seguridad descontrolada de volúmenes EBS (Elastic Block Storage). El error sólo ha afectado a las zonas de una de las regiones de EEUU, N. Virginia, estando completamente operativa las regiones de N. California y las de Europa y Asia.

La fiabilidad y la madurez de los sistemas de Cloud Computing ha sido puesta en entredicho. En los blogs y sobre todo en la red social Twitter se está discutiendo sobre este fallo y se pueden apreciar las diferentes posturas al respecto.

Mientas unos usuarios protestan por el fallo y se cuestionan si los servicios de Cloud Computing aún no son lo suficientemente estables para sus servicios, otros admiten el fallo como normal dentro del SLA (Service Level Agreement) y demuestran cómo los errores son más fácil de solventar en la Cloud.

En mi opinión, aunque el SLA pueda garantizar un alto nivel de disponibilidad del servicio, siempre existirá una posibilidad de fallo. Cualquier sistema de Hosting tradicional también es propenso a errores al igual que la Cloud.

La ventaja es que con la Cloud de Amazon es muy simple la migración a otra región, la copia de seguridad y la restauración de la aplicación. Lo que realmente permite la Cloud es diseñar la arquitectura de tu aplicación. Los administradores de sistemas en la Cloud son ahora arquitectos, del “cacharreo” con los sitemas físicos se pasa al diseño de la arquitectura, a los sistemas de monitorización y políticas de prevención contra errores. Es muy curioso el post de Ricardo Galli acerca del diseño de la infraestructura usando la Cloud de Amazon para la migración del portal meneame.net.

Según Amazon: “El compromiso del contrato a nivel de servicio de Amazon EC2 es de una disponibilidad del 99,95% en cada Región de Amazon EC2.” Ese 0,05% del tiempo indisponible puede ser insignificante para nuestro servicio (por ejemplo un blog) o de impacto mínimo si las copias de seguridad las podemos restaurar en minutos en una región diferente.

Este fallo de la Cloud ha resucitado de nuevo la discusión entre si se debe utilizar sólo la Cloud pública, en el cual se paga por los recursos que se estén usando, o diseñar una sistema mixto de Cloud pública y privada, en el cual podemos hacer uso también de servidores internos. Es común la comparación con la electricidad. Sabemos que ésta puede fallar y lo hace muy poco pero ¿compensa tener un generador interno para evitar estos errores? Continuando con el ejemplo, la diferencia es que ahora no sólo nos llega un cable a la casa sino varios (distintas regiones de la Cloud o distintos proveedores) por lo que cambiar de uno a otro es una operación simple y rápida. Aún así pueden existir situaciones en las que hacer uso de la infraestructura interna sea la solución.

Estoy seguro de que serán muy interesantes los análisis “post mortem” de las compañías afectadas y de Amazon AWS, así como las decisiones que se tomen para evitar estar fuera de servicio en el futuro.

Comentarios desactivados en Los errores de la nube / 23 Abr 2011 por Beltran Rueda Borrego
embasev /

Comentarios cerrados.