O Google criou um agente para tirar seu Kubernetes da AWS. Agentes de migração tornam o plano de saída real

Todo contrato de nuvem tem cláusula de saída, e quase nenhuma empresa acredita nela. Sair de uma nuvem significa meses de engenharia reversa, tradução e testes, e o plano de saída vira um documento parado na matriz de riscos. O lançamento de modernização do Google em 5 de outubro inclui um agente cujo trabalho é baratear uma saída específica: levar workloads de Kubernetes do Amazon EKS para o Google Kubernetes Engine.

O que o Google anunciou

Dentro do Google Cloud Modernize, descrito num post de Souvik Choudhury e Tom Nikl, o Google apresentou a EKS-to-GKE Agentic Migration, em Public Preview. Segundo o Google, ela:

• cuida de descoberta, tradução de manifestos Kubernetes e mapeamento de armazenamento e rede entre as nuvens, num pipeline automatizado;
• tem portões de aprovação humana e credenciais mantidas só em memória, para preservar um GitOps rigoroso.

Junto veio o Agentic Quick Estimator, já em GA, que transforma exportações de inventário VMware, como as do RVTools, em projeções de TCO no Compute Engine. O Google diz que ele condensa semanas de planilha em “um business case defensável em minutos”. É a descrição que o Google faz da própria ferramenta de venda; trate o resultado como ponto de partida, não como o business case.

O custo de sair está caindo, dos dois lados da mesa

1. Descoberta só leitura na conta de origem
2. Traduz manifestos, mapeia armazenamento e rede
3. Mudanças propostas como pull requests
4. Time de plataforma aprova e faz o merge
5. GitOps aplica no GKE
6. Decisão de cutover e de rollback

• Autonomia do agente: Descoberta só leitura na conta de origem · Traduz manifestos, mapeia armazenamento e rede · Mudanças propostas como pull requests
• Autoridade humana: Time de plataforma aprova e faz o merge · GitOps aplica no GKE · Decisão de cutover e de rollback

Trabalho do agentePipeline que você já controla

Migração é trabalho braçal, e trabalho braçal é o que agentes comprimem. A arquitetura da AWS que analisamos em agentes de migração com playbooks leva workloads para dentro da AWS; o agente do Google leva para fora. Espere que cada hyperscaler lance o seu, mirando os concorrentes. O efeito colateral importa mais do que qualquer ferramenta: o custo de trocar de nuvem está caindo, e isso muda três coisas.

O plano de saída passa a ser testável. Plano de saída nunca ensaiado é esperança. Se um agente traduz um cluster representativo em dias, dá para ensaiar uma vez por ano num workload não crítico e registrar quanto tempo levou. Para instituições reguladas pelo Banco Central, isso conversa direto com a Resolução CMN 4.893, que já exige que contratos relevantes de nuvem prevejam a transferência dos dados quando o contrato termina. Um ensaio medido é a melhor evidência de que essa cláusula funciona na prática.

A negociação muda. Uma saída crível e medida é poder de barganha na renovação. Funciona também ao contrário: quem constrói o agente quer os seus workloads, e o estimador de TCO faz parte do processo de venda. Refaça as contas com o seu time financeiro, com câmbio e impostos de importação de serviços incluídos, antes que elas cheguem ao conselho.

Compromissos de consumo continuam pesando. Gasto comprometido, créditos de marketplace e descontos prendem você ao provedor muito depois de a tecnologia permitir a saída. Trocar de nuvem mais barato não ajuda se o contrato torna a saída cara.

Onde a autonomia deve parar

As escolhas de desenho do Google são as certas, e valem para qualquer agente de infraestrutura:

• Credenciais. O agente precisa acessar a conta AWS para descobrir o que roda lá. Dê a ele um papel dedicado, só leitura, restrito aos clusters em questão e com prazo de validade. Credencial “só em memória” significa que ela não fica guardada, não que ela pode menos enquanto está em uso.
• GitOps como fronteira. O agente propõe; o repositório e o pipeline aplicam. A saída dele deve chegar como mudança revisável, nunca como escrita direta no cluster de destino.
• O que a tradução não enxerga. Manifestos são a parte fácil. Papéis de IAM ligados a service accounts, controladores de load balancer, classes de armazenamento, configurações de segurança de pods e os serviços gerenciados que os workloads chamam (filas, bancos, segredos) mudam de uma nuvem para outra. Pergunte quais desses o preview cobre e teste o resto à mão. Se o destino for a região de São Paulo do Google Cloud, confirme também se o próprio preview opera nela.

O que fazer agora

1. Ensaie uma saída por ano num workload não crítico e registre tempo e esforço.
2. Restrinja as credenciais do agente a só leitura, por cluster e com prazo.
3. Mantenha o GitOps como único caminho de escrita no cluster de destino.
4. Liste as dependências específicas da nuvem que os manifestos não cobrem antes de aceitar um cronograma.
5. Refaça o TCO do fornecedor com premissas financeiras suas, em reais.
6. Leia os compromissos de consumo junto com o plano técnico de saída; os dois decidem se você consegue sair.

Para fechar

Agentes de migração estão sendo construídos para ganhar workloads, mas o maior presente que dão às empresas é uma saída crível. Use o preview do Google, ou os equivalentes de outras nuvens, para transformar o plano de saída num ensaio medido, e mantenha a autoridade do agente terminando no pull request.