Por qué siguen ocurriendo los cortes de energía y qué se puede hacer realmente al respecto
El año 2025 fue difícil si apostabas tu negocio por un único proveedor de servicios en la nube. En diciembre, los clientes de Snowflake vieron impotentes cómo una actualización del esquema se extendía en cascada en varias regiones, bloqueando las consultas durante 13 horas. Los usuarios de Databricks lidiaron con días de servicios de IA degradados.
En octubre, la región US-East-1 de Amazon Web Services (AWS) quedó inactiva durante 15 horas: un error de DNS que afectó a DynamoDB dejó fuera de servicio a más de 1000 empresas. En junio, una excepción de puntero nulo en el binario de control de servicios de Google Cloud desactivó varios sistemas, incluidos Cloud Storage, Compute Engine y BigQuery durante varias horas, con efectos secundarios que afectaron a Spotify, Discord y OpenAI.
En todos estos incidentes, el patrón era el mismo: los clientes actualizaban las páginas de estado y esperaban a que alguien solucionara el problema. La diferencia entre los proveedores no es si ocurren interrupciones, sino las opciones que tienes cuando suceden.
El patrón: puntos únicos de fallo con alcance global
El incidente de Snowflake en diciembre se debió a una actualización del esquema de base de datos incompatible con versiones anteriores. Los errores de desajuste de versiones provocaban que las operaciones fallaran o se quedaran colgadas indefinidamente en múltiples regiones en AWS, Microsoft Azure y Google Cloud Platform (GCP). Las comunicaciones de Snowflake indicaban que no había soluciones alternativas salvo para clientes que hubieran preconfigurado la replicación a regiones no afectadas. Todos los demás esperaron.
La interrupción de Databricks en diciembre (que duró varios días) incluyó problemas con el catálogo de Unity, degradación de computación en múltiples regiones y una interrupción de Mosaic AI que se prolongó durante días. Las actualizaciones de estado señalaron repetidamente que estaban "trabajando con el proveedor de la nube en posibles rutas de mitigación". Esa frase lo dice todo sobre la cadena de dependencias: cuando Azure tiene un mal día, los clientes de Databricks de las regiones de Azure también tienen un mal día.
El incidente de Google Cloud de junio reveló la misma vulnerabilidad. Una política defectuosa con campos en blanco se insertó en las tablas de configuración global y se replicó por todo el mundo en cuestión de segundos. Los datos corruptos provocaron bucles de bloqueo que interrumpieron los servicios principales durante 7,5 horas. Los propios cuadros de mando de estado de Google inicialmente no estaban disponibles: los equipos SRE ni siquiera pudieron confirmar el alcance del desastre.
La redundancia regional no ayuda cuando el fallo es lógico más que físico. Cuando una plataforma se basa en metadatos coordinados a nivel mundial o en una configuración compartida, una sola actualización errónea se propaga por todas partes. El fracaso te sigue de región en región.
Además, en estos escenarios, la infraestructura está distribuida, pero el control permanece centralizado. Cuando el plano de control de Snowflake se rompe, no importa que se ejecute en AWS, Azure y Google Cloud Platform por debajo. Cuando Databricks espera a que Azure arregle algo, el marketing multinube no ayuda. El único punto de fallo es la capa patentada en la parte superior.
Lo que dicen los analistas
El análisis de Gartner® de 2025 sobre las tendencias de adopción de la nube estima que más del 50 % de las organizaciones no obtendrán los resultados esperados de sus implementaciones multinube para 2029. El problema principal: la falta de interoperabilidad entre entornos.
En Forrester Predictions 2026: Cloud Outages, Private AI On Private Clouds, And The Rise Of The Neoclouds, la empresa de investigación predice al menos dos grandes interrupciones de varios días en la nube en 2026. La industria de la nube está atravesando una enorme transición de infraestructura, ya que los hiperescaladores compiten por construir centros de datos nativos de IA. Esa inversión tiene un coste: se está despriorizando los entornos x86 y ARM antiguos, lo que hace que la infraestructura envejecida se tambalee por la creciente complejidad.
En el mismo artículo de predicciones de Forrester, estiman que al menos el 15 % de las empresas cambiarán a implementaciones de IA privadas creadas en nubes privadas en 2026. Los factores: el aumento de los costes de la IA, la preocupación por el bloqueo de los datos y el riesgo operativo de depender de una infraestructura que se optimiza cada vez más para las prioridades de otra persona. Las interrupciones de 2025 fueron un adelanto de lo que ocurre cuando tus cargas de trabajo no son la principal preocupación del proveedor.
Arquitecto para la resiliencia con Cloudera
La mayoría de las empresas tienen arquitecturas de “multinube accidentales” debido a adquisiciones, TI en la sombra o la selección de las mejores herramientas, y no a través de una planificación arquitectónica deliberada. Sus cargas de trabajo están dispersas entre los proveedores, pero carecen de la capacidad de mover los datos y las cargas de trabajo cuando las cosas van mal.
La arquitectura para la resiliencia implica garantizar que tu plataforma de datos e IA permita la portabilidad y elimine los puntos únicos de conmutación por error.
La plataforma Cloudera está diseñada para la portabilidad y te da la posibilidad de realizar una conmutación por error entre entornos para mantener las operaciones. Las cargas de trabajo y los datos pueden moverse entre AWS, Azure, Google Cloud y los entornos locales sin reescrituras, fricciones ni dependencia de un proveedor. Las actualizaciones no se fuerzan como cambios globales y no compatibles con versiones anteriores.
Cuando se produce una interrupción inevitable, tienes varias opciones: realizar una conmutación por error a otra nube o trasladar las cargas de trabajo de vuelta a tu centro de datos. No tienes que estar pendiente de una página de estado: mantienes el control de tus datos y puedes garantizar la coherencia de las operaciones y el cumplimiento normativo independientemente de dónde se encuentren los datos.
Para obtener más información sobre cómo construir una arquitectura resiliente con Cloudera, lea nuestro blog: Arquitectura para la resiliencia de datos: garantizar la continuidad del negocio con Cloudera
Mirando hacia el futuro
El desarrollo de la IA está sobrecargando la infraestructura y las empresas analíticas apuntan a más turbulencias en el futuro: Forrester predice interrupciones de varios días, Gartner predice una adopción defensiva en múltiples nubes. Las empresas que lleguen al 2026 en buena forma serán aquellas que traten la resiliencia como un principio arquitectónico en lugar de una casilla de verificación de cumplimiento.
Cloudera no ofrece una conmutación por error entre nubes con solo pulsar un botón lista para usar; nadie lo hace. Pero estamos arquitectónicamente posicionados para apoyar esa resiliencia de una manera que las plataformas propietarias no lo están.
Si las interrupciones del servicio en 2025 te han causado molestias, nos gustaría hablar contigo al respecto. Porque la nube es solo el ordenador de otra persona. Y cuando ese ordenador tiene un mal día, deberías tener otro sitio al que ir.
Para obtener más información sobre cómo diseñar soluciones resilientes con Cloudera, contacta con nuestro equipo de servicios profesionales, echa un vistazo a nuestras demostraciones de productos o regístrate para obtener una prueba gratuita de 5 días.
