---
title: "Multi-cloud: la mentira más cara del sector (y por qué Europa necesita otra senda)"
description: "Durante años, la diapositiva fetiche de los comités de dirección ha sido siempre la misma: “No queremos vendor lock-in . Vamos a ser multi-cloud ”. Traducido del powerpointiano al castellano: vamos a..."
url: https://revistacloud.com/multi-cloud-la-mentira-mas-cara-del-sector-y-por-que-europa-necesita-otra-senda/
date: 2025-09-22
modified: 2025-09-20
author: "Silvia A. Feliz"
image: https://revistacloud.com/wp-content/uploads/2025/09/multicloud-problems.jpg
categories: ["Análisis y opinión", "Cloud"]
tags: ["cloud privado", "infraestructura", "Multicloud", "vendor lock-in"]
type: post
lang: es
---

# Multi-cloud: la mentira más cara del sector (y por qué Europa necesita otra senda)

Durante años, la diapositiva fetiche de los comités de dirección ha sido siempre la misma: “No queremos *[vendor lock-in](https://revistacloud.com/vendor-lock-in-el-peligro-invisible-en-la-nube-y-la-tecnologia-moderna/)*. Vamos a ser *multi-cloud*”. Traducido del *powerpointiano* al castellano: **vamos a triplicar la complejidad y a duplicar la factura**. Y, para rematar, cuando algo crítico falle, nadie levantará la mano a tiempo. Lo que se prometía como independencia acaba, demasiadas veces, convertido en **deuda técnica con sobrecoste *premium***.

Este reportaje recoge la crítica —cada vez menos impopular— a la estrategia *multi-cloud* tal y como se aplica en la práctica, el contexto europeo de **soberanía digital** y una alternativa realista: **cloud privado moderno** sobre **virtualización abierta y europea**, con [Proxmox](https://revistacloud.com/proxmox-la-alternativa-real-y-de-codigo-abierto-a-vmware-para-entornos-empresariales/) como pilar tecnológico y **proveedores 100 % europeos**, incluso españoles, como **[Stackscale](https://www.stackscale.com/es/)**, alineados con esa visión.

## El mito fundacional: “evitar el *lock-in*”

La promesa suena prudente: si se reparten cargas en varios *hyperscalers*, se reduce el riesgo de dependencia y se gana resiliencia. El problema es que **esa independencia rara vez se consigue**. Las aplicaciones reales se pegan a servicios gestionados concretos (colas, *datastores*, identidad, *serverless*, IA, analítica). Al final, **las piezas que hacen competitivo a cada proveedor son, precisamente, las que atan**.

La consecuencia es conocida en la trinchera: **portabilidad teórica, dependencia práctica**. Sí, Kubernetes ayuda… hasta que la app necesita la base de datos X gestionada, el *feature flag* Y propietario o el *embedding* Z de IA. Migrar ya no es mover contenedores: es **replantear servicios**, reescribir integraciones y volver a certificar *compliance*. El coste, financiero y organizativo, aparece cuando la pizarra deja paso a la realidad.

## Las tres facturas ocultas del *multi-cloud*

### 1) Complejidad operativa crónica

Cada nube trae **su propia semántica**: redes, seguridad, identidad, *observability*, *billing*, *quotas*, límites blandos y duros. Multiplicar nubes multiplica **matrices de fallo** y **vectores de incidente**. Donde antes había un *runbook*, ahora hay tres; donde antes había un panel de control, ahora hay cuatro herramientas y un puente de monitorización que nadie quiere mantener en fin de semana.

### 2) Equipos “aprendices de todo, maestros de nada”

Construir excelencia en AWS, GCP o Azure exige **años**. Pretender dominar **tres** a la vez suele degradar el nivel medio. El talento senior se dispersa; el *mid-level* se frustra; el *on-call* se incendia. La consecuencia es la peor posible: **seguridad difusa, costes descontrolados y tiempos de respuesta alargados**.

### 3) Costes financieros que no salen en el *pitch*

La promesa de “optimizaremos precios comparando proveedores” choca con la realidad de **egresos**, **interconexiones**, ***overheads* de gestión**, **duplicación de herramientas** y **contratos mínimos**. Lo barato se evapora entre líneas. En la práctica, muchas compañías acaban **pagando lo mismo a tres proveedores** en lugar de **optimizar el gasto en uno** y hablar en serio de descuentos por compromiso o *reserved capacity*.

## Cuando la teoría colisiona con el soporte

En las crisis nadie llama “a los tres”. Cuando un servicio se cae y amenaza la cuenta de resultados, **se llama al que realmente sostiene la carga**. Si los datos están en la nube A, la *pipeline* de pagos en la B y la orquestación en la C, el incidente se convierte en **búsqueda del culpable**. Los SLA se vuelven poesía y **el tiempo de recuperación**—lo único que importa— se dispara. La foto final es conocida: **Frankenstein arquitectónico**, difícil de auditar, caro de asegurar y pobremente gobernado.

## ¿Es *multi-cloud* siempre mala idea? No. Pero el margen es estrecho.

Existen **casos justificables**:

- **Regulación y *compliance*** con requisitos explícitos de **separación de cargas** o **salvaguardas jurisdiccionales**.
- **Continuidad de negocio** con **planes serios** de *active-standby* entre proveedores, **datos replicados** y **ejercicios de conmutación** medidos por RTO y RPO, no por diapositivas.
- **M&A**: grupos con negocios heredados, donde la heterogeneidad es un daño colateral transitorio.
- **IA y *specialized workloads***: elegir un proveedor sólo por un **acelerador concreto** o una **capacidad de entrenamiento** que no existe en otro… asumiendo conscientemente el *lock-in* **por valor**.

Pero para todo lo demás, **rock-solid *single-cloud*** bien diseñado (multi-zona, multi-región, *IaC*, *observability* madura) y **cloud privado** donde tenga sentido —*low-latency*, control de costes, *data residency* o exigencias de rendimiento— suele ganar en **simplicidad, control y previsibilidad**.

## Europa necesita otra senda: soberanía y proximidad

El discurso *multi-cloud* ha servido como excusa para no tomar decisiones de fondo: **dónde residen los datos**, **quién da soporte**, **qué jurisdicción aplica** y **qué dependencia estratégica estamos asumiendo**. Para Europa, y especialmente para España, la pregunta es política, económica y tecnológica: **¿queremos construir industria o alquilarla?**

**Soberanía digital** no es un eslogan: es **capacidad** real de **operar, proteger y escalar** infraestructuras críticas **sin pedir permiso fuera de la UE**, alineadas con el **RGPD** y con marcos regulatorios que se endurecen. Significa poder hablar **en nuestro huso horario**, con **ingeniería local** y **responsables** que responden a **nuestras leyes**. Y también **contribuir a la cadena de valor europea**, en vez de alimentarla fuera.

En este contexto, **apostar por empresas 100 % europeas —e incluso españolas—** no es proteccionismo ingenuo: es **estrategia industrial**. Se traduce en **cercanía**, **latencias previsibles**, **costes claros**, **contratos transparentes** y un ecosistema donde **proveedor y cliente** pueden **co-diseñar** soluciones. Además, **reduce la asimetría** de poder de negociación que existe con los *hyperscalers*.

## La alternativa pragmática: cloud privado moderno (y abierto)

Lejos de nostalgias *on-prem*, el **cloud privado** contemporáneo no compite con la nube pública: **la completa**. Para cargas **predecibles**, **sensibles**, **latencia-críticas** o con **turbulencia de coste**, **montar o consumir** un **cloud privado** bien hecho **recupera control** sin renunciar a elasticidad dentro de límites razonables.

### Proxmox como *stack* europeo y abierto

**Proxmox VE** es un **hipervisor de código abierto**, desarrollado en Europa, con un ecosistema maduro y **capacidad real** para sostener **entornos de producción**:

- **Virtualización KVM** y **contenedores LXC** sólidos.
- **Ceph** para almacenamiento distribuido, con **replicación**, **autocuración** y **escala horizontal**.
- **Redes virtuales** con VLAN, *bonding*, OVS y reglas de *firewall* integradas.
- **Backups consistentes**, **replicación** y **restores granulares** (VM completas o discos).
- **Automatización** vía API y *Terraform providers* mantenidos por comunidad/partners.

Todo ello con **licenciamiento predecible** y **sin peajes por VM o por API**; sin sorpresas por **egresos** y con **observabilidad** bajo control del cliente o del proveedor europeo que lo opere.

### Stackscale: cloud privado europeo con soporte experto

En España, **Stackscale** (Grupo Aire) opera **infraestructura *bare-metal* y cloud privado** con [**soporte especializado** en **Proxmox**](https://www.stackscale.com/es/blog/proxmox-ve-9-la-evolucion-del-cloud-privado-open-source/) —formación base, **monitorización del hipervisor**, **backups de configuraciones y estados de VM**, **restauración** ante fallos de la capa de virtualización— y **almacenamiento centralizado** capaz de **levantar cargas rápidamente**.
Según apunta **David Carrero Fernández-Baillo**, cofundador y VP de Ventas & Marketing, el enfoque es **complementario**: “**bare-metal** donde hace falta **máxima performance** o control fino de costes; **clusters Proxmox** donde se requiere **elasticidad privada** y **altísima disponibilidad**; y **conectividad** para integrar con nubes públicas cuando aporta valor concreto”. Es, en esencia, **usar cada pieza por lo que mejor sabe hacer**, sin importar el logo, pero **cuidando la soberanía** y **el *runbook***.

## Un plan más honesto que “ser de todos a la vez”

Para la mayoría de organizaciones europeas que no son una *big tech* con equipos de plataforma de tres cifras, **este enfoque mixto funciona mejor** que el *multi-cloud* genérico:

1. **Elegir un proveedor principal** (público o privado) y **hacerlo bien**: *multi-AZ*, *multi-región* si aplica, *IaC*, *SLOs*, *error budgets* y costes contenidos.
2. **Añadir cloud privado** donde el **TCO gane**: datos sensibles, cargas estables, rendimiento, latencia, *FinOps*.
3. **Interoperar de forma concreta** con otras nubes **solo** por **ventajas nítidas** (un acelerador, una región imprescindible, una *feature* diferencial).
4. **Diseñar la salida** desde el día uno: **datos soberanos**, **formatos abiertos**, ***backups* fuera de banda**, **planes de *exit*** probados.
5. **Alinear seguridad y *compliance*** con un **marco único**: identidad, claves, *logs*, *SIEM* y *runbooks* que no dependan de tres mundos distintos.

Con este guion, **la independencia es táctica y verificable**, no un *mantra*. Y, sobre todo, **se recorta la deuda técnica** que el *multi-cloud* difumina hasta que llega el primer gran incidente.

## Objeciones habituales… y respuestas incómodas

- **“*Multi-cloud* abarata por competencia.”**Solo si se opera con **métricas de coste por producto**, **egresos controlados** y **capacidad de negociación** real. En pymes y *mid-market*, el efecto suele ser el contrario.
- **“Kubernetes nos hace portables.”**Kubernetes porta **contenedores**; lo que ata son **servicios gestionados y datos**. Portabilidad ≠ *lift-and-shift* exprés.
- **“Es más resiliente por definición.”****No** sin **datos replicados** entre nubes, **ejercicios de *failover*** y **automatismos fiables**. Duplicar logos no duplica resiliencia.
- **“Nos acerca a la frontera tecnológica.”**Solo si se **usa** esa frontera. Tener tres catálogos no convierte a nadie en *state of the art*.

## Conclusión: menos *hype*, más arquitectura y soberanía

Llamar a las cosas por su nombre no es pesimismo, es higiene técnica. **El *multi-cloud* indiscriminado es, demasiadas veces, el autoengaño más caro del sector**. Europa —y España— **no pueden permitirse pagar complejidad importada** mientras renuncian a **capacidad estratégica propia**. Hay una alternativa: **combinar con criterio** nube pública y **cloud privado abierto**, empujar **proveedores europeos** que respondan **aquí** y construir **arquitecturas verificables** que sobrevivan al *hype*.

En ese mapa, **Proxmox** aporta un **núcleo europeo y abierto**; **Stackscale** y otros actores aportan **proximidad, soporte y *know-how*** para hacerlo **real**. No se trata de ideología, sino de **ingeniería, economía y responsabilidad**.

---

## Preguntas frecuentes

**¿Cuándo tiene sentido una estrategia *multi-cloud* y cuándo no?**
Tiene sentido en **exigencias regulatorias** que obligan a **separación de cargas**, **planes de continuidad** con **datos replicados** y **ensayos de conmutación**, o **ventajas técnicas únicas** (p. ej., un **acelerador de IA** específico). **No compensa** cuando se adopta por **inercia política** o **miedo difuso al *lock-in***: suele traducirse en **costes mayores** y **complejidad innecesaria**.

**¿Qué aporta un proveedor 100 % europeo o español frente a un *hyperscaler*?**
**Soberanía jurídica** (RGPD y marcos UE), **soporte en proximidad**, **latencias estables**, **contratos más claros** y **capacidad de co-diseño**. Además, **desarrolla industria local** y reduce **dependencias estructurales** de EE. UU.

**¿Por qué Proxmox es una base sólida para cloud privado moderno?**
Porque es **abierto, europeo** y **probado**: KVM + LXC, **Ceph** distribuido, **redes virtuales** avanzadas, **backups y replicación** integrados, APIs para automatizar e integrar con *tooling* estándar. Permite **predecir costes**, **evitar peajes por uso** y **controlar datos** y operaciones.

**¿Qué ofrece un proveedor como Stackscale en este esquema híbrido?**
**Infraestructura *bare-metal* y cloud privado** con **soporte experto en Proxmox** (formación base, **monitorización del hipervisor**, **backups de configuraciones/estados**, **restauraciones rápidas** desde almacenamiento centralizado), además de **conectividad** para integrar con nubes públicas **solo** cuando aporte valor. Es **pragmatismo operativo** al servicio de **soberanía y control**.