Llegamos a ustedes gracias a:



Reportajes y análisis

Los 10 peores cortes de la nube

(y qué podemos aprender de ellos)

[14/07/2011] Como concepto, hay mucho que gusta de la nube. Olvídese de esos voluminosos servidores y consiga una unidad grande, dura y blanca en el cielo. Otra persona se encarga del mantenimiento y le permite poner sus datos donde quiera. Incluso la palabra "nube" le trae a la mente una fantasía celestial (aunque un poco esponjosa).

La realidad es, por supuesto, un poco de todo. Lo que se gana por evitar el mantenimiento, se pierde en el control. Y las preocupaciones de seguridad son importantes. Pero en ninguna parte la pesadilla es tan real, como cuando su servicio cloud cae.
Pregúntele a cualquiera de las empresas afectadas por la interrupción de Amazon Web Services en abril.
"Estábamos muy impresionados", señala Nick Francis, cuya empresa, Help Scout, se puso en marcha una semana antes del problema de Amazon. "Definitivamente no estábamos preparados".
Francis no fue el único sorprendido con la guardia baja. Grandes nombres de propiedades como Reddit y Foursquare cayeron cuando la nube de Amazon fue bombardeada.
"La nube se ha vendido como esta cosa mágica que simplemente funciona y es totalmente confiable", indica Lew Moorman, director de estrategia de Rackspace, un proveedor cloud que ha visto su parte justa de los apagones. "La verdad es que la compra a través de la nube es otra forma de compra de la informática, y la computación es inherentemente defectuosa. Si desea asegurarse de que esos defectos no le harán daño, tiene que planificar el futuro".
Para ayudar a mantener su negocio en la nube libre de angustias, le ofrecemos las siguientes lecciones duramente aprendidas a través de diez de las peores tormentas cloud que la Web ha resistido.
Amazon Web Services (AMZN) hizo poof
Liberarse del trabajo duro que representa el mantenimiento de la red es un punto de venta principal para hacer negocios en la nube. ¿El lado negativo? Quedarse de pie sin poder hacer nada, cuando el cambio de la configuración rutinaria de su proveedor cloud detiene su negocio.
Eso es lo que muchos clientes de AWS experimentaron en abril pasado, cuando el centro de datos de Amazon ubicado al norte de Virginia sufrió un problema técnico y -para usar el término técnico- fue totalmente Nutso.
El error comenzó durante una actualización de la red, cuando una transferencia de tráfico extraviada envió un grupo de volúmenes de Amazon EBS (Tienda de bloques elásticos) hacia una tormenta de duplicación, mientras buscaban las cajas disponibles en las que se pudieran insertar copias de seguridad de sí mismas -perverso, lo sé. Eso provocó una serie de acontecimientos que finalmente hicieron bajar a la mayor parte de las empresas de la región oriental de EE.UU.
Esa es la versión corta, de todos modos -si está interesado en el meollo de la cuestión, haga espacio para 47 horas en su agenda y lea la explicación de Amazon que es tan larga como una novela.
Los problemas persistieron durante unos cuatro días. Sin embargo, mientras muchas empresas luchaban, otras como Netflix pasaron la tormenta en calma. ¿La clave para sobrevivir? El diseño de sus sistemas teniendo este tipo de fallas en mente.
"Nuestra arquitectura evita el uso de EBS como nuestro principal servicio de almacenamiento de datos, y los servicios de SimpleDB, S3, y Cassandra de los que dependemos no se vieron afectados por el apagón", escribieron los ingenieros de Netflix en el post "Lecciones aprendidas de Netflix en el corte de AWS" de su blog. Servicios de apátridas y múltiples copias redundantes de datos a través de las zonas de disponibilidad fueron clave para evitar el dolor de la falla de la nube de AWS.
¿Cree que hay que ser un negocio del tamaño de Netflix para estar a salvo? Piénselo otra vez. Twilio, una empresa que ayuda a que los desarrolladores integren las comunicaciones en aplicaciones Web, utiliza Amazon EC2 para albergar el núcleo de su infraestructura -sin embargo, el corte de abril ha tenido poco o ningún impacto sobre su estabilidad.
"La premisa fundamental de la construcción en la nube es el supuesto de que la red va a tener problemas técnicos", señala Evan Cooke, co-fundador y director de tecnología de Twilio. "Hemos construido una infraestructura en torno a la idea de que un host puede y va a fracasar, por lo que no se basan en cualquier máquina o componente de la arquitectura del núcleo en sí".
El cierre de Sidekick
Los teléfonos inteligentes hacen que sea fácil acceder a sus datos fuera de la oficina, pero solo porque algo tenga la palabra "inteligente" en su nombre, no significa que no pueda ser mudo. El caso en cuestión: la metedura de pata de T-Mobile Sidekick, hacia el otoño del 2009.
¿Recuerda este fiasco? Sidekick, de propiedad de Microsoft, sufrió un corte de servicio de casi una semana de duración que dejó a los usuarios sin acceso a correo electrónico, información de calendario, y otros datos personales. Entonces, como si esto fuera poco, Microsoft confesó que había perdido por completo los bits almacenados en la nube, y no sería capaz de restaurarlos. Evidentemente, los chicos de Redmond habían olvidado hacer copias de seguridad.
La tecnología puede haber evolucionado desde entonces, pero la lección sigue siendo la misma: cuando se trata de datos cruciales, nunca asuma que otra persona está automáticamente protegiéndolo. Asegúrese de entender la configuración de recuperación de desastres de su proveedor cloud -mejor aún, haga sus propios arreglos para respaldar los datos importantes de forma independiente.
"Las mismas disposiciones operativas se aplican incluso en la nube", señala Ken Godskind, vicepresidente de productos de monitorización de AlertSite, una empresa SmartBear. "Las organizaciones que utilizan la nube no pueden asumir que porque están en la nube, toda la responsabilidad para la planificación de la continuidad del negocio de alguna manera ha sido transferida al proveedor".
Falla de Gmail
De todos los servicios en la nube, Gmail de Google presenta una de las más probables amenazas al dominio de Microsoft en las empresas. Reemplace sus servidores de Exchange, que cuestan mantener, por un servicio de correo electrónico barato y confiable respaldado por Postini. ¿Qué más se puede pedir?
Una serie de molestas interrupciones, la más reciente de las cuales tuvo a 150 mil usuarios de Gmail iniciando sesión en sus cuentas solo para encontrar páginas en blanco -sin mensajes de correo electrónico, carpetas, nada que indicara que estaban en sus propias bandejas de entrada. A favor de Google: prometió actualizaciones regulares y una solución rápida. Pero las reparaciones demoraron hasta cuatro días para algunos de los usuarios afectados.
"¿Cómo pudo suceder esto, si tenemos varias copias de sus datos, en múltiples centros de datos?" se preguntó el vicepresidente de ingeniería de Google BenTreynor, en un post blogueado en ese momento. "En algunos casos raros, los errores de software pueden afectar a varias copias de los datos. Eso es lo que ocurrió aquí".
Google tuvo que recurrir a copias de seguridad de cinta física real con el fin de restaurar los datos. En última instancia, la protección de múltiples capas aplicada a los datos por parte de la empresa funcionó, pero no sin dejar a miles de usuarios bloqueados fuera de su correo electrónico durante varios días.
¿Es eso una razón para correr, alzando los brazos, lejos de cualquier cosa conectada en la nube? Probablemente no. Pero es una razón para considerar cuidadosamente sus propias garantías de los datos y pensar en la creación de una copia de seguridad o acceso fuera de línea ahora, antes que la urgente necesidad surja.
"Cuando nos fijamos en los promedios generales, la nube tendrá mucho más éxito operativo que usted como individuo", señala Ken Godskind de AlertSite. "Es solo que cuando se va a la escala Web, el impacto del fracaso se amplifica en una forma mucho mayor".
Desastre en Hotmail
Hotmail de Microsoft, experimentó errores en su propia base de datos a finales del 2010, el resultado fueron decenas de miles de bandejas de entrada vacías en el umbral del nuevo año.
El error, según Microsoft, surgió de un script que estaba destinado a eliminar las cuentas ficticias creadas para realizar pruebas automatizadas. En su lugar, el script se dirigió erróneamente a 17 mil cuentas reales.
Microsoft se tomó tres días para restablecer el servicio para la mayoría de los usuarios. Un desafortunado 8% tuvo que esperar un extra de tres días antes de que los datos volvieran al lugar al que pertenecían.
Incluso Clippy no podía sonreír con un dolor de cabeza así.
La doble baja de Intuit
Intuit fue golpeado por una mala racha el año pasado cuando sus servicios conectados en la nube, incluidas las plataformas populares como TurboTax, Quicken y QuickBooks, se fueran de línea dos veces en un solo mes. El peor caso fue un corte de 36 horas en junio. Un corte de energía fue la causa evidente del desastre, con el sistema principal y de respaldo de la empresa cayéndose por completo fuera de la red.
Solo se añadió más sal a la herida, luego, cuando otra aparente falla de energía golpeó a Intuit semanas más tarde. Entre otras cuestiones, el segundo corte pareció causar una tasa anormalmente alta de gritos cargados de obscenidades.
"Veinticinco horas de tiempo de inactividad son difíciles de tragar", escribió un usuario en el momento. "La comunicación pasiva, opaca y rígida de Intuit no ayudó".
Ouch.
"La verdad es que hay mejores soluciones que una sola nube, si usted necesita disponibilidad absoluta", señala Chris Whitener, jefe de estrategia del programa Secure Advantage de HP. "No tiene que duplicar todo necesariamente, pero incluso poner un paso adicional en ello -tal vez haciendo copia de seguridad de datos cruciales por sí mismo- puede hacer toda la diferencia".
El error de BPOS de Microsoft
Es difícil ser productivos cuando su suite de productividad en la nube muerde el polvo virtual. Eso es lo que sucedió con las organizaciones que dependen de la oferta de negocios en la nube de Microsoft hace apenas unas semanas: El servicio, llamado -al más puro estilo Microsoft - Microsoft Business Productivity Online Standard Suite, comenzó a tartamudear hacia el 10 de mayo. Como resultado, el pago electrónico de los clientes se retrasó hasta nueve horas.
Dos días más tarde, justo cuando parecía que BPOS estaba a salvo, la demora regresó y comenzó a recibir mensajes salientes atrapados en la tubería. Como si eso no fuera suficiente, Microsoft experimentó un tema aparte que impedía que los usuarios pudieran iniciar sesión en su portal de Outlook basado en web.
"Me gustaría pedirles disculpas, a nuestros clientes y socios, por las molestias causadas por estos temas", escribió Dave Thompson, vicepresidente corporativo de Microsoft Online Services, en un blog.
"También me gustaría pedir disculpas por las molestias evidentes de tener que hablar 15 sílabas cada vez que dice el ridículo nombre de nuestro servicio", debió agregar, probablemente.
El desliz de Salesforce
Una hora de tiempo de inactividad puede sonar inofensivo, pero cuando su empresa tiene las llaves de las operaciones de servicio al cliente de decenas de miles de empresas, muchas de esas organizaciones están obligadas a ver esos 60 minutos como toda una vida.
Salesforce.com aprendió esto a la fuerza cuando su centro de datos se apagó en enero. Solo cuatro días después de año nuevo, Salesforce.com reportó una falla completa -es decir las nueve yardas de servicios y copias de seguridad hicieron caput.
¿Desconcertante? Por supuesto. ¿Sorprendente? No del todo.
"La realidad es que los centros de datos basados en la nube -adivinen qué- también se caen", señala Tim Crawford, director de información de All Covered, una división de Konica Minolta. "Eso siempre ha sido así y siempre será el caso. Tenemos que ser realistas al respecto".
Crawford señala que el cloud computing exitoso requiere una mentalidad diferente a las configuraciones tradicionales de servidores: Depende de usted, según él, decidir si los datos de su empresa pueden soportar un tiempo de inactividad ocasional -y si no, asegúrese de que su configuración tenga la resistencia necesaria para evitarlo.
"Cuando elige un proveedor cloud, tiene que hacer su tarea para entender cómo se van a proporcionar esos servicios, y si son capaces de construir un nivel de redundancia tan bueno o mejor que el que usted puede hacer por su cuenta", agrega Crawford. "Si la respuesta es no, entonces ¿por qué lo está usando?".
El día terrible de Terremark
En estos días, Terremark puede estar haciendo titulares por millonarios acuerdo con Verizon, pero a principios del 2010, una interrupción prolongada dominó la cobertura del proveedor cloud.
La suerte de Terremark se volvió amarga en el Día de San Patricio, 17 de marzo del 2010. El servicio vCloud Express de la compañía se fue en picada ese día, con un centro de datos con sede en Miami que quedó fuera de línea por cerca de siete horas. Los usuarios no pudieron acceder a los datos almacenados en el centro durante todo ese período.
No hay que ser demasiado redundante, pero esto trae a colación el valor de la redundancia -con sus datos cruciales en múltiples servidores de centros de datos diferentes o, mejor aún, en diferentes regiones. También puede tomar el paso adicional de distribuirlos entre los diferentes proveedores, como un mecanismo de seguridad.
"Puede escoger una serie de proveedores para recibir una carga de trabajo -uno o dos como copia de seguridad, y luego otro como el principal", sugiere Harold Moss, director de tecnología del programa de Estrategia de Seguridad Cloud de IBM. "A continuación, puede implementar su carga de trabajo de una manera segura, con la seguridad apropiada, y empezar a introducir sus capacidades de resistencia."
La caída de PayPal
¿Quiere un corte cloud con un serio impacto de largo alcance? Trate de sacar de la línea a PayPal por unas horas.
Esto no es un ejercicio hipotético: PayPal cayó de verdad en el verano del 2009, dejando a millones de comerciantes en todo el mundo sin la capacidad de vender sus cosas. El servicio estuvo completamente interrumpido por alrededor de una hora y se mantuvo irregular por varias más. PayPal dijo que la culpa fue de una falla en el hardware.
Fue un corte raro, sin duda, pero con toda la pérdida de ventas, esta lamentable interrupción se gana fácilmente un lugar en la sala de vergüenza del cloud computing.
El año difícil de Rackspace
Al ofrecer servicios en la nube a personalidades en la Web como TechCrunch y Justin Timberlake, es mejor creer que la gente se va a dar cuenta cuando los servidores dejen de funcionar.
Rackspace aprendió la lección un par de veces en el año 2009. El proveedor cloud sufrió cuatro fallas de perfil durante todo el año, que suman horas de tiempo fuera de línea para los clientes de la compañía. Un bache ya era bastante malo pues Rackspace tuvo que pagar cerca de tres millones de dólares en créditos de servicio a sus usuarios.
Rackspace catalogó a los incidentes como "dolorosos y muy decepcionantes" y se comprometió a "ejecutar un alto nivel por un largo tiempo. En la actualidad, la compañía sigue centrándose en el tiempo de actividad, pero también trabaja para ayudar a los usuarios a planificar las turbulencias inevitables que vienen con la vida en la nube.
"Si quiere un clúster de servidor o crear redundancia geográfica, es más fácil hacerlo ahora como nunca antes, pero tiene que tomar esas medidas de hecho", señala Lew Moorman de Rackspace. "La nube no produce una debilidad inherente que no haya estado presente si hubiera hecho las cosas en casa primero".
Considerando todo, la mayor lección aquí puede ser que ningún servidor o servicio puede ser 100% confiable. Si no construye su negocio con eso en mente -entonces, amigo mío- simplemente está caminando con la cabeza en las nubes.
JR Raphael, InfoWorld