- La IA hace la traducción. El pipeline decide qué entra 🔎
- Nada de “confía en la IA y pulsa Enter” 🛡️
- Google está tratando la migración como una compilación ⚙️
- ¿Por qué empezar por AWS? ☁️
- ¿Y dónde entra el open source? 🧩
- Dos piezas de una estrategia mayor 🤖
- El movimiento también dice mucho sobre los agentes de IA 🧠
- Menos trabajo manual, pero no menos responsabilidad
Principales destacados
- Migración automatizada: la herramienta open source traduce configuraciones de AWS EKS y manifiestos de Kubernetes para entornos compatibles con Google Kubernetes Engine.
- IA con validación: el sistema combina LLM con verificaciones deterministas y propone cambios mediante pull requests, sin modificar directamente los clústeres en producción.
- Una estrategia mayor: el lanzamiento forma parte de una ofensiva de Google para ampliar el uso de software open source y acercar a los desarrolladores a su infraestructura de nube e IA.
Migrar una aplicación entre nubes nunca ha sido exactamente como cambiarse de apartamento. Hay que trasladar configuraciones, identidades, redes, balanceadores, permisos y toda esa infraestructura que normalmente solo aparece cuando algo falla.
Google quiere hacer que este proceso sea menos doloroso.
La compañía lanzó una herramienta open source capaz de automatizar parte de la migración de cargas de trabajo de Kubernetes ejecutadas en AWS hacia Google Kubernetes Engine, GKE.
La idea es utilizar IA para realizar la traducción, pero sin entregarle a la IA las llaves del clúster.
La IA hace la traducción. El pipeline decide qué entra 🔎
La herramienta combina el razonamiento de grandes modelos de lenguaje con validaciones deterministas.
En la práctica, analiza infraestructura como código y manifiestos utilizados en Amazon EKS y produce configuraciones adaptadas al entorno de GKE.
Entre sus tareas se encuentran:
• traducir configuraciones de identidad de AWS a Workload Identity de Google;
• convertir configuraciones de ingress y balanceo a Gateway API;
• adaptar configuraciones relacionadas con el aprovisionamiento de nodos;
• verificar los cambios antes de que sean aplicados.
El detalle más importante está precisamente en lo que no sucede.
La herramienta no sale modificando directamente un clúster en producción.
Nada de “confía en la IA y pulsa Enter” 🛡️
En su lugar, los cambios se convierten en pull requests.
Esto permite que el equipo responsable revise el resultado y lo someta a los procesos tradicionales de CI/CD antes de la implementación.
💡 La propuesta es colocar una capa de ingeniería entre la sugerencia de la IA y la infraestructura real.
Es una respuesta a uno de los problemas más delicados de la automatización basada en agentes: incluso cuando un modelo consigue producir código aparentemente correcto, la infraestructura de producción exige algo más que una respuesta plausible.
Una configuración incorrecta de identidad, red o balanceo puede convertir una migración aparentemente sencilla en una madrugada bastante larga para el equipo de infraestructura.
Google está tratando la migración como una compilación ⚙️
La herramienta fue presentada como un plugin de agente de código abierto basado en el Model Context Protocol, MCP.
La comparación realizada por Persistent es particularmente interesante.
Rahul Shrivastava, vicepresidente ejecutivo de la compañía, describió la solución como una especie de “fábrica de migración con nivel de compilador”, con resultados verificables.
La analogía ayuda a entender la arquitectura.
En lugar de simplemente pedirle a un chatbot “convierte este YAML de AWS para GCP”, el proceso intenta transformar la migración en una secuencia más controlada de traducción, validación y revisión.
Esto acerca la IA a las herramientas tradicionales de ingeniería de software.
¿Por qué empezar por AWS? ☁️
La elección tiene sentido dentro de la estrategia de Google Cloud.
Las empresas que ya ejecutan Kubernetes en AWS tienen una barrera técnica considerable para cambiar de proveedor. No basta con mover los contenedores: diferentes servicios de infraestructura, identidad, red y aprovisionamiento deben ser adaptados.
El costo de esta adaptación puede ayudar a mantener a una empresa vinculada a su proveedor original.
La herramienta intenta atacar precisamente esa fricción.
Cuanto más automatizada sea la conversión, menor será el trabajo necesario para evaluar una migración a GKE.
Pero existe una diferencia importante entre automatizar la traducción y automatizar una migración completa. La herramienta reduce una parte del trabajo técnico; no elimina la necesidad de probar aplicaciones, validar la arquitectura, evaluar costos y revisar dependencias específicas del entorno.
¿Y dónde entra el open source? 🧩
El lanzamiento también se produce en un momento de expansión de la estrategia open source de Google.
En ROSCon 2026, celebrada en Toronto entre el 22 y el 24 de septiembre, la división Intrinsic de Google anunció Intrinsic Core, un conjunto de capacidades para robótica industrial compatibles con Robot Operating System y disponibles bajo la licencia Apache 2.0.
El paquete incluye componentes relacionados con:
• control;
• planificación de movimiento;
• planificación de agarre;
• simulación;
• estimación de pose.
Anteriormente, estas capacidades eran propietarias.
Dos piezas de una estrategia mayor 🤖
Los dos lanzamientos pertenecen a áreas diferentes, pero siguen una lógica similar.
Por un lado, Google abre herramientas capaces de reducir barreras técnicas para desarrolladores y empresas.
Por otro, crea caminos para que esas mismas organizaciones utilicen su infraestructura comercial.
En el caso de GKE, el objetivo es bastante claro: workloads que actualmente se ejecutan en AWS.
En el caso de la robótica, la apuesta es crear una capa abierta sobre la que los desarrolladores puedan construir aplicaciones y, potencialmente, utilizar componentes de IA e infraestructura ofrecidos por el ecosistema de Google.
La estrategia recuerda una vieja fórmula de la industria tecnológica: hacer más accesible la capa básica y aumentar el valor de las capas que están por encima.
El movimiento también dice mucho sobre los agentes de IA 🧠
Hay un cambio importante escondido en este lanzamiento.
La discusión sobre los agentes de IA está dejando de ser simplemente “¿el modelo puede escribir código?” y avanzando hacia una pregunta más difícil:
¿qué ocurre cuando ese código controla infraestructura real?
En este escenario, generar código no es suficiente.
Es necesario contar con validación, trazabilidad, revisión humana e integración con los procesos que ya protegen los entornos de producción.
La arquitectura adoptada por Google intenta precisamente combinar autonomía con estos mecanismos de control.
Menos trabajo manual, pero no menos responsabilidad
Para empresas que poseen grandes entornos de Kubernetes en AWS, esto puede reducir una parte significativa del trabajo repetitivo de una migración.
Pero la decisión de cambiar de nube continúa siendo mucho más grande que convertir archivos de configuración.
Costos, rendimiento, dependencias propietarias, requisitos de seguridad, contratos, observabilidad y arquitectura siguen formando parte de la ecuación.
La IA puede ayudar a desmontar una de las barreras más laboriosas del cambio.
La cuestión es si, al hacerlo, también conseguirá transformar la migración entre nubes de un proyecto de meses en algo mucho más parecido a un proceso de ingeniería automatizado.
Y es precisamente ahí donde la herramienta de Google comienza a resultar interesante: no como un botón de “migrar a GKE”, sino como un intento de transformar la migración en algo que una máquina pueda traducir, verificar y entregar a los humanos para su aprobación.
