Aprovechando el post introductorio de hace unos días, y para no perder el impulso, vamos a seguir hablando del cloud, en un ámbito en el que parece especialmente útil: la continuidad del negocio. Entre otras medidas, es cierto que la existencia de datacenters distribuidos por todo el mundo (¿alguien dijo GDPR?), el escalado flexible de los sistemas y el despliegue casi instantáneo hacen una infraestructura en la nube (en igualdad de condiciones) más resiliente que una infraestructura on premise. Claro que la disponibilidad no es el único factor a considerar, pero de eso hablaremos otro día.
Sin embargo, para hablar de las bondades del cloud los proveedores se bastan y se sobran. De lo que quiero hablar es de algunos de los aspectos que deben ser considerados antes de migrar una infraestructura al cloud (aunque algunos de estos puntos también son aplicables al PaaS y al SaaS). Es decir, los problemas.
1. La nube no falla
Este es el mito que más me gusta, en parte promovido por los grandes proveedores de cloud, que tienden a crear una imagen falsa de disponibilidad total, y comprado sin demasiados reparos por los profesionales de TI. La realidad es que la nube sí falla. Falló en el pasado, y lo volverá a hacer en el futuro; se llama Murphy. Porque la disponibilidad total no existe. Sea Amazon AWS, Google GCloud, Microsoft Azure, Oracle Cloud o IBM Cloud, tarde o temprano habrá caídas. Aunque, ¿saben qué? Desde el punto de vista de la continuidad del negocio importa poco que haya habido o no caídas en el pasado. Debemos asumir que las habrá, y prepararnos para ello.
2. Los SLA son del 99,9999999… lo que sea
Es cierto que el SLA garantizado por los proveedores para la durabilidad de los datos viene a ser una larga hilera de ‘9’, pero es muy importante no confundir durabilidad con disponibilidad, cuyo SLA garantizado oscila entre el 99.9% y el 99.99%, dependiendo del proveedor y el servicio en particular. Lo que en la práctica significa que la probabilidad de que perdamos datos es insignificante, pero la probabilidad de que un servicio no esté disponible en un momento dado es algo mayor (siempre dentro de los márgenes en los que nos movemos). En realidad, 99,99% no parece tan malo, pero vamos con el siguiente punto.
3. Si los SLA no se cumplen, el proveedor del cloud compensa económicamente
Es lógico pensar que incluso una disponibilidad en el rango del 99,9% (sí, me he comido un 9) es perfectamente aceptable en la mayor parte de los casos, especialmente si la caída se distribuye en caídas más cortas a lo largo del año (esa disponibilidad viene a ser un tiempo total de caída de 8,5 horas). Pero ya saben, de nuevo, como va esto de Murphy: pasan cosas y caídas que deberían ser de un par de horas se convierten mágicamente en incidentes de un par de días. Y sí, es cierto, el CSP compensará ese “inconveniente” devolviendo parte (o el total, aunque eso es mala señal) de la factura mensual si el SLA cae por debajo de cierto nivel. Pero, ¿saben qué? Tal vez la compensación no sea suficiente para cubrir el impacto operacional de la caída, y eso es algo a tener en cuenta.
4. El cloud simplifica la continuidad del negocio
De acuerdo. Sí… pero no. No hay duda de que las capacidades técnicas y recursos virtualmente ilimitados del cloud facilitan la recuperación ante desastres. Pero esa es solo la parte visible del iceberg, y hay mucho más debajo (lo que va en la propia analogía). El cloud no nos librará de identificar los procesos y actividades, sus RTO, RPO, MTPD y MBCO, los recursos mínimos y el personal crítico, o de identificar los riesgos existentes. Tampoco de diseñar el implementar el Plan de Gestión de Crisis, los Planes Operacionales o el Plan de Comunicación. Ni de poner en marcha actividades de concienciación en materia de continuidad del negocio, mantener el sistema (de gestión) ni hacer las pruebas de continuidad periódicas (sobre eso, un poco más adelante). Por lo que, sí, podemos decir que el cloud simplifica la continuidad del negocio… pero mucho menos de lo que queremos creer.
5. El coste de las medidas de contingencia es bajo
Francamente, no tengo datos para afirmar que el coste de la implementación de medidas de recuperación ante desastres es mayor en el modelo on premise que en la nube, pero me atrevería a decir que en general, podemos decir que sí. Al final, desplazar el CapEx hacia el OpEx tiene sus ventajas. Sin embargo, la inmensa oferta de servicios de la nube y la sencillez de puesta en marcha de nuevos servicios puede provocar con bastante facilidad que se sobredimensionen los recursos, y se establezcan (es decir, contraten) mecanismos o servicios para hacer frente a una contingencia cuya necesidad no siempre ha sido analizada en profundidad, pero que se contratan simplemente “porque están ahí y es tan fácil…”.
6. El proveedor se encarga de los backups, y las pruebas de continuidad no son realmente tan necesarias
En fin, si nuestro CSP garantiza un 99,9999999… lo que sea de durabilidad de los datos, ¿por qué hacer backups? Quiero creer que la respuesta es evidente, pero por si no es así: porque el proveedor de cloud quizá no pierda datos, pero la operación diaria implica errores, y esos errores pérdida de datos. De acuerdo, está claro, necesitamos backups. Pero ¿para qué probarlos? De nuevo, porque hacer backups no implica automáticamente hacerlos bien. Y podemos ampliar y multiplicar esto en el caso de las pruebas de contingencia. En situación de crisis, vamos a necesitar que las medidas técnicas que hemos implementado (y que llevamos meses o años pagando) funcionen, y que funcionen bien. Exactamente igual que en una infraestructura on premise. Y para eso son las pruebas de contingencia. Lo sé, una obviedad.
En definitiva, a pesar de todos los matices que se puedan introducir, no hay duda de que el cloud proporciona múltiples mecanismos técnicos que facilitan la recuperación ante desastres. Sin embargo, confiar ciegamente en que migrar nuestra infraestructura al cloud va a solucionar todos nuestros problemas es una invitación al desastre, y nunca mejor dicho. La (buena) continuidad del negocio, aquí y en Marte, on premise y en cloud, es un proceso complejo en el que intervienen múltiples variables que no pueden ser simplificadas, para bien o para mal, a una migración a la nube.
