Pocos temas en tecnología empresarial generan tanto debate apasionado como la estrategia multi-nube. Los vendedores lo promocionan como el camino hacia la libertad. Los analistas lo presentan como inevitable. Las mesas redondas de CIO susurran sobre la influencia y la resiliencia. Los ponentes de conferencias declaran que es el futuro de las arquitecturas de TI empresariales.

Y, sin embargo, tras años apoyando transformaciones en la nube en sectores regulados y no regulados, mi visión se ha vuelto más pragmática.

La multi-nube es real. Hoy en día, muchas empresas operan a través de múltiples proveedores de nube. Pero las razones por las que lo hacen y los resultados que logran suelen diferir significativamente de la forma en que se comercializa o imagina la multi-nube.

La promesa parece convincente: evitar el bloqueo de proveedores, optimizar para lo mejor de la clase, reducir costes mediante la competencia, aumentar la resiliencia entre proveedores y mantener el apalancamiento negociador.

La realidad es más sutil y a menudo más cara.

Investigaciones recientes del sector muestran que las empresas con despliegues multi-nube no gestionados gastan entre un 20 y un 30 por ciento más en infraestructura que entornos de nube única comparables, y más del 80 por ciento reportan una mayor complejidad operativa. Estas cifras no implican que la multi-nube sea un error. Implican que la multi-nube no es gratuita. Conlleva compensaciones que deben ser reconocidas y justificadas.

Esta publicación intenta romper el entusiasmo y describir una realidad que he observado repetidamente: la multi-nube ofrece un valor real para escenarios específicos, pero la mayoría de las organizaciones lo persiguen por razones equivocadas y no están preparadas para las consecuencias operativas.

Cómo llegamos a Multi-Cloud

Entender cómo la multi-nube acabó en los decks de estrategia de las salas de juntas requiere revisar sus orígenes.

Contrariamente a la suposición popular, la mayoría de las empresas no adoptaron la multi-nube mediante una estrategia deliberada a nivel de sistemas. Llegaron allí gracias a una combinación de fuerzas orgánicas:

• Los equipos de aplicaciones seleccionan la nube que mejor se adapta a sus patrones de carga de trabajo
• Decisiones de adquisición vinculadas a acuerdos de licencia o descuentos por volumen
• Fusiones y adquisiciones que introducen pilas heterogéneas
• Requisitos regulatorios regionales que determinan la selección de proveedores
• Equipos de datos y analítica que eligen plataformas diferenciadas para ML o analítica
• Cargas de trabajo heredadas on-premises que persisten indefinidamente

Esto no es lo que yo llamaría estrategia multi-nube. Esto es expansión de nubes, algunos la llaman multi-nube accidental.

Una verdadera estrategia multi-nube implica decisiones arquitectónicas deliberadas sobre dónde se ejecutan las cargas de trabajo, bajo qué condiciones, con gobernanza unificada y controles de seguridad, y con una justificación empresarial clara.

La expansión de nubes es la ausencia de estrategia. La distinción importa porque las acciones correctivas difieren mucho.

Si no se aborda, la expansión en la nube produce fragmentación, modelos de seguridad inconsistentes, herramientas duplicadas, servicios superpuestos, curvas de costes impredecibles y fricciones operativas que se acumulan con el tiempo.

El mito del enclausuramiento del proveedor

Una de las razones más citadas para la adopción multi-nube es el deseo de evitar el bloqueo por parte del proveedor. Este argumento es intuitivo: si las cargas de trabajo se distribuyen entre proveedores, la empresa mantiene la opcionalidad y el apalancamiento de negociación.

En la práctica, el argumento del bloqueo está exagerado y a menudo está mal dirigido.

La clave es que el bloqueo significativo no proviene del proveedor de la nube como concepto. Proviene de los servicios consumidos. Las bases de datos gestionadas, las plataformas de streaming de eventos, los entornos de ejecución serverless, los servicios de IA, los marcos de identidad y las integraciones propietarias de capas de datos crean dependencias que no se borran al ejecutar múltiples nubes. De hecho, utilizar servicios específicos de cada proveedor en tres nubes puede aumentar el bloqueo en lugar de reducirlo.

