Migración a cloud soberana europea
Se puede reducir la dependencia de un hiperescalador no europeo trasladando las cargas de trabajo a proveedores europeos como Exoscale, STACKIT u OVHcloud, y el modo de que la migración no cree una dependencia nueva es apoyarla en Kubernetes e infraestructura como código. Empezamos por una evaluación honesta: qué servicios tienen equivalente, qué os ata de verdad al proveedor actual, qué cuesta moverlo y qué funcionalidad se pierde. Si el resultado es que no compensa, lo decimos en el mismo informe.
Última actualización:
Qué ata de verdad a un hiperescalador
Para quién es
Para empresas tecnológicas que tienen una razón concreta para mover la infraestructura a Europa: un cliente del sector público que lo pide en el pliego, un requisito de sector regulado, el riesgo de depender de una jurisdicción que no es la vuestra, o simplemente una factura que ha crecido sin que nadie la discuta.
Qué problema resuelve
Que salir de un hiperescalador es difícil a propósito. Lo que ata no es la máquina virtual, que se mueve en una tarde: son los servicios gestionados que no tienen equivalente exacto, el coste de sacar los datos, las funciones serverless atadas a su ecosistema, la gestión de identidades y la cantidad de configuración que vive en la consola web y no en ningún repositorio. Si eso no se inventaria antes, la migración se convierte en un proyecto sin final.
La parte que importa: no repetir el problema
Cambiar de proveedor para volver a atarse al siguiente no resuelve nada. Por eso la arquitectura se apoya en Kubernetes, Terraform y servicios con interfaz estándar —S3, Postgres, Kafka— y la configuración vive entera en vuestro repositorio. El criterio para dar la migración por buena es poder repetirla: si mover la infraestructura a un tercer proveedor volvería a ser un proyecto de meses, algo se ha hecho mal.
En qué se diferencia de Independencia Cloud
Independencia Cloud es para la empresa que quiere salir de Microsoft 365, Google Workspace o AWS en lo que afecta a su trabajo de oficina: correo, archivos, ofimática, videollamadas. Esto es para la empresa que tiene producto propio corriendo en un hiperescalador y quiere moverlo sin que se note. Si os encajan las dos, se empieza por la que tenga el plazo encima.
Las tres fases del trabajo
Evaluación
Inventario de servicios en uso, equivalencia en cada proveedor europeo candidato, coste de salida de los datos y lista de lo que no tiene equivalente.
Arquitectura portable
Kubernetes e infraestructura como código, con interfaces estándar y la configuración entera en vuestro repositorio. Nada que solo exista en una consola web.
Migración por fases
Entorno nuevo, convivencia, traslado por servicios y corte cuando se confirma. Con plan de vuelta atrás en cada fase, no solo al principio.
Qué entregamos
El informe de evaluación
Servicio a servicio: qué usáis, qué proveedor europeo lo cubre y con qué diferencias, qué habría que reconstruir, qué cuesta sacar los datos y cuánto trabajo es cada pieza. Con una comparativa de los candidatos —Exoscale, STACKIT, OVHcloud y otros según el caso— en lo que de verdad os afecta: regiones, certificaciones, catálogo gestionado, red y soporte.
La arquitectura
Diseño documentado del destino, con el código de Terraform y los manifiestos que lo levantan. Red, almacenamiento, copias, identidades, secretos, observabilidad y despliegue, escritos de forma que se puedan volver a aplicar en otro proveedor.
La migración
Por fases y con presupuesto cerrado calculado desde la evaluación. Convivencia de los dos entornos mientras haga falta, traslado de datos con ventana acordada y corte solo cuando el destino ya ha estado sirviendo tráfico real.
Cuándo NO compensa
Si vuestro producto se apoya en servicios propietarios sin equivalente y reconstruirlos cuesta más que el problema que resolvéis; si tenéis una certificación montada encima de la infraestructura actual; o si el gasto es lo bastante pequeño como para que la migración no se pague nunca. Sale en el informe, y es una conclusión tan válida como la contraria.
Cómo trabajamos
Inventario
Qué hay desplegado, qué servicios gestionados se usan y cuánta configuración vive fuera de un repositorio.
Evaluación y candidatos
Equivalencias, coste de salida, comparativa de proveedores europeos y estimación de esfuerzo. Aquí se decide si sigue.
Arquitectura y entorno nuevo
Destino levantado con Terraform y Kubernetes, con copias, observabilidad y despliegue funcionando antes de mover nada.
Traslado y corte
Servicio a servicio, con convivencia, tráfico real en el destino y vuelta atrás disponible hasta el último momento.
Preguntas frecuentes
¿Hay que irse del todo o se puede quedar a medias?
Se puede, y muchas veces es lo razonable: mover lo que tiene equivalente claro y dejar en el proveedor actual lo que reconstruir costaría más de lo que ahorra. La evaluación dice qué pieza está en cada grupo.
¿Esto nos deja «soberanos»?
Depende de lo que os pidan. Un proveedor europeo con regiones europeas y sociedad europea resuelve bastantes requisitos de pliego y de contrato, pero «soberanía» significa cosas distintas en distintos sectores. Si tenéis el requisito por escrito, lo leemos y decimos qué cubre la arquitectura propuesta y qué no.
¿Vamos a pagar menos?
Puede que sí, pero no es el motivo principal ni lo vendemos como tal. La comparativa de coste va en el informe sobre vuestras propias cifras, incluyendo lo que cuesta operar el destino, que es la parte que se suele olvidar.
¿Kubernetes es obligatorio?
No. Es la forma más habitual de que una carga de trabajo se pueda mover sin reescribirla, pero si lo que tenéis son unas pocas máquinas y una base de datos, meter Kubernetes de por medio añade un problema en lugar de quitarlo.
¿Hace falta cambiar de proveedor de cloud para empezar?
No. El trabajo de fiabilidad se hace sobre lo que ya tenéis, sea AWS, Azure, Google Cloud, un proveedor europeo o vuestro propio hardware. La migración es otro servicio y solo tiene sentido si hay una razón para hacerla.
¿Cuánto tardamos en notar algo?
Lo primero que se nota es el ruido: una revisión de alertas suele dar resultado en las primeras semanas, porque buena parte de las que suenan no son accionables. Los SLOs tardan más, porque antes hay que medir, y no sirven de nada hasta que hay unas semanas de datos detrás.
¿Firmáis un acuerdo de confidencialidad?
Sí, si lo queréis, y nada de lo que veamos se usa como ejemplo en ningún sitio sin permiso por escrito. Los accesos se piden al mínimo necesario y se documentan.
Pide la evaluación de salida
Dinos en qué proveedor estáis y qué servicios gestionados usáis. Respondemos en menos de 24 horas laborables con el alcance de la evaluación y el plazo.
o escríbenos a info@esdis.es