4 min de lectura
Durante años, el bloqueo de proveedor fue el precio que las empresas pagaron por la comodidad en la nube. En 2026, el equilibrio de fuerzas se invierte: el Reglamento sobre Datos de la UE crea palancas regulatorias, Kubernetes ofrece la abstracción técnica – y un número creciente de empresas alemanas construye su infraestructura conscientemente de forma multi-proveedor.
En resumen
- El Reglamento sobre Datos de la UE, en vigor desde enero de 2024, obliga a los proveedores de servicios en la nube, a partir de septiembre de 2025, a garantizar la portabilidad de los datos y ofrecer interfaces interoperables – un hito para la soberanía en la nube – un cambio de paradigma respecto al bloqueo de proveedor.
- Kubernetes se ha consolidado como estándar de facto para la abstracción en la nube: según la CNCF, el 84 % de las empresas de todo el mundo utilizan contenedores en producción.
- Empresas alemanas como Zalando, Deutsche Bahn y Otto Group apuestan por arquitecturas multi-nube para reducir su dependencia de hiperscalers individuales.
- La estrategia multi-nube puede abrir márgenes de negociación en condiciones contractuales, pero incrementa la complejidad operativa. El efecto neto sobre los costes totales depende en gran medida del nivel de madurez en gobernanza y de la competencia en FinOps.
- El mayor obstáculo no es tecnológico, sino organizativo: la estrategia multi-nube exige una gobernanza unificada, una gestión transversal de competencias y un equipo centralizado de FinOps.
La ecuación es sencilla: quien opera toda su infraestructura con un único hiperscaler se beneficia de la integración y la comodidad – pero pierde poder de negociación, portabilidad y, en caso extremo, el acceso a sus propios datos. Según el informe Flexera State of the Cloud 2025, el 70 % de los responsables de TI encuestados señalan el bloqueo de proveedor entre sus tres principales riesgos en la nube. No obstante, muchas empresas tienen dificultades para salir de esta situación – porque los servicios propietarios, las APIs vinculadas a un proveedor específico y las dependencias acumuladas hacen que el cambio resulte caro y complejo.
El Reglamento sobre Datos de la UE: impulso regulatorio
El Reglamento sobre Datos de la UE, vigente desde enero de 2024, desplegará su pleno efecto para los servicios en la nube a partir de septiembre de 2025. Sus exigencias centrales son:
Los proveedores de servicios en la nube deben garantizar la equivalencia funcional – lo que significa que los clientes deben poder migrar sus cargas de trabajo a otro proveedor sin necesidad de una reingeniería fundamental. Las Switching Charges – es decir, los cargos aplicables al cambio de proveedor – se eliminarán progresivamente: a partir de septiembre de 2025 solo podrán cobrarse los costes directos derivados del proceso de cambio; y a partir de enero de 2027, todas las Switching Charges quedarán suprimidas por completo. Además, los proveedores deben ofrecer interfaces abiertas que permitan exportar tanto los datos como las configuraciones.
Para las empresas alemanas, esto representa una oportunidad estratégica. Quienes hasta ahora han evitado la migración multi-nube por su elevada complejidad obtienen, gracias al Reglamento sobre Datos, palancas regulatorias que aumentan la presión negociadora sobre los hiperscalers. Al mismo tiempo, la prohibición de las Switching Charges reduce la barrera económica para realizar una migración parcial.
No obstante, el Reglamento sobre Datos no es una solución automática. La definición de «equivalencia funcional» se ha formulado deliberadamente de forma vaga, y pasarán años hasta que las normas de ejecución estén detalladas en todos sus aspectos. Las empresas que actúen ya obtendrán una ventaja competitiva – pero no deben esperar a la regulación, sino construir simultáneamente las bases técnicas necesarias.
Kubernetes como capa de abstracción
La respuesta técnica al bloqueo de proveedor es la abstracción – y Kubernetes es la herramienta que materializa dicha abstracción en la práctica. Esta plataforma de orquestación de contenedores permite desplegar y operar cargas de trabajo independientemente del proveedor subyacente de infraestructura.
Según la CNCF Annual Survey 2024, el 84 % de las empresas encuestadas utilizan contenedores en producción. En Alemania, la tasa de adopción alcanza, según Bitkom, el 67 % entre las empresas con más de 500 empleados – un aumento de 15 puntos porcentuales respecto al año anterior.
Kubernetes por sí sola no resuelve completamente el problema del bloqueo de proveedor. Los servicios gestionados de Kubernetes, como EKS (AWS), AKS (Azure) o GKE (Google), suelen integrar funciones propietarias – balanceadores de carga, clases de almacenamiento, gestión de identidades – que, en parte, anulan nuevamente la ventaja de portabilidad.
La clave radica, por tanto, en una decisión arquitectónica consciente: ¿qué funciones de Kubernetes utilizaré de forma multi-proveedor?, ¿qué servicios propietarios aceptaré deliberadamente? y ¿dónde trazaré la línea? Empresas como Zalando han tomado esta decisión de forma sistemática y operan su plataforma de comercio electrónico sobre una arquitectura Kubernetes que es portátil entre AWS y su propio centro de datos.
Casos prácticos: empresas alemanas en ruta hacia la multi-nube
Zalando: El grupo berlinés de comercio electrónico apostó temprano por una plataforma Kubernetes independiente del proveedor. Su infraestructura funciona principalmente en AWS, pero está tan bien abstraída que, en teoría, determinados servicios también podrían ejecutarse en otras plataformas. El valor estratégico: mayor poder de negociación frente a AWS en las conversaciones sobre precios.
„Durante años, el bloqueo de proveedor fue el precio que las empresas pagaron por la comodidad en la nube. En 2026, el equilibrio de fuerzas se invierte.“
Deutsche Bahn: DB Systel, la filial de TI de Deutsche Bahn, gestiona una plataforma multi-nube basada en AWS y Azure. Las aplicaciones para viajeros funcionan en AWS, mientras que las cargas de trabajo internas de SAP se han migrado a Azure. Un equipo centralizado de plataforma asegura que las políticas de seguridad y los requisitos de cumplimiento se apliquen de forma uniforme en ambas nubes.
Otto Group: El grupo comercial de Hamburgo utiliza Google Cloud como plataforma principal, complementada con infraestructura on-premises para sistemas heredados. En este caso, la estrategia multi-nube está motivada menos por razones técnicas que por consideraciones organizativas: distintas sociedades del grupo pueden elegir libremente su plataforma en la nube preferida, siempre que cumplan con los estándares centrales de gobernanza.
El soporte organizativo
La estrategia multi-nube es, ante todo, una decisión organizativa. La tecnología por sí sola no basta – las empresas necesitan tres elementos:
Gobernanza unificada: ¿Quién decide en qué plataforma se ejecuta cada carga de trabajo? ¿Qué servicios pueden ser propietarios y cuáles deben mantenerse portables? Sin una instancia de gobernanza centralizada – ya sea un Cloud Center of Excellence o un consejo de arquitectura – lo que surge no es una estrategia multi-nube, sino caos multi-nube.
FinOps transversal: Una estrategia multi-nube sin monitorización centralizada de costes es una receta para la explosión presupuestaria. Cada proveedor cuenta con sus propios modelos de precios, sus propias estructuras de descuentos (Reserved Instances, Committed Use Discounts, Savings Plans) y sus propias lógicas de facturación. Un equipo de FinOps con visibilidad sobre todas las plataformas no es una opción, sino una obligación.
Gestión de competencias: AWS, Azure y Google Cloud son tres ecosistemas diferentes, cada uno con sus propias certificaciones – el falta de profesionales cualificados agrava aún más este desafío – , sus propias buenas prácticas y sus propios modos de pensar. Las empresas deben decidir si forman equipos con perfil en T – con conocimientos amplios y profundidad especializada en una única plataforma – o si constituyen equipos especializados por nube y coordinan la integración desde una instancia central.
Las empresas que implementan con éxito la estrategia multi-nube tienen algo en común: tratan la estrategia en la nube no como un proyecto de TI, sino como una decisión empresarial. La dirección de TI define los principios rectores, y los equipos de ingeniería los ejecutan.
Preguntas frecuentes
¿A partir de cuándo entra en vigor el Reglamento sobre Datos de la UE para los servicios en la nube?
El Reglamento sobre Datos de la UE está en vigor desde enero de 2024. Las disposiciones específicas relativas al cambio de proveedor en la nube y a la portabilidad de los datos entran en vigor en septiembre de 2025. Los proveedores de servicios en la nube disponen de un período transitorio de 40 meses para adaptar los contratos existentes.
¿Es la estrategia multi-nube siempre más económica que la single cloud?
No necesariamente. La estrategia multi-nube puede reducir costes mediante una mejor posición negociadora y una optimización de las cargas de trabajo – pero operar múltiples plataformas también genera costes adicionales por complejidad. El efecto neto depende del volumen, del nivel de madurez en gobernanza y de la competencia en FinOps.
¿Basta Kubernetes por sí sola para evitar el bloqueo de proveedor?
No. Kubernetes abstrae la capa de cómputo, pero las aplicaciones suelen utilizar servicios propietarios como bases de datos, colas de mensajes o proveedores de identidad. Es necesario, además, tomar una decisión arquitectónica consciente – sobre qué servicios deben ser portables y cuáles pueden ser propietarios.
Lecturas complementarias
- Profesionales de la nube: ¿Por qué Alemania está recuperando terreno en la capacitación continua? – cloudmagazin
- Consolidación de SaaS: cómo los CIOs frenan la proliferación descontrolada de herramientas – cloudmagazin
- Computación periférica (Edge Computing) e Industria 4.0 – cloudmagazin
Más contenido de la red MBF Media
- Producción de vuelta a Europa: reconfigurar las cadenas de suministro – MyBusinessFuture
- Consejo de administración digital: competencias directivas en tecnología – Digital Chiefs
- Seguros cibernéticos 2026 – SecurityToday
Fuente de imagen: Pexels / Panumas Nikhomkhai
