Estrategia multi-cloud: cómo evitar el vendor lock-in sin sobreingeniería

La mayoría de las conversaciones sobre vendor lock-in empiezan por la pregunta equivocada: si conviene ejecutar en dos nubes. La útil es más concreta y más difícil: cuánto costaría dejar tu proveedor actual en un plazo de doce meses, cuánto tiempo llevaría y qué se rompería primero.

Pocos equipos saben responder, porque el lock-in no es una sola cosa. Es una pila de dependencias separadas, cada una con su propio coste de salida. Una segunda nube resuelve algunas y, a cambio, duplica tu superficie operativa. Conocer tu coste de salida, y probarlo, las resuelve todas con mucho menos esfuerzo.

El lock-in es una pila, no un único riesgo

Puntúa cada capa por su coste de salida: el tiempo de ingeniería para reconstruirla en otro sitio, más el dinero puntual (como la transferencia de datos), más el riesgo del cutover. Las valoraciones de abajo son puntos de partida típicos, no veredictos.

• Cómputo: normalmente bajo. Las cargas de trabajo en contenedores sobre Kubernetes se mueven con pocos cambios. Las imágenes de máquina, las llamadas a los metadatos de instancia en los scripts de arranque y las anotaciones del balanceador de carga, no.
• Bases de datos gestionadas: de bajo a alto. PostgreSQL o MySQL gestionado es un motor estándar; los datos salen con un dump o con replicación lógica. Una base de datos propietaria, con su propio modelo de datos y su propia API de consulta, obliga a reescribir todas las consultas.
• Colas y buses de eventos: medio. El código que habla un protocolo abierto (AMQP, MQTT, el protocolo de Kafka) se mueve con poco coste. Una API de colas propietaria exige reescribir el adaptador, y la semántica (garantías de entrega, orden, reintentos) difiere más que las API.
• Identidad e IAM: alto, y el más subestimado. Cada rol, política y binding de cuenta de servicio está escrito en el lenguaje de políticas de un proveedor y no se traduce. Si tu personal inicia sesión a través del directorio del proveedor en lugar de tu propio proveedor de identidad, también hay que mover todas las cuentas de usuario.
• Red: medio. Las subredes y las reglas de firewall se reconstruyen. Lo doloroso está fuera de tu entorno: los partners que han añadido tus IP de salida a una allowlist.
• Observabilidad: de bajo a medio. Con agentes nativos del proveedor, cada dashboard y cada alerta se reconstruyen a mano. Con OpenTelemetry y métricas compatibles con Prometheus, cambias el endpoint de un exportador.
• Serverless propietario: alto. El código de las funciones suele ser portable. Los triggers, el cableado de eventos y las definiciones de workflows que lo rodean no lo son, y es en ese pegamento donde se acumula la lógica de negocio.
• Datos y egress: crece cada mes. Cada terabyte que añades encarece la transferencia y alarga la ventana de cutover, aunque la arquitectura no cambie nunca.

Construye el inventario de tu propio entorno

Tres fuentes te dan una lista completa en un día. Primero, la factura: exporta un año de datos de facturación agrupados por servicio. Cada servicio que aparece en ella es una dependencia, incluidos los olvidados.

Segundo, tu estado de Terraform. Cuenta los tipos de recurso de cada estado:

terraform state list \
  | sed -E 's/\[[^]]*\]//g' \
  | awk -F. '{print $(NF-1)}' \
  | sort | uniq -c | sort -rn

El prefijo de cada tipo indica el proveedor y el resto, el servicio. Lo que aparece en la factura pero falta aquí se creó a mano, y eso ya es un hallazgo en sí mismo.

Tercero, el código: busca en tus repositorios las importaciones de SDK del proveedor. Cada una es lógica de negocio que habla con un proveedor en lugar de con una interfaz que controlas.

Registra cada dependencia en un fichero guardado en Git junto al código:

