Platform Engineering | The .NET Blog

Die Monkey Work der Migration mit Agentic Platform Engineering beseitigen

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Removing the Monkey Work of Migration with Agentic Platform Engineering — eine Schritt-für-Schritt-Anleitung von Git-Ape (git agentic platform engineering tool), das ein echtes AWS-Terraform-Repo zu Azure migriert, mit Fokus auf Intent-Extraktion statt zeilenweiser Konvertierung.

Die Eingabe: contoso-migration

Die Quelle ist ein echtes Terraform-Projekt (contoso-migration), das eine Next.js-App auf AWS bereitstellt — EC2 für Compute, ALB für Load Balancing, S3 für Artefakte und IAM-Schlüssel für Identität. Kosten: ~34 $/Monat. Das Ziel ist nicht, dieselbe Infrastruktur auf Azure zu reproduzieren; es geht darum herauszufinden, was das Deployment eigentlich tun soll, und das mit nativen Azure-Diensten neu aufzubauen.

Schritt 1: Validierung und Authentifizierung

Git-Ape beginnt damit, alle erforderlichen CLI-Tools zu validieren — az, aws, gh, jq, git — und aktive Auth-Sessions zu bestätigen, bevor etwas angerührt wird. Keine Teilausführungen.

Schritt 2: Intent-Extraktion

Der Agent liest das gesamte Quell-Repository über die GitHub API und extrahiert den Deployment-Intent: Laufzeit (Node.js), Compute-Typ, Ingress-Muster, Artefakt-Handling, Identitätsmodell, Netzwerk und Monitoring. Dies ist der entscheidende Schritt — es wird ein semantisches Modell dessen erstellt, was das Deployment tut, nicht welche Terraform-Keywords es verwendet.

Schritt 3: Service-Mapping

AWS-Dienste werden auf Azure-Äquivalente abgebildet:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Integriertes App Service Load Balancing
IAM-Rollen/Schlüssel → Managed Identity
Terraform → Bicep + GitHub Actions

Schritt 4: Kritik-Agent

Vor der Ausgabegenerierung läuft ein Kritik-Agent und erkennt zwei blockierende Probleme:

Build-on-Startup-Antimuster — das ursprüngliche Terraform führte npm install && npm run build auf EC2 beim Start aus. Fix: In CI bauen, ein fertiges Artefakt deployen.
Unnötiger Blob Storage — S3 wurde für Artefakt-Staging verwendet, das mit korrektem CI/CD eliminiert werden könnte. Der Kritik-Agent hat es vollständig entfernt.

Schritt 5: Generierte Ausgabe

Das Ergebnis sind ~80 Zeilen Bicep statt der ursprünglichen 200+ Zeilen Terraform. Der Agent erstellte ein neues GitHub-Repo mit infra/main.bicep und .github/workflows/deploy.yml und entfernte alle AWS-spezifischen Dateien.

Vergleich der Sicherheitslage

Die Migration ergab auch eine bedeutende Sicherheitsverbesserung:

AWS-Original	Azure-Ausgabe
Nur HTTP	Nur HTTPS, TLS 1.2
SSH offen für 0.0.0.0/0	Keine SSH-Exposition
IAM-Zugriffsschlüssel	OIDC + Managed Identity
Kein Monitoring	Application Insights

Kosten: ~13 $/Monat vs. ursprüngliche 34 $/Monat.

Was dies von einem Syntax-Konverter unterscheidet

Der Kritik-Agent-Schritt ist das, was dies von einer mechanischen Übersetzung trennt. Er erkannte Muster, die auf AWS funktioniert hätten, aber auf Azure falsch wären — und korrigierte sie, anstatt sie zu replizieren. Die Ausgabe ist kein “AWS in Azure-Syntax”; es ist ein Azure-natives Deployment, das dasselbe Ziel sauberer erreicht.

Siehe die vollständige Anleitung für die vollständige Agent-Ablaufverfolgung und generierte Dateien.

