Ayer vivimos (otra) buena lección – una de esas que no gusta pero conviene. AWS cayó; sí, la infraestructura en la que muchas empresas confían casi sin pestañear. No es para alarmarse sin más, pero sí para preguntarnos: ¿qué significa “poner tus servicios en la nube”? ¿Y estamos haciéndolo con los ojos bien abiertos o con fe?

¿Qué es realmente “la nube”?

La nube no es un ente místico, es infraestructura: servidores, redes, almacenamiento, centros de datos que pertenecen a otros (en este caso AWS). Cuando decimos “mover a la nube” lo que hacemos es: delegar – delegar gestión, escalabilidad, mantenimiento, ciertas garantías. Para muchas empresas hace mucho sentido: escalas sin comprar tú 100 servidores, te desapegas del hardware, pagas por uso.

Pero delegar no es “desentenderse”. Porque aunque la infraestructura grande tenga mejores recursos que la mayoría de empresas, sigue siendo susceptible a fallos: humanos, de red, de diseño, geográficos. Por ejemplo, AWS tiene múltiples “Availability Zones” (AZ) y “Regions” para garantizar redundancia interna. Pero como vemos, eso no elimina el riesgo.

¿Es siempre necesaria la nube?

Depende. Hay tres preguntas clave que tienes que hacerte (y en ForgeNEX podemos ayudarte a responderlas):

• ¿Cuáles son tus objetivos de tiempo de recuperación (“RTO” – cuánto tiempo puedes tolerar sin servicio) y de punto de recuperación (“RPO” – cuánto dato puedes permitirte perder)?
• ¿Cuál es la criticidad de ese servicio o esos datos? Un blog de marketing tiene otro nivel de tolerancia que un sistema de gestión de clientes o facturación.
• ¿Qué coste estás dispuesto a asumir por la resiliencia? Más redundancia = más coste = más complejidad.

Entonces: la nube es “necesaria” cuando te aporta escala, agilidad y no te quiere cargar una gran infraestructura local. Pero no es una garantía de cero problemas. Y depender únicamente de un proveedor sin plan a la espalda puede dejarte expuesto.

¿Podemos confiar siempre en infraestructuras como AWS?

La respuesta honesta: no. Confiar “siempre” implica creer que nunca habrá fallo – y los fallos existen, también en AWS. Varios análisis lo afirman: incluso una región bien preparada puede caer. Lo que sí podemos hacer: reducir el riesgo, prepararnos.

Por ejemplo:

• Que tu arquitectura esté desplegada en más de una AZ, o incluso más de una región, si lo justifican tus RTO/RPO.
• Tener monitoreo que detecte temprano caídas, no sólo “todo bien hasta que no”.
• Comunicar claro con usuarios/clientes cuando hay problemas – la transparencia es parte de la recuperación. 

¿Y la solución (o parte de ella): usar múltiples puntos, múltiples proveedores?

Sí. Vale la pena al menos considerarlo. No como panacea, pero como parte del plan. Algunas ideas concretas para que ForgeNEX implemente con clientes:

1. Backup y redundancia geográfica
   • En AWS (o cualquier proveedor) activar replicación de datos fuera de la región principal, o al menos fuera de una única AZ.
   • Hacer backup “cold” o “warm” de infraestructura, configuraciones, scripts de despliegue (IaC: Infrastructure as Code) para poder restaurar en otro lugar si hace falta.
   • Considerar un proveedor secundario (por ejemplo Microsoft Azure, Google Cloud u otro) donde albergar copias esenciales.
2. Arquitectura de failover/desastres
   • Definir qué tolerancia tiene el servicio para caída/región caída. Según esto, escoger entre “backup y restaurar”, “standby caliente” o “multi-sitio activo” (opciones descritas por AWS).
   • En servicios críticos, valorar que sean “activos en varios sitios” y que la redirección/tráfico pueda cambiar si un proveedor falla.
3. Desacoplamiento y diseño para fallos
   • Diseñar aplicaciones que sean lo más “stateless” posible (servidores que pueden morir y otro asumir).
   • Usar colas de mensajes, caches locales, mecanismos que reduzcan dependencia absoluta de “que todo esté online ahora mismo”.
   • Pruebas de “qué pasa si esto cae” (Chaos engineering): probar fallos reales para descubrir puntos débiles.
4. Multi-nodo, multi-proveedor
   • Tener parte de la infraestructura en otro proveedor o en “on-premise” propio (especialmente en el caso de datos que necesitas siempre).
   • Sincronizar datos entre los proveedores, o al menos tener snapshots periódicos que permitan restaurar.
   • Asegurarte de no depender de un único “endpoint” o un solo proveedor de DNS, etc.
5. Monitorización, alertas y recuperación rápida
   • Configurar alertas que detecten fallos de provisión, latencia elevada, error de servicios dependientes.
   • Tener procedimientos documentados (runbooks) para actuación cuando un proveedor falla. Ensayar.
   • Comunicación al cliente: tener plantillas, canales listos para decir “sí, esto está pasando, estamos en ello”.

Depender de una sola plataforma cloud es cómodo, pero no garantía de inquebrantabilidad. La nube es poderosa, sí, pero no infalible. Y para empresas (incluyendo las pymes) que no pueden permitirse largos periodos de inactividad, la mejor apuesta es: la nube sí + plan B sí. Es decir, usarla, sí, pero sin pensar que “ya está todo hecho”. Redundancia, diversificación, preparación para fallos, ensayos … esas cosas que “nadie hace hasta que toca”.

Siendo claro: no estoy diciendo dejar AWS – ni mucho menos. Estoy diciendo que usar AWS es buena opción, pero no poner todos los huevos en la misma cesta sin pensar qué pasa cuando esa cesta se rompe.