- layer: managed-database
  service: managed PostgreSQL 16
  used_by: [orders-api, billing-worker]
  portable_target: any PostgreSQL 16
  blockers:
    - two provider-only extensions
    - database login through provider IAM
  data_volume_tb: 1.4
  cost_to_leave: "3 engineer-weeks, one-off egress, one maintenance window"
  owner: platform-team
  last_reviewed: 2026-10-01

Expresa el coste de salida en semanas de ingeniería y en dinero, no como bajo, medio o alto. Una cifra se puede discutir y corregir después de una prueba.

El plan de salida es un documento que se mantiene

Una estrategia de salida que vive en la cabeza de alguien es una esperanza. Por escrito, ocupa unas pocas páginas por sistema crítico:

• Disparadores. Qué iniciaría una salida (una subida de precio por encima de tu umbral, una disputa contractual, una instrucción del regulador) y quién decide.
• Un destino por capa. Adónde iría cada entrada del inventario, con precisión: "PostgreSQL autogestionado en Kubernetes", no "a otro sitio".
• El plan de datos. Volúmenes, formatos, método y tiempo de transferencia, coste de egress y cómo se sincronizan los cambios mientras funcionan ambos lados.
• Secuencia y rollback. El orden en que se mueven los sistemas, el periodo en paralelo y el punto de no retorno.
• Términos del contrato. Plazos de preaviso y condiciones de recuperación de datos, sacados del contrato firmado.
• Dependencias externas. Allowlists de IP en partners, endpoints hard-coded en clientes, certificados, delegaciones DNS.
• La última prueba. Fecha, resultado y hallazgos abiertos de la prueba de portabilidad más reciente.

Dale un único responsable con nombre, normalmente quien lidera infraestructura o plataforma, con la aprobación de quien gestiona el riesgo de proveedores. Actualiza el inventario cada trimestre, revisa el plan cuando cambie la arquitectura y pruébalo al menos una vez al año. Un plan sin probar es un borrador.

Una prueba de portabilidad que puedes hacer en un sprint

Reconstruye tu entorno de staging desde el código, en otra cuenta o región, y cronométralo. Hacerlo en otro proveedor es la versión completa, pero una cuenta nueva ya destapa la mayoría de los problemas. Cuatro reglas mantienen honesto el resultado:

1. 1Empieza con una cuenta vacía, sin nada creado a mano.
2. 2Solo cuenta lo que está en Git. Cada clic en la consola o valor copiado se registra como hallazgo.
3. 3Restaura los datos desde los backups, no desde la base de datos en producción, para probar también los backups.
4. 4Para el cronómetro cuando pasen los smoke tests, no cuando termine el último apply.

Apunta el mismo código a un nuevo backend de estado y a un nuevo fichero de variables:

terraform init -reconfigure -backend-config=backends/portability-test.hcl
time terraform apply -var-file=env/portability-test.tfvars

Después despliega con tu pipeline habitual y restaura los datos. Los fallos se repiten de un equipo a otro:

• Identificadores hard-coded. IDs de cuenta, nombres de región y nombres de bucket incrustados en el código, en los values de Helm y en las variables del pipeline. Ejecuta antes grep -rnF -e "$ACCOUNT_ID" -e "$REGION" --exclude-dir=.git . en cada repositorio.
• Recursos que nunca estuvieron en el código. Un registro DNS o un rol arreglado en la consola durante un incidente. El apply funciona; la aplicación falla.
• El bootstrap de secretos. El nuevo almacén de secretos está vacío y nadie tiene la lista completa de lo que va dentro.
• Claves de cifrado. Los backups cifrados con una clave que solo puede usar la cuenta original no se restauran en ningún otro sitio.
• Cuotas y orden. Una cuenta nueva empieza con las cuotas por defecto, y las dependencias ocultas por años de applies incrementales aparecen en el primer apply desde cero.
• Imágenes. Descargadas de un registry al que la cuenta nueva no llega, o referenciadas con tags mutables.

