O agente da AWS agora reescreve código .NET do Azure para a AWS. Trocar as chamadas do SDK é a parte fácil

Aponte um agente para um aplicativo .NET que lê do Azure Blob Storage, processa mensagens do Azure Queue Storage em Azure Functions e grava no Cosmos DB. Peça que ele faça o aplicativo rodar na AWS. O agente encontra cada chamada do SDK do Azure, propõe um equivalente na AWS, espera sua aprovação e reescreve o código. O aplicativo compila. Ele se comporta igual?

Em 16 de outubro, a AWS tornou a conversão de código do SDK do Azure para o SDK da AWS em disponibilidade geral (GA) no AWS Transform, seu agente de modernização .NET. O agente analisa um aplicativo .NET nativo de nuvem, encontra dependências do Azure suportadas, apresenta opções de conversão em um relatório de avaliação e plano de modernização que o usuário aceita ou ajusta, converte o código e verifica se as mudanças foram incorporadas. Três conversões estão em disponibilidade geral (GA): Azure Functions para AWS Lambda, Azure Blob Storage para Amazon S3 e Azure Queue Storage para Amazon SQS. Cosmos DB para DynamoDB está em preview. O recurso roda em oito Regiões da AWS: US East (N. Virginia), Canada (Central), Frankfurt, London, Mumbai, Tokyo, Seoul e Sydney. Para um time brasileiro, nenhuma das oito regiões fica na América do Sul, então o código-fonte da conversão iria para uma região como US East (N. Virginia). Como o código pode carregar configuração, dados de teste ou até dados pessoais, vale checar o que sai antes de enviar: dados pessoais enviados ao exterior são transferência internacional sob a LGPD.

Duas nuvens, uma direção

No início deste mês, o Google colocou um agente por trás da migração de cargas de trabalho Kubernetes do EKS para o GKE. Agora a AWS tem um apontado no sentido contrário, para o Azure. As hiperescaladoras estão construindo agentes de migração voltados aos clientes umas das outras, o que torna os planos de saída de nuvem mais baratos de testar e dá aos compradores uma alternativa crível na hora da renovação. O problema é o mesmo nas duas direções: um agente converte o que consegue ver no código, e boa parte do que faz um aplicativo se comportar como se comporta não está nas chamadas do SDK.

O que fica fora das chamadas do SDK

Identidade. Um aplicativo no Azure normalmente chega ao armazenamento e às filas por meio do Microsoft Entra ID e de identidades gerenciadas com atribuições de função. Na AWS, o mesmo acesso são funções e políticas do IAM. Converter chamadas de BlobClient em chamadas do S3 não projeta a política do IAM que deveria restringi-las, e a correção conveniente, permissões amplas para os testes passarem, é como migrações criam cargas de trabalho com privilégios excessivos que depois viram incidentes.

Gatilhos e tratamento de falhas. Uma Azure Function com um gatilho de fila e uma AWS Lambda lendo SQS processam mensagens, mas as tentativas, as mensagens envenenadas, a visibilidade e o processamento em lote funcionam de forma diferente. Funções do Azure Queue Storage movem uma mensagem para uma fila de mensagens envenenadas depois de um número definido de retiradas da fila; o SQS depende de um visibility timeout e de uma política de redrive de fila de mensagens mortas que alguém precisa configurar. Uma conversão que preserva o caminho feliz pode mudar o que acontece com a milésima mensagem que falha, que é quando as empresas descobrem que seu processo era idempotente só por acidente.

Modelo de dados. Cosmos DB para DynamoDB está em preview por um motivo. Migrar entre bancos de dados de documentos com modelos de consulta, particionamento, indexação e opções de consistência diferentes é uma decisão de design de dados, não uma mudança de sintaxe. Trate uma camada de dados convertida como uma proposta para um arquiteto, não como uma mudança concluída.

Rede e configuração. Endpoints privados, redes virtuais, armazenamentos de configuração e segredos têm equivalentes na AWS, mas são infraestrutura, normalmente definida fora do código da aplicação que o agente reescreve.

Operações. Logs, métricas, tracing e alertas saem do Azure Monitor e do Application Insights para as ferramentas da AWS. Dashboards e runbooks de on-call não migram sozinhos, e o primeiro incidente na nova plataforma não é a hora de descobrir.

Como verificar um aplicativo convertido

O ponto de aprovação no plano de modernização é o design certo: o agente propõe e uma pessoa decide. Mas aprovar um plano não é verificar um resultado. Para um aplicativo que importa, a evidência deve vir do comportamento:

• Testes de contrato em cada fronteira convertida, incluindo casos de falha: objetos ausentes, mensagens grandes demais, throttling, entrega duplicada.
• Replay de tráfego real contra as implantações antiga e nova com comparação de saídas, a abordagem que tornou o Dual Run do Google crível para mainframes.
• Uma revisão de IAM escrita por uma pessoa, não inferida do que os testes precisaram.
• Um caminho de rollback enquanto as duas implantações rodam em paralelo.

Agentes como este tiram das mãos dos engenheiros a parte lenta e repetitiva de uma migração, encontrar e reescrever centenas de chamadas do SDK, o padrão que descrevemos para agentes de migração trabalhando dentro de playbooks. Eles não removem a parte que exige saber o que o aplicativo deve fazer quando as coisas dão errado. Essa parte sempre foi a cara, e continua sendo.