El segundo error es pensar que cambiar de proveedor es simplemente una cuestión de portabilidad. Las investigaciones indican que la migración implica reestructurar, reentrenar equipos, reescribir integraciones, modificar modelos de identidad, ajustar patrones de observabilidad y absorber el riesgo operativo de la reestructuración. La probabilidad de que una empresa realmente cambie de nube es extremadamente baja, salvo en condiciones económicas o geopolíticas extremas.

La tercera verdad olvidada es que el confinamiento no es inherentemente negativo. Es un intercambio. El precio de la «portabilidad» suele ser una innovación más lenta y una mayor carga operativa. El precio de adoptar servicios nativos en la nube es la dependencia. La cuestión no es si existe el bloqueo de la vivienda, sino si el valor supera el coste.

He visto empresas invertir millones en abstracciones independientes de la nube que nunca usaron para cambiar de proveedor. La portabilidad era teórica. El precio fue real.

Una pregunta más honesta para el liderazgo es: bajo qué escenario realista nos beneficiaría cambiar de proveedor de nube, y cuál es la probabilidad de que ese escenario ocurra en un plazo de 3 a 7 años?

Para la mayoría de las empresas, la respuesta pone de manifiesto lo rara que es la portabilidad que aporta un valor tangible para el negocio.

Los costes ocultos que nadie incluye en el caso de negocio

El argumento financiero a favor de la multi-nube suele asumir que la competencia entre proveedores reduce los costes. En realidad, suele ocurrir lo contrario porque surgen fuentes de costes adicionales que son invisibles en las discusiones estratégicas.

Complejidad operativa

Cada proveedor de nube introduce su propio modelo de identidad, constructos de red, patrones IAM, pila de observabilidad, pipeline de despliegue y semántica operativa. Estandarizar entre ellos no es simplemente un ejercicio de herramientas. Afecta a los perfiles de contratación, rotaciones de guardia, vías de escalada, flujos de trabajo de respuesta a incidentes y carga cognitiva entre los equipos de ingeniería. En multi-nube, la complejidad no se suma, se multiplica.

Salida y transferencia de datos

El movimiento de datos entre proveedores es donde los costes se disparan rápidamente. Los flujos de trabajo analíticos y de aprendizaje automático requieren frecuentemente patrones de movimiento de datos que castiguen las arquitecturas multi-nube. Varias empresas a las que asesoré solo supieron después del despliegue que los cargos por transferencia de datos superaban los costes de cálculo por órdenes de magnitud.

Herramientas y sobrecarga de integración

Para unificar la visibilidad, las organizaciones introducen plataformas de terceros para la gestión de costes, la observabilidad, el seguimiento del cumplimiento normativo y la identidad. Irónicamente, en un intento de evitar la dependencia de los hiperescaladores, se vuelven dependientes de herramientas de gestión entre proveedores.

Talento y experiencia

Encontrar una experiencia profunda en una sola nube es difícil. Encontrar talento con nivel experto en múltiples nubes es significativamente más complicado. Surge un anti-patrón común: equipos competentes en múltiples plataformas pero competentes en ninguna, lo que limita la capacidad de la organización para aprovechar capacidades nativas avanzadas.

Fragilidad operativa

La multi-nube aumenta la superficie de fallo. La respuesta a incidentes se vuelve más lenta porque los ingenieros deben razonar a través de plataformas heterogéneas. Depurar modos de fallo distribuidos entre nubes es mucho más complejo.

Estos costes rara vez se incluyen en las presentaciones iniciales de estrategia, y sin embargo son los principales factores de coste en el segundo y tercer año de adopción multi-nube.

Donde la multi-nube realmente tiene sentido estratégico

A pesar de los desafíos, la multi-nube no es un mito. Existen escenarios legítimos en los que aporta un valor considerable.