Agentisches Platform Engineering Wird Realität — Git-APE Zeigt Wie

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Platform Engineering war einer dieser Begriffe, die auf Konferenzen toll klingen, aber normalerweise bedeuten: „Wir haben ein internes Portal und einen Terraform-Wrapper gebaut." Das eigentliche Versprechen — Self-Service-Infrastruktur, die wirklich sicher, kontrolliert und schnell ist — war immer noch ein paar Schritte entfernt.

Das Azure-Team hat gerade Teil 2 ihrer Serie über agentisches Platform Engineering veröffentlicht, und in diesem Teil geht es um die praktische Umsetzung. Sie nennen es Git-APE (ja, das Akronym ist beabsichtigt), und es ist ein Open-Source-Projekt, das GitHub Copilot Agents plus Azure MCP Server nutzt, um natürlichsprachliche Anfragen in validierte, deployed Infrastruktur umzuwandeln.

Was Git-APE tatsächlich macht

Die Kernidee: Anstatt dass Entwickler Terraform-Module lernen, durch Portal-UIs navigieren oder Tickets beim Platform-Team einreichen, sprechen sie mit einem Copilot-Agenten. Der Agent interpretiert die Absicht, generiert Infrastructure-as-Code, validiert sie gegen Richtlinien und deployt — alles innerhalb von VS Code.

Hier ist das Setup:

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

Öffne den Workspace in VS Code, und die Agent-Konfigurationsdateien werden automatisch von GitHub Copilot erkannt. Du interagierst direkt mit dem Agenten:

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

Der Agent nutzt Azure MCP Server unter der Haube, um mit Azure-Diensten zu interagieren. Die MCP-Konfiguration in den VS Code-Einstellungen aktiviert spezifische Fähigkeiten:

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

Warum das wichtig ist

Für diejenigen von uns, die auf Azure bauen, verschiebt dies die Platform-Engineering-Diskussion von „wie bauen wir ein Portal" zu „wie beschreiben wir unsere Leitplanken als APIs." Wenn die Schnittstelle deiner Plattform ein KI-Agent ist, wird die Qualität deiner Einschränkungen und Richtlinien zum Produkt.

Der Blog von Teil 1 legte die Theorie dar: gut beschriebene APIs, Kontrollschemata und explizite Leitplanken machen Plattformen agent-ready. Teil 2 beweist, dass es funktioniert, indem tatsächliche Werkzeuge ausgeliefert werden. Der Agent generiert nicht blind Ressourcen — er validiert gegen Best Practices, respektiert Namenskonventionen und wendet die Richtlinien deiner Organisation an.

Das Aufräumen ist genauso einfach:

@git-ape destroy my-resource-group

Meine Einschätzung

Ich bin ehrlich — hier geht es mehr um das Muster als um das spezifische Tool. Git-APE selbst ist eine Demo/Referenzarchitektur. Aber die zugrundeliegende Idee — Agenten als Interface zu deiner Plattform, MCP als Protokoll, GitHub Copilot als Host — ist die Richtung, in die sich die Enterprise-Developer-Experience bewegt.

Wenn du ein Platform-Team bist, das darüber nachdenkt, wie man interne Werkzeuge agent-freundlich macht, gibt es keinen besseren Startpunkt. Und wenn du ein .NET-Entwickler bist, der sich fragt, wie das mit deiner Welt zusammenhängt: Der Azure MCP Server und GitHub Copilot Agents funktionieren mit jedem Azure-Workload. Deine ASP.NET Core API, dein .NET Aspire Stack, deine containerisierten Microservices — all das kann Ziel eines agentischen Deployment-Flows sein.

Zusammenfassung

Git-APE ist ein früher, aber konkreter Blick auf agentisches Platform Engineering in der Praxis. Klone das Repo, probiere die Demo aus und fange an darüber nachzudenken, wie die APIs und Richtlinien deiner Plattform aussehen müssten, damit ein Agent sie sicher nutzen kann.

Lies den vollständigen Post für den Walkthrough und Video-Demos.