Como muchos habrán escuchado, leído o experimentado en carne propia, la semana pasada la plataforma de servicios web AWS de Amazon se vino abajo estrepitosamente, arrastrando consigo a muchos sitios, servicios y emprendimientos que alojan con ellos como Hootsuite, Quora, FourSquare, Reddit, Heroku, Chartbeat y bueno, Betazeta.
Hoy ha salido a la luz nueva información que no nos deja completamente satisfechos y, en la práctica, tiene a varios clientes algo disconformes.
El problema se presentó la madrugada del jueves 21 de abril, cuando un error del cual no se ha dado suficiente información gatilló un mecanismo de emergencia que respalda los volumenes elásticos de storage (EBS) y levanta espejos. Este proceso escaló en cadena levantando espejos de espejos, respaldos de respaldos, respaldos de espejos, espejos de respaldo ocupando finalmente todo el espacio disponible. Los sitios que cayeron sufrieron la consecuencia de este proceso de emergencia recursivo, pero si bien todos entendimos el síntoma, todavía nadie tiene clara la enfermedad: ¿Qué hizo que los volúmenes intentaran replicarse infinitamente? ¿La nube cobró conciencia? ¿Pasará nuevamente mañana o pasado?
Durante el jueves 21 el servicio se fue restableciendo paulatinamente. Algunos sitios volvieron durante esa tarde y nosotros durante la madrugada del viernes. A las 6:30 am nuestro equipo IT declaró la emergencia superada y se fue a casa con 22 horas de trabajo continuo en el cuerpo y aproximadamente 2Kg de pizza en las tripas y otro tanto en litros de café (alimento de campeones). En esa jornada maratónica levantaron nuestros respaldos y salvo por el desfase natural entre el último respaldo y la caída de Amazon, se recuperó todo.
Hoy Amazon reconoció oficialmente que aproximadamente un 0.07% de la información se perdió para siempre y, aunque eso parece muy poco, en algunos casos equivale a haber perdido el proyecto completo (aunque no me consta que alguien haya tenido tanta mala suerte). Este reconocimiento es hasta ahora la información más relevante ofrecida por el proveedor, luego de casi una semana de mantener a los clientes en la oscuridad.
Esto no hace sino acrecentar la molestia entre los usuarios de la nube AWS, que no sólo se debe al hermetismo de la empresa sino a que quedó en evidencia que el servicio no es tan diversificado como se ofrecía. Así como hay regiones que son absolutamente independientes, cada región tiene Availability Zones (AZ) que pueden compartir un mismo volumen de datos pero son independientes a nivel material, de modo que si cae una bomba nuclear en un AZ no bote a toda la región. Bueno, no fue una bomba nuclear -eso lo tenemos claro- y de todos modos sí cayó toda la región, al menos todo el storage compartido en ella. ¿No contradice eso los términos de servicio?
Muchos anticipan reacciones luego de este incidente. Algunos pronostican que las empresas abandonarán la nube, aunque eso me parece improbable. Sí queda en evidencia que necesitamos no solamente tener respaldos offline fuera de Amazon (que ya tenemos) sino la capacidad de atender al menos parcialmente aunque se caiga el proveedor principal. Como sea, el aprendizaje para nosotros no es que hay que abandonar la nube, sino volverse infinitamente flexibles para aprovechar su esencia volátil.
Para cerrar, también es relevante comentar que cada vez que quiebra un banco sale alguien a decir: “por eso es mejor guardar la plata debajo del colchón” y cada vez que sube el precio de los limones mi suegra dice: “por eso hay que plantar limoneros”. La verdad es que la diversificación y tercerización de cualquier aspecto de nuestra actividad no están exentas de riesgo, y uno lo elige conociéndolos y tomando la decisión que maximiza su valor. En ese escenario, encerrarse y aspirar a autoabastecerse en todos los insumos y servicios que uno necesita puede eliminar el riesgo, pero también todo el valor agregado de existir en una economía globalizada. El remedio sería peor que la enfermedad
Link: Amazon: Some data won’t be recovered after cloud outage (The Register)