Apunta dos cifras: horas desde la cuenta vacía hasta que pasan los smoke tests, y número de pasos manuales. Corrige los principales hallazgos y repite hasta que ambas bajen.

¿Quieres una segunda opinión antes de hacerla? Nuestra evaluación gratuita construye el inventario por capas a partir de tu exportación de facturación y de tu estado de Terraform, pone un coste de salida a cada entrada y señala qué se rompería en una reconstrucción desde cero. Solicita una evaluación gratuita de lock-in.

Gravedad de los datos y egress: haz las cuentas

Es la gravedad de los datos: los jobs, los servicios y los backups que leen tus datos acaban donde viven los conjuntos de datos más grandes, así que el volumen de datos marca el ritmo de cualquier salida. Las cuentas caben en tres líneas:

one-off transfer cost = data_GB x egress_price_per_GB
transfer time (days)  = data_TB x 8000 / (link_Gbps x utilization x 86400)
monthly cross-cloud   = daily_cross_cloud_GB x 30 x egress_price_per_GB

Un ejemplo práctico; sustituye las cifras por las tuyas. Supón que tienes 40 TB en almacenamiento de objetos y 2 TB en bases de datos, y toma 0,08 € por GB como precio de egress de ejemplo. No es un presupuesto: las tarifas reales son escalonadas y cambian.

• Transferencia puntual: 42 000 GB x 0,08 € = 3360 €. Es poco comparado con las semanas de ingeniería de tu inventario.
• Tiempo de transferencia: 42 TB por un enlace de 1 Gbit/s al 50% de utilización sostenida son 42 x 8000 / (1 x 0,5 x 86400), unos 7,8 días pagando ambos entornos y sincronizando cada cambio.
• Tráfico continuo entre nubes: un diseño active-active que envía 500 GB al día entre proveedores cuesta 500 x 30 x 0,08 € = 1200 € al mes, mientras exista esa arquitectura.

La línea puntual rara vez bloquea una salida; la ventana de transferencia, sí. La línea mensual es el precio de funcionar en dos proveedores por diseño, una decisión distinta de conservar la capacidad de irte.

Portabilidad pragmática: invierte donde compensa

Compra portabilidad donde el coste de salida es alto o no tiene límite. Acepta el lock-in donde está acotado y el servicio gestionado te ahorra trabajo cada semana.

Kubernetes para las cargas de trabajo, no como promesa

Los Deployments, Services y ConfigMaps se mueven entre clusters conformes. Las anotaciones de ingress, las storage classes y la identidad de las cargas de trabajo no, así que mantenlas en un overlay fino por entorno (Kustomize o values de Helm).

Módulos de Terraform con una interfaz estable

El HCL es igual en todos los proveedores; los recursos no. Lo que ayuda es un límite de módulo por componente (red, cluster, base de datos) con el código específico del proveedor dentro y outputs estables, de modo que un segundo destino sea una nueva implementación y no una reescritura de todo lo que lo llama:

module "orders_db" {
  source = "./modules/postgres/managed" # or ./modules/postgres/self-managed
  name   = "orders"
  tier   = "medium"
}

# callers only ever depend on this output
output "orders_db_host" {
  value = module.orders_db.host
}

Que lo escribas en HCL o en un lenguaje de propósito general importa menos que ese límite; nuestra comparativa Terraform vs Pulumi trata esa elección, y diseñar interfaces de módulo que sobrevivan a un cambio de proveedor es una parte central de nuestra consultoría de Terraform.

Formatos abiertos e identidad portable

Guarda una copia de los datos críticos en un formato que cualquier destino pueda leer, y restáurala de forma periódica: un dump de PostgreSQL en formato directorio para las bases de datos, Parquet para los datos analíticos.

pg_dump --format=directory --jobs=4 --file=/backup/orders "$DATABASE_URL"

