¡Sorpresa! ¡La nube puede fallar!

Si no leíste la noticia, tal vez te diste cuenta al ver cómo múltiples servicios de compañías diferentes fallaban al mismo tiempo: Foursquare, Reddit, Hootsuite, Quora y varios cientos de compañías más fallaban o sufrían problemas con la caída de la Amazon Elastic Compute Cloud (EC2), una plataforma de cloud computing utilizada por una gran cantidad de servicios.

Según parece, la promesa de independencia entre sistemas que Amazon ofrecía como garantía de redundancia y estabilidad falló estrepitosamente: varios sistemas situados en lugares geográficamente separados fallaron a la vez debido, según parece, a un procedimiento de copia de seguridad descontrolado que hizo incontables copias de sí mismo, en un efecto en cascada que consumió rápidamente todo el espacio disponible y dio lugar a lo que ya se ha dado en llamar el “cloudgate” o el “cloudpocalipsis”. Algo que, efectivamente, nunca debió producirse, y que hace surgir dudas de todo tipo sobre la madurez y desarrollo del cloud computing en su conjunto.

¿O no? En realidad, ¿es lo ocurrido de algún modo diferente a la caída de una central eléctrica? ¿O al fallo de una estación de suministro de agua potable? Si algo sabemos de la tecnología es que es imposible que no falle, y que lo que debemos hacer es tomar las medidas adecuadas para que, cuando falle (no “si falla”, porque el que fallará es algo que alcanza la categoría de certeza metafísica), los efectos del fallo sean lo menos graves posible. La energía eléctrica falla en mi casa con suficiente frecuencia como para que hace años decidiese adquirir un modesto sistema de alimentación ininterrumpida (SAI) de uso doméstico, y me consta que ese tipo de fallos son perfectamente habituales en la vida de mucha gente, no solo en España sino en otros países en los que he vivido. Cuando falla, supone una molestia importante en tu vida diaria, cuando no una pequeña catástrofe debido a problemas de todo tipo. Y si llamas a la compañía, se excusan y te dicen básicamente eso, que es un fallo y que no pueden hacer nada, que las cosas fallan de vez en cuando. Y hablamos de servicios como la luz o el agua, que llevan con nosotros muchos, muchos años, en los que confiamos plenamente y sobre los que construimos muchos aspectos de nuestra vida, alrededor de una fiabilidad que tomamos por descontado.

De acuerdo, el fallo no debería haberse producido. Como hemos dicho en otras ocasiones, la nube es tan buena – o mala – como buenos – o malos – sean sus proveedores. No hay “nube”, hay empresas que proveen servicios en ella. Empresas en las que cifrar determinados niveles de confianza, riesgos que estimar y valorar, evitando tanto un extremo (quedarse sistemáticamente al descubierto) como el otro (invertir más de lo que el riesgo realmente puede llegar a suponer). Tanto el defecto como el exceso suponen problemas, que pueden ir desde la interrupción del servicio y la pérdida de reputación hasta el exceso de coste. La tecnologia, oh sorpresa, puede fallar. Si la posibilidad de ese fallo es crucial para tu compañía, redúndala, preferentemente con diferentes proveedores. Un servicio como este blog que estás leyendo tiene varios sistemas de alerta inmediata, varios procedimientos alternativos en caso de caída dentro de mi proveedor de hosting, Acens, y aún así, a pesar de recibir protocolos de atención similares al de clientes de Acens con una criticidad de servicio infinitamente mayor que la mía, incluso una copia de seguridad diaria sobre Amazon. Y eso que si todo falla… me da prácticamente igual, porque el servicio que proporciona esta página puede ser cualquier cosa menos crítico. El posible impacto de una caída de un día completo de mi blog es prácticamente nulo, porque al día siguiente, mis lectores, seguramente, seguirán estando ahí: me juego cada día mucho más en función de lo que pueda ocurrir dentro de mi cabeza que de lo que pueda ocurrir dentro de mi servidor.

Lo importante es plantearse una caída como esta, sucedida en un momento de bajo impacto (en pleno período vacacional y en uno de los días de tráfico más bajo de todo el año) como algo de lo que aprender. Para Amazon, entender que los fallos -dentro de un orden – pueden suceder, shit happens, pero que no deben fallar otros elementos fundamentales, como la comunicación. Para quien tiene procesos de verdad críticos con un impacto importante en lo transaccional, traducibles directamente a valor económico, que es preciso redundar en la medida que pueda paliar al menos una parte del posible perjuicio, y que dicho análisis no es una cuenta de servilleta que se hizo una vez al montar el servicio, sino un análisis dinámico en función de las diferentes opciones disponibles, la evolución de su coste, la de nuestro volumen de operación, etc. Un análisis de riesgos que no se puede descuidar.

Para Amazon, el fallo va a suponer un importante perjuicio. Muchas cosas pueden fallar, pero lo que no debe fallar es la esencia de lo que prometías a tus clientes (sistemas completamente independientes) ni tu comunicación con ellos. El cloud computing está en sus inicios, y veremos fallos como el de ayer en numerosas ocasiones. Pero tan tangibles como esos mismos fallos son sus ventajas en términos de escalabilidad, flexibilidad, coste, rendimiento, eficiencia y muchos otros, hasta el punto de convertirse en ventajas fundamentales que definen, para muchas empresas, el auténtico ser o no ser, la disminución de barreras de entrada que hacen que muchas cosas que de otro modo no serían posibles puedan, efectivamente, ser posibles. Lo cual no quiere decir que, como todo, de vez en cuando pueda fallar.

(Enlace a la entrada original - Licencia)