Platform Engineering | The .NET Blog

Removendo o Trabalho Repetitivo de Migração com Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Removing the Monkey Work of Migration with Agentic Platform Engineering — um passo a passo do Git-Ape (ferramenta git de engenharia de plataformas agêntica) migrando um repositório Terraform real da AWS para o Azure, com foco na extração de intenção em vez de conversão linha por linha.

A entrada: contoso-migration

A fonte é um projeto Terraform real (contoso-migration) que implanta um aplicativo Next.js na AWS — EC2 para computação, ALB para balanceamento de carga, S3 para artefatos e chaves IAM para identidade. Custo: ~$34/mês. O objetivo não é reproduzir a mesma infraestrutura no Azure; é descobrir o que o deployment está realmente tentando fazer e reconstruí-lo com serviços nativos do Azure.

Passo 1: Validação e autenticação

O Git-Ape começa validando todas as ferramentas CLI necessárias — az, aws, gh, jq, git — e confirmando as sessões de autenticação ativas antes de tocar em qualquer coisa. Sem execuções parciais.

Passo 2: Extração de intenção

O agente lê todo o repositório fonte pela API do GitHub e extrai a intenção do deployment: runtime (Node.js), tipo de computação, padrão de ingress, tratamento de artefatos, modelo de identidade, rede e monitoramento. Este é o passo-chave — está construindo um modelo semântico do que o deployment faz, não quais palavras-chave do Terraform ele usa.

Passo 3: Mapeamento de serviços

Os serviços AWS são mapeados para equivalentes do Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Balanceamento de carga integrado do App Service
Funções/chaves IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Passo 4: Agente crítico

Antes de gerar a saída, um agente crítico é executado e detecta dois problemas bloqueantes:

Anti-padrão de build no startup — o Terraform original estava executando npm install && npm run build no EC2 na inicialização. Solução: construir no CI, implantar um artefato pronto.
Blob Storage desnecessário — o S3 era usado para staging de artefatos que poderia ser eliminado com CI/CD adequado. O agente crítico o removeu completamente.

Passo 5: Saída gerada

O resultado são ~80 linhas de Bicep em vez das 200+ linhas originais de Terraform. O agente criou um novo repositório GitHub com infra/main.bicep e .github/workflows/deploy.yml e removeu todos os arquivos específicos da AWS.

Comparação de postura de segurança

A migração também produziu uma melhoria significativa de segurança:

AWS original	Saída Azure
Somente HTTP	Somente HTTPS, TLS 1.2
SSH aberto para 0.0.0.0/0	Sem exposição SSH
Chaves de acesso IAM	OIDC + Managed Identity
Sem monitoramento	Application Insights

Custo: ~$13/mês vs os $34/mês originais.

O que o diferencia de um conversor de sintaxe

O passo do agente crítico é o que separa isso de uma tradução mecânica. Ele detectou padrões que teriam funcionado na AWS mas seriam incorretos no Azure — e os corrigiu em vez de replicá-los. A saída não é “AWS em sintaxe Azure”; é um deployment nativo do Azure que atinge o mesmo objetivo de forma mais limpa.

Veja o guia completo para o rastreamento completo do agente e arquivos gerados.

A Engenharia de Plataformas Agêntica Está se Tornando Real — Git-APE Mostra Como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Engenharia de plataformas tem sido um daqueles termos que soam ótimos em conferências, mas que normalmente significam “construímos um portal interno e um wrapper de Terraform.” A verdadeira promessa — infraestrutura self-service que seja realmente segura, governada e rápida — sempre esteve a alguns passos de distância.

O time Azure acaba de publicar a Parte 2 da série sobre engenharia de plataformas agêntica, e esta é toda sobre a implementação prática. Eles chamam de Git-APE (sim, a sigla é intencional), e é um projeto open source que usa agentes do GitHub Copilot mais servidores Azure MCP para transformar solicitações em linguagem natural em infraestrutura validada e implantada.

O que o Git-APE realmente faz

A ideia central: em vez de desenvolvedores aprenderem módulos Terraform, navegarem por UIs de portais ou abrirem tickets para o time de plataforma, eles conversam com um agente Copilot. O agente interpreta a intenção, gera Infrastructure-as-Code, valida contra políticas e implanta — tudo dentro do VS Code.

Aqui está a configuração:

git clone https://github.com/Azure/git-ape
cd git-ape

Abra o workspace no VS Code, e os arquivos de configuração do agente são descobertos automaticamente pelo GitHub Copilot. Você interage diretamente com o agente:

@git-ape deploy a function app with storage in West Europe

O agente usa o Azure MCP Server por baixo dos panos para interagir com os serviços Azure. A configuração MCP nas opções do VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por que isso importa

Para nós que construímos no Azure, isso muda a conversa de engenharia de plataformas de “como construímos um portal” para “como descrevemos nossas guardrails como APIs.” Quando a interface da sua plataforma é um agente de IA, a qualidade das suas restrições e políticas se torna o produto.

O blog da Parte 1 apresentou a teoria: APIs bem descritas, schemas de controle e guardrails explícitas tornam as plataformas agent-ready. A Parte 2 prova que funciona entregando ferramentas reais. O agente não gera recursos cegamente — valida contra melhores práticas, respeita convenções de nomenclatura e aplica as políticas da sua organização.

A limpeza é igualmente simples:

@git-ape destroy my-resource-group

Minha opinião

Vou ser honesto — aqui é mais sobre o padrão do que sobre a ferramenta específica. O Git-APE em si é uma demo/arquitetura de referência. Mas a ideia subjacente — agentes como a interface da sua plataforma, MCP como protocolo, GitHub Copilot como host — é para onde a experiência do desenvolvedor enterprise está caminhando.

Se você é um time de plataforma procurando como tornar seu ferramental interno amigável para agentes, não há melhor ponto de partida. E se você é um desenvolvedor .NET se perguntando como isso se conecta ao seu mundo: o Azure MCP Server e os agentes do GitHub Copilot funcionam com qualquer workload Azure. Sua API ASP.NET Core, seu stack .NET Aspire, seus microsserviços em containers — tudo pode ser alvo de um fluxo de deploy agêntico.

Concluindo

Git-APE é um olhar inicial mas concreto sobre engenharia de plataformas agêntica na prática. Clone o repo, experimente a demo e comece a pensar em como as APIs e políticas da sua plataforma precisariam ser para que um agente as use com segurança.

Leia o post completo para o walkthrough e vídeos de demonstração.