Tu personal inicia sesión con tu propio proveedor de identidad, federado en cada nube mediante SAML u OIDC; el CI usa federación OIDC en lugar de claves de larga duración. Las políticas no se traducen, así que documenta la intención (qué servicio lee qué datos) en el repositorio.

Cuándo la abstracción cuesta más que el lock-in

Supón que autogestionar PostgreSQL para evitar un servicio gestionado cuesta medio día a la semana en parches, backups y simulacros de failover: unos 25 días de ingeniería al año. Supón que mover un PostgreSQL gestionado a otro proveedor es un proyecto acotado de 15 días que quizá nunca necesites. Pagar 25 días al año para asegurarte contra un posible proyecto de 15 días es un mal negocio. La misma lógica descarta las abstracciones caseras sobre las colas de varios proveedores. Dedica el esfuerzo a donde el coste de salida no tiene límite: modelos de datos propietarios y lógica de negocio enterrada en el pegamento de los workflows.

Cuándo está justificado un segundo proveedor

Un segundo proveedor compensa su coste cuando:

• La regulación o la residencia de datos exige datos o procesamiento en un país donde tu proveedor principal no tiene región.
• Un cliente o un contrato lo exige: desplegar en el propio tenant cloud del cliente, o una licitación pública que especifica un proveedor que no usas.
• Una adquisición trae una empresa que funciona en otra nube; integra primero la identidad y consolida según un calendario.
• Una capacidad que solo tiene un proveedor es central para tu producto; aíslala detrás de una interfaz que controles.

No compensa para "evitar el lock-in" en general (un plan de salida y una reconstrucción probada lo consiguen más barato), para ganar resiliencia mientras sigues en una sola región (añade primero una región) ni como palanca de negociación (repartir el gasto debilita el compromiso que puedes ofrecer a cada proveedor). Si todavía estás eligiendo tu proveedor principal, nuestra comparativa de AWS, Azure y GCP recoge los criterios.

La perspectiva europea: DORA y el EU Data Act

Si eres una entidad financiera de la UE, el reglamento DORA (Digital Operational Resilience Act) se aplica desde el 17 de enero de 2025 y exige estrategias de salida para los proveedores terceros de TIC críticos. Es probable que tu proveedor cloud sea uno de ellos. Una estrategia de salida no es un segundo proveedor funcionando en paralelo; es una salida documentada y probada, y el inventario, el plan y la prueba de arriba son su contenido. Si vendes a entidades financieras, cuenta con que su planificación de salida te llegue en forma de cláusulas contractuales.

El EU Data Act se aplica desde el 12 de septiembre de 2025. Obliga a los proveedores cloud a hacer posible el cambio de proveedor, limita los cargos por cambio al coste durante un periodo transitorio y los suprime a partir del 12 de enero de 2027. Eso reduce lo que un proveedor puede cobrarte por irte. No hace nada por tu coste de ingeniería: las políticas de IAM, el pegamento serverless y los IDs de cuenta hard-coded son igual de difíciles de mover que antes.

Tu primer mes

• Semana 1: exporta la factura, lista tu estado de Terraform y construye el inventario con un coste de salida por entrada.
• Semana 2: escribe la primera versión del plan de salida y asígnale un responsable.
• Semana 3: haz la prueba de portabilidad en staging y registra cada paso manual.
• Semana 4: corrige los principales hallazgos, haz las cuentas del egress con tus volúmenes reales y decide si algo justifica un segundo proveedor.

Nuestros equipos de migración a la nube y de infraestructura pueden hacer contigo esa primera pasada. Solicita una evaluación gratuita de lock-in: revisamos tu exportación de facturación, tu estado de Terraform y el cifrado de tus backups, estimamos el coste de salida por capa, hacemos las cuentas del egress con tus volúmenes y, si eres una entidad financiera, contrastamos tu plan de salida con lo que pide DORA.