Platform Engineering | The .NET Blog

Eliminare il Lavoro Ripetitivo della Migrazione con l'Agentic Platform Engineering

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Removing the Monkey Work of Migration with Agentic Platform Engineering — una guida passo per passo di Git-Ape (strumento git di ingegneria di piattaforma agentiva) che migra un vero repository Terraform AWS verso Azure, concentrandosi sull’estrazione dell’intenzione piuttosto che sulla conversione riga per riga.

L’input: contoso-migration

La fonte è un vero progetto Terraform (contoso-migration) che distribuisce un’app Next.js su AWS — EC2 per il computing, ALB per il bilanciamento del carico, S3 per gli artefatti e chiavi IAM per l’identità. Costo: ~34 $/mese. L’obiettivo non è riprodurre la stessa infrastruttura su Azure; è capire cosa il deployment sta effettivamente cercando di fare e ricostruirlo con servizi nativi Azure.

Passo 1: Validazione e autenticazione

Git-Ape inizia validando tutti gli strumenti CLI richiesti — az, aws, gh, jq, git — e confermando le sessioni di autenticazione attive prima di toccare qualsiasi cosa. Nessuna esecuzione parziale.

Passo 2: Estrazione dell’intenzione

L’agente legge l’intero repository sorgente tramite l’API GitHub ed estrae l’intenzione del deployment: runtime (Node.js), tipo di computing, modello di ingress, gestione degli artefatti, modello di identità, rete e monitoraggio. Questo è il passaggio chiave — sta costruendo un modello semantico di cosa fa il deployment, non quali parole chiave Terraform usa.

Passo 3: Mappatura dei servizi

I servizi AWS vengono mappati agli equivalenti Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Bilanciamento del carico integrato di App Service
Ruoli/chiavi IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Passo 4: Agente critico

Prima di generare l’output, viene eseguito un agente critico che individua due problemi bloccanti:

Anti-pattern di build all’avvio — il Terraform originale eseguiva npm install && npm run build su EC2 all’avvio. Fix: costruire in CI, distribuire un artefatto pronto.
Blob Storage non necessario — S3 veniva usato per lo staging degli artefatti che poteva essere eliminato con un CI/CD appropriato. L’agente critico lo ha rimosso completamente.

Passo 5: Output generato

Il risultato è ~80 righe di Bicep invece delle 200+ righe originali di Terraform. L’agente ha creato un nuovo repository GitHub con infra/main.bicep e .github/workflows/deploy.yml e rimosso tutti i file specifici di AWS.

Confronto della postura di sicurezza

La migrazione ha anche prodotto un significativo miglioramento della sicurezza:

AWS originale	Output Azure
Solo HTTP	Solo HTTPS, TLS 1.2
SSH aperto a 0.0.0.0/0	Nessuna esposizione SSH
Chiavi di accesso IAM	OIDC + Managed Identity
Nessun monitoraggio	Application Insights

Costo: ~13 $/mese vs i 34 $/mese originali.

Cosa lo differenzia da un convertitore di sintassi

Il passaggio dell’agente critico è ciò che separa questo da una traduzione meccanica. Ha individuato pattern che avrebbero funzionato su AWS ma sarebbero stati sbagliati su Azure — e li ha corretti invece di replicarli. L’output non è “AWS in sintassi Azure”; è un deployment nativo Azure che raggiunge lo stesso obiettivo in modo più pulito.

Vedi la guida completa per la traccia completa dell’agente e i file generati.

L'Ingegneria delle Piattaforme Agentiche Sta Diventando Realtà — Git-APE Mostra Come

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

L’ingegneria delle piattaforme è stato uno di quei termini che suona bene alle conferenze ma che di solito significa “abbiamo costruito un portale interno e un wrapper Terraform.” La vera promessa — infrastruttura self-service che sia realmente sicura, governata e veloce — è sempre stata a qualche passo di distanza.

Il team Azure ha appena pubblicato la Parte 2 della serie sull’ingegneria delle piattaforme agentiche, e questa è tutta sull’implementazione pratica. Lo chiamano Git-APE (sì, l’acronimo è intenzionale), ed è un progetto open source che utilizza agenti GitHub Copilot più server Azure MCP per trasformare richieste in linguaggio naturale in infrastruttura validata e deployata.

Cosa fa Git-APE concretamente

L’idea centrale: invece di far imparare ai developer moduli Terraform, navigare nelle UI dei portali o aprire ticket al team piattaforma, parlano con un agente Copilot. L’agente interpreta l’intento, genera Infrastructure-as-Code, la valida contro le policy e deploya — tutto all’interno di VS Code.

Ecco il setup:

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

Apri il workspace in VS Code, e i file di configurazione dell’agente vengono scoperti automaticamente da GitHub Copilot. Interagisci direttamente con l’agente:

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

L’agente utilizza Azure MCP Server internamente per interagire con i servizi Azure. La configurazione MCP nelle impostazioni di VS Code abilita capacità specifiche:

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

Perché è importante

Per chi di noi costruisce su Azure, questo sposta la conversazione sull’ingegneria delle piattaforme da “come costruiamo un portale” a “come descriviamo i nostri guardrail come API.” Quando l’interfaccia della tua piattaforma è un agente IA, la qualità dei tuoi vincoli e delle tue policy diventa il prodotto.

Il blog della Parte 1 esponeva la teoria: API ben descritte, schemi di controllo e guardrail espliciti rendono le piattaforme agent-ready. La Parte 2 dimostra che funziona rilasciando strumenti concreti. L’agente non genera risorse alla cieca — valida contro le best practice, rispetta le convenzioni di naming e applica le policy della tua organizzazione.

La pulizia è altrettanto semplice:

@git-ape destroy my-resource-group

La mia opinione

Sarò onesto — qui si tratta più del pattern che dello strumento specifico. Git-APE in sé è una demo/architettura di riferimento. Ma l’idea sottostante — agenti come interfaccia alla tua piattaforma, MCP come protocollo, GitHub Copilot come host — è la direzione in cui sta andando l’esperienza developer enterprise.

Se sei un team piattaforma che cerca come rendere il proprio tooling interno agent-friendly, non c’è punto di partenza migliore. E se sei uno sviluppatore .NET che si chiede come questo si collega al suo mondo: Azure MCP Server e gli agenti GitHub Copilot funzionano con qualsiasi workload Azure. La tua API ASP.NET Core, il tuo stack .NET Aspire, i tuoi microservizi containerizzati — tutto può essere il target di un flusso di deployment agentico.

Per concludere

Git-APE è uno sguardo precoce ma concreto sull’ingegneria delle piattaforme agentiche nella pratica. Clona il repo, prova la demo e inizia a pensare a come le API e le policy della tua piattaforma dovrebbero apparire per permettere a un agente di usarle in sicurezza.

Leggi il post completo per il walkthrough e i video dimostrativi.