Pregúntale a diez equipos de infraestructura si tienen una estrategia de salida cloud y nueve dirán que sí. Pregunta en qué consiste y normalmente obtendrás una página de wiki escrita durante una revisión de proveedores, con la lista de qué servicios son propietarios y cuáles son portables. Eso es un inventario, no una estrategia. La prueba real es menos cómoda: si tu proveedor duplicara sus precios, cambiara de jurisdicción, o suspendiera tu cuenta un martes por la mañana, ¿cuántas semanas pasarían hasta que sirvieras tráfico en otro sitio - y quién de tu equipo puede responder eso sin abrir una hoja de cálculo?
La presión regulatoria aquí es real, pero no es la parte interesante. La Data Act está eliminando los cargos por cambio de proveedor, lo que le quita la excusa al departamento financiero. Schrems II y la CLOUD Act le quitaron la excusa legal hace años. Lo que queda es la realidad de la ingeniería, y ninguna directiva arregla eso. Un regulador puede hacer que irse sea más barato sobre el papel; no puede hacer que tu pipeline de despliegue, tu modelo de identidad, tus registros DNS y tu proceso de restauración funcionen en un segundo proveedor. Ese trabajo es tuyo, y es el coste completo.
Qué es en realidad una estrategia de salida cloud
Una estrategia de salida es una propiedad medible de tu arquitectura, no un documento. La medición es directa: ¿qué proporción de tu infraestructura en marcha podrías levantar en otro proveedor, usando herramientas que ya operas, sin escribir código nuevo? Para la mayoría de equipos, la respuesta honesta se sitúa entre el cuarenta y el setenta por ciento, y la brecha nunca está donde esperaban. Rara vez es la aplicación. Es la base de datos gestionada, la cola, la semántica del almacenamiento de objetos, y los once pequeños hábitos operativos que nadie escribió nunca.
El modo de fallo es creer que tener dos proveedores demuestra algo. Muchas empresas ejecutan producción en un hyperscaler y un proyecto de pruebas olvidado en algún otro sitio, y luego llaman al resultado multicloud. La opcionalidad no es la existencia de una segunda cuenta; es la capacidad de ejercerla. Hasta que una carga de trabajo real - con monitorización, copias de seguridad, un turno de guardia y una restauración que de verdad hayas realizado - se ejecute en un sitio distinto de tu proveedor principal, tienes una segunda factura, no una segunda opción.
Las tres cosas que hacen difícil la salida
Primero, la gravedad de los datos, que es aburrida y decisiva. Copiar bytes es barato, pero moverlos de forma consistente mientras un sistema está en producción es caro. En el momento en que tus datos residen dentro de un servicio gestionado propietario, la salida deja de ser una copia y se convierte en reescribir todo lo que habla con él. Por eso los equipos que mantienen su estado en algo que ellos mismos podrían operar - aunque hoy elijan no hacerlo - conservan opciones que los equipos en stacks totalmente gestionados van perdiendo silenciosamente con los años.
Segundo, la memoria muscular operativa. Tu equipo conoce el modelo de identidad de un proveedor, una abstracción de firewall, una forma de nombrar redes, la disposición de una consola a las tres de la madrugada. Cambia a un segundo proveedor y todo eso deja de ser familiar justo cuando más presión hay. El coste no es el fin de semana de migración; son los seis meses siguientes de incidentes gestionados un poco más despacio por gente que va adivinando. Nadie incluye eso en la estimación de una migración, y suele ser la partida más grande.
Tercero, la atribución de costes. La mayoría de los equipos no puede decirte cuánto cuesta hoy una sola carga de trabajo, lo que hace que comparar proveedores sea imposible en principio. Si tu factura es una cifra por proveedor y tu arquitectura tiene cuarenta servicios, la conversación sobre salir degenera en intuiciones. Antes de poder calcular el coste de una salida necesitas el gasto desglosado por servicio, proyecto y entorno, en todos los proveedores que usas, incluidos los pequeños que se te olvidaron. Es un trabajo de base poco vistoso, y es un requisito previo para cualquier otra decisión de este tipo.
Cómo evitar el vendor lock-in de proveedores cloud en la UE
Si quieres evitar el vendor lock-in de proveedores cloud, el mercado europeo está en mejor forma de lo que la mayoría de los equipos asume. La relación precio-rendimiento de Hetzner hace que las facturas de los hyperscalers parezcan un error de redondeo en la dirección equivocada. OVHcloud opera sus propios centros de datos y fibra por toda Europa. Scaleway ofrece una experiencia de desarrollador genuinamente moderna desde Francia. UpCloud entrega cómputo fiable desde Finlandia. Ninguno de ellos sustituye todos los servicios de un hyperscaler - pero para cómputo, almacenamiento en bloque y redes, que es donde realmente va la mayor parte del dinero de infraestructura, son creíbles y responden únicamente ante la ley de la UE.
El límite honesto son los servicios gestionados. Si tu producto está construido sobre una base de datos serverless propietaria, un bus de eventos específico o una plataforma de machine learning sin equivalente en otro sitio, ninguna cantidad de entusiasmo europeo va a cambiar eso en un trimestre. El movimiento útil no es una migración heroica de todo o nada. Es saber exactamente qué cargas de trabajo son portables hoy, ejecutar algunas donde la jurisdicción y el precio te convengan, y tratar el resto como una decisión deliberada y documentada en lugar de un accidente de la historia.
En qué consiste de verdad un simulacro de salida
Trátalo como un simulacro de restauración, porque eso es exactamente lo que es. Elige una carga de trabajo real - no la web de marketing, algo con estado y un runbook. Levántala en un segundo proveedor. Dirígele una fracción de tráfico real. Rómpela deliberadamente y comprueba si tu monitorización, tu modelo de acceso y tu turno de guardia también funcionan ahí. Después anota el tiempo real transcurrido y todo lo que te sorprendió. Un simulacro que no produce sorpresas suele significar que elegiste algo demasiado fácil.
La razón por la que la mayoría de los equipos nunca ensaya no es la pereza, son las herramientas. Cada proveedor adicional significa otra consola, otro modelo de credenciales, otra exportación de facturación, otro conjunto de peculiaridades que aprender - y un equipo de plataforma pequeño no puede absorber eso una vez por cada cloud. Este es el impuesto operativo que convierte silenciosamente una conversación sobre soberanía en el problema del año que viene, cada año. Es también, precisamente, el problema que se supone que un plano de control debe quitarte de encima.
Eso es lo que hemos construido con Sencai. Un plano de control sobre once proveedores - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode de Akamai y Oracle Cloud - además de tus propios servidores a través de un agente instalado en el host. Las redes, los firewalls y el DNS se gestionan donde realmente viven, en el proveedor, de modo que un segundo proveedor se convierte en una casilla más en la misma interfaz en lugar de en un segundo equipo de plataforma. El gasto se controla por organización con topes, así que la conversación sobre la salida tiene cifras de verdad.
Puedes ejecutar esto sobre tus propias cuentas de proveedor, o comprar la capacidad a través de nosotros y quedarte con una sola factura - ambas opciones están soportadas, y la elección es tuya y puedes cambiarla más adelante. En cualquier caso, el resultado es el mismo, y es la única cifra que merece la pena reportar hacia arriba: cuánto tardarías en estar funcionando en otro sitio. Mídelo una vez y deja de ser un miedo. Mídelo cada trimestre y se convierte en palanca de negociación - en una negociación, en una revisión de compras, y el día en que algo te obligue a plantearte la pregunta.