Google crea un agente para sacar su Kubernetes de AWS. Los agentes de migración hacen real el plan de salida

Todo contrato de nube tiene una cláusula de salida, y casi ninguna empresa se la cree. Abandonar una nube supone meses de ingeniería inversa, traducción y pruebas, así que el plan de salida se queda en un documento del registro de riesgos. El lanzamiento de modernización de Google del 5 de octubre incluye un agente cuyo único trabajo es abaratar una salida concreta: llevar cargas de Kubernetes de Amazon EKS a Google Kubernetes Engine.

Qué ha anunciado Google

Dentro de Google Cloud Modernize, descrito en un artículo de Souvik Choudhury y Tom Nikl, Google presentó EKS-to-GKE Agentic Migration, en Public Preview. Según Google:

• gestiona el descubrimiento, la traducción de manifiestos de Kubernetes y el mapeo de almacenamiento y red entre nubes en un pipeline automatizado;
• incluye puntos de aprobación humana y credenciales que solo se mantienen en memoria, para preservar un GitOps estricto.

Junto a él llega Agentic Quick Estimator, ya en disponibilidad general, que convierte exportaciones de inventario de VMware, como las de RVTools, en proyecciones de coste total de propiedad en Compute Engine. Google dice que condensa semanas de hojas de cálculo en “un caso de negocio defendible en minutos”. Es la descripción que hace Google de su propia herramienta comercial; trate el resultado como punto de partida, no como el caso de negocio.

El coste de salir baja, a ambos lados de la mesa

1. Descubrimiento de solo lectura en origen
2. Traduce manifiestos, mapea almacenamiento y red
3. Cambios propuestos como pull requests
4. El equipo de plataforma aprueba y fusiona
5. GitOps aplica en GKE
6. Decisión de corte y de rollback

• Autonomía del agente: Descubrimiento de solo lectura en origen · Traduce manifiestos, mapea almacenamiento y red · Cambios propuestos como pull requests
• Autoridad humana: El equipo de plataforma aprueba y fusiona · GitOps aplica en GKE · Decisión de corte y de rollback

Trabajo del agentePipeline que ya controla

La migración es trabajo intensivo, y eso es justo lo que comprimen los agentes. La arquitectura de AWS que analizamos en agentes de migración con playbooks lleva cargas hacia AWS; el agente de Google las saca de AWS. Es de esperar que cada hiperescalador lance el suyo apuntando a sus competidores. El efecto secundario importa más que cualquier herramienta: cambiar de nube cuesta cada vez menos, y eso cambia tres cosas.

El plan de salida se puede probar. Un plan de salida nunca ensayado es una esperanza. Si un agente traduce un clúster representativo en días, se puede ensayar una vez al año con una carga no crítica y registrar cuánto se tardó. Para una entidad financiera europea, un ensayo medido es además la mejor evidencia de la estrategia de salida que DORA exige para los servicios TIC críticos.

La regulación europea empuja en la misma dirección. Las reglas de cambio de proveedor de la Ley de Datos de la UE se aplican desde el 12 de septiembre de 2025, y a partir del 12 de enero de 2027 los proveedores ya no podrán cobrar cargos por cambio, incluida la salida de datos. Cuando la barrera contractual y la técnica bajan a la vez, la salida deja de ser teórica para las empresas en España y en el resto de la UE. En Latinoamérica la Ley de Datos no aplica, así que allí la palanca es sobre todo técnica y de negociación.

La negociación cambia, y los compromisos siguen pesando. Una salida creíble y medida da poder en la renovación. También funciona al revés: quien construye el agente quiere sus cargas, y su estimador de costes forma parte del proceso de venta. Rehaga las cuentas con su equipo financiero. Y recuerde que el gasto comprometido y los descuentos atan al proveedor mucho después de que la tecnología permita salir.

Dónde debe detenerse la autonomía

Las decisiones de diseño de Google son las correctas, y sirven para cualquier agente de infraestructura:

• Credenciales. El agente necesita acceder a la cuenta de AWS para descubrir qué se ejecuta allí. Dele un rol dedicado, de solo lectura, limitado a los clústeres implicados y con caducidad. Que la credencial esté “solo en memoria” significa que no se guarda, no que pueda hacer menos mientras se usa.
• GitOps como frontera. El agente propone; el repositorio y el pipeline aplican. Su resultado debe llegar como cambios revisables, nunca como escrituras directas en el clúster de destino.
• Lo que la traducción no ve. Los manifiestos son la parte fácil. Los roles de IAM ligados a cuentas de servicio, los controladores de balanceo de carga, las clases de almacenamiento, la seguridad de los pods y los servicios gestionados que usan las cargas (colas, bases de datos, secretos) cambian entre nubes. Pregunte cuáles cubre la vista previa y pruebe el resto a mano.

Qué hacer ahora

1. Ensaye una salida al año con una carga no crítica y registre tiempo y esfuerzo.
2. Limite las credenciales del agente a solo lectura, por clúster y con caducidad.
3. Mantenga GitOps como único camino de escritura en el clúster de destino.
4. Enumere las dependencias propias de cada nube que los manifiestos no cubren antes de aceptar un calendario.
5. Rehaga el coste estimado por el proveedor con sus propias hipótesis financieras.
6. Revise los cargos por cambio de su contrato a la luz de la Ley de Datos y de la fecha de enero de 2027.

En resumen

Los agentes de migración se construyen para ganar cargas, pero su mayor regalo para las empresas es una salida creíble. Use la vista previa de Google, o sus equivalentes en otras nubes, para convertir el plan de salida en un ensayo medido, y mantenga la autoridad del agente terminando en el pull request.