Fusiones y adquisiciones

Cuando las empresas se fusionan, se heredan pilas heterogéneas. La unificación forzada es arriesgada y a veces imposible dentro de las ventanas de auditoría o los SLA de los clientes. Un enfoque estructurado multi-nube evita interrupciones y permite una racionalización futura.

Soberanía regulatoria y de datos

Ciertas industrias y jurisdicciones imponen requisitos de residencia de datos que requieren múltiples proveedores para atender mercados globales. Las instituciones financieras, los sistemas sanitarios y los gobiernos suelen operar bajo tales limitaciones.

Diferenciación de la mejor categoría

A veces, cargas de trabajo específicas se benefician materialmente de servicios diferenciados como análisis avanzados, computación de alto rendimiento o plataformas GenAI. La palabra clave aquí es material. «Un poco mejor» rara vez justifica la multi-nube. «Orden de magnitud mejor» a veces sí.

Especialización en la Plataforma GenAI

La IA generativa está emergiendo como un motor legítimo para los patrones multi-nube, y esto merece una atención especial.

A diferencia de las cargas de trabajo tradicionales, donde los servicios en la nube son en gran medida comparables, los ecosistemas GenAI difieren significativamente entre proveedores. Las arquitecturas RAG dependen de bases de datos vectoriales, modelos de incrustación y pipelines de recuperación que varían en madurez y profundidad de integración según la nube. Las opciones de alojamiento de modelos difieren en modelos de fundación disponibles, capacidades de ajuste fino y certificaciones de cumplimiento. La economía de las GPU, incluyendo la disponibilidad, el precio y la capacidad reservada, puede variar significativamente, y las investigaciones sugieren que los costes de inferencia representan entre el 80 y el 90 por ciento del gasto total de GenAI en cargas de producción.

Para las empresas que desarrollan capacidades de GenAI, estas diferencias pueden justificar la adopción selectiva de multi-nube. Una empresa puede utilizar un proveedor para la infraestructura central mientras que otro para acceder a modelos específicos, capacidad GPU especializada o requisitos de cumplimiento que exigen ciertos acuerdos de alojamiento.

Sin embargo, la misma disciplina se aplica. La multi-nube GenAI debería ser una decisión arquitectónica deliberada con una gobernanza clara, no una excusa para que los equipos adopten de forma independiente el servicio de IA que les llame la atención. Como escribí en The GenAI Governance Gap, las organizaciones que se lanzan a GenAI sin fundamentos de gobernanza se enfrentan a fracasos previsibles. Añadir complejidad multi-nube a la adopción de GenAI sin regulación agrava el riesgo.

Gestión de riesgos y concentración en proveedores

Para un pequeño subconjunto de cargas de trabajo críticas para la misión, la resiliencia frente a interrupciones de proveedores de nube puede justificar múltiples entornos activos, aunque operativamente este patrón es extremadamente costoso y normalmente reservado para infraestructuras de mercados financieros o sistemas críticos nacionales.

Apalancamiento estratégico

Algunas empresas globales eligen la multi-nube no por razones técnicas, sino para evitar el riesgo estratégico de concentración. Esta es una decisión empresarial más que tecnológica y debe tratarse como tal.

En todos estos casos, la multi-nube es consecuencia de las realidades empresariales más que una postura filosófica.

El principio 80/20 y el papel de la gobernanza

La guía de AWS sobre estrategia multi-nube recomienda una distribución 80/20 en lugar de una asignación equitativa entre proveedores. Las empresas que tienen éxito con multi-nube tienden a seguir este patrón: designan una nube primaria para la mayoría de las cargas de trabajo y utilizan proveedores secundarios para casos específicos y justificados.

El principal diferenciador en estas historias de éxito no es la arquitectura, sino el modelo de gobernanza.

He escrito antes sobre el poder silencioso de la gobernanza en la nube, y el principio se aplica aún más en entornos multi-cloud. Los entornos multi-nube exitosos incluyen:

• Gestión unificada de identidades y accesos entre proveedores con políticas coherentes y visibilidad centralizada
• Visibilidad centralizada de costes con disciplina de etiquetado y metodologías claras de asignación
• Se aplican políticas de seguridad y cumplimiento consistentes independientemente de la nube que aloje una carga de trabajo
• Criterios claros de colocación de la carga de trabajo documentados y vinculados a la justificación empresarial, no a las preferencias individuales
• Observabilidad multiplataforma con gestión unificada de incidentes y rutas de escalada
• Centros de excelencia en la nube con especialización específica para cada proveedor, según lo recomendado por la guía prescriptiva de AWS

La gobernanza transforma la multi-nube de una complejidad accidental a un diseño intencionado.

Una historia de dos viajes multi-nube

Un fabricante tecnológico buscó la multi-nube para evitar el bloqueo y reducir costes. Las cargas de trabajo se distribuyeron de forma equitativa entre tres proveedores. Tras 18 meses, el gasto operativo aumentó aproximadamente un 35 por ciento, los despliegues se ralentizaron y se acumularon hallazgos de seguridad debido a modelos de identidad y políticas inconsistentes. Los equipos operaban en modo reactivo y la experiencia seguía siendo superficial en todas las plataformas.

En cambio, una organización de servicios financieros adoptó una nube primaria para el 85 por ciento de las cargas de trabajo y una nube secundaria para los requisitos regulatorios regionales. Los criterios de gobernanza eran explícitos, los controles de seguridad consistentes y las capacidades operativas maduras. Los costes eran predecibles, la velocidad de despliegue aumentó y la postura de seguridad se mantuvo fuerte. La experiencia se profundizó porque los equipos tenían una plataforma dominante.

La diferencia no era la capacidad en la nube, sino la claridad estratégica y la madurez en la gobernanza.

Preguntas que todo equipo directivo debería hacer

Antes de adoptar la multi-nube, los líderes deben responder rigurosamente a estas preguntas:

1. ¿Qué problema empresarial específico resuelve la multi-nube para nosotros? Si la respuesta es vaga («flexibilidad» o «evitar el bloqueo»), la estrategia necesita más rigor.

2. ¿Cuál es la probabilidad de que necesitemos trasladar cargas de trabajo entre proveedores en los próximos 3 a 7 años? Si la respuesta es baja, la inversión en portabilidad puede no estar justificada.

3. ¿Tenemos la madurez operativa necesaria para gestionar múltiples nubes sin degradar el rendimiento o la seguridad? La multi-nube amplifica las debilidades operativas existentes.

4. ¿Cuál es el coste completo de la complejidad? Incluye habilidades, herramientas, observabilidad, gobernanza y adquisición de talento en el cálculo.

5. ¿Es la multi-nube una estrategia deliberada o un subproducto de decisiones descentralizadas? La autoevaluación honesta es esencial.

6. ¿Estamos adoptando multi-nube por valor o por óptica? La forma en que los líderes responden a esta pregunta suele revelar si una estrategia multi-nube está justificada o es meramente aspiracional.

Reflexiones finales

La multi-nube no es ni inherentemente buena ni inherentemente defectuosa. Es una herramienta para resolver problemas específicos que tiene implicaciones operativas, financieras y organizativas.

Las empresas que tienen éxito tratan la multi-nube como una capacidad que debe justificarse, gobernarse y dotarse de personal, no como un símbolo de sofisticación o una táctica de negociación.

Como escribí en From Buzzwords to Business Value, la transformación en la nube nunca trata sobre la nube. Se trata del valor empresarial. Aquí se aplica el mismo principio: las decisiones tecnológicas deben servir a los resultados empresariales. La nube no es un destino, la multi-nube no es una condición de victoria, y la libertad no se logra aumentando la complejidad. Se logra aumentando la claridad.

La multi-nube no es señal de madurez. La claridad estratégica sí lo es.

Ricardo González