Platform Engineering | The .NET Blog

Eliminando el Trabajo Tedioso de la Migración con Agentic Platform Engineering

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Removing the Monkey Work of Migration with Agentic Platform Engineering — un recorrido de Git-Ape (herramienta git de ingeniería de plataformas agéntica) que migra un repositorio Terraform real de AWS a Azure, centrándose en la extracción de intención en lugar de una conversión línea por línea.

La entrada: contoso-migration

La fuente es un proyecto Terraform real (contoso-migration) que despliega una aplicación Next.js en AWS — EC2 para cómputo, ALB para balanceo de carga, S3 para artefactos y claves IAM para identidad. Costo: ~34 $/mes. El objetivo no es reproducir la misma infraestructura en Azure; es descubrir qué intenta hacer realmente el despliegue y reconstruirlo con servicios nativos de Azure.

Paso 1: Validación y autenticación

Git-Ape comienza validando todas las herramientas CLI requeridas — az, aws, gh, jq, git — y confirmando las sesiones de autenticación activas antes de tocar nada. Sin ejecuciones parciales.

Paso 2: Extracción de intención

El agente lee todo el repositorio fuente a través de la API de GitHub y extrae la intención de despliegue: tiempo de ejecución (Node.js), tipo de cómputo, patrón de ingress, manejo de artefactos, modelo de identidad, red y monitoreo. Este es el paso clave — está construyendo un modelo semántico de lo que hace el despliegue, no qué palabras clave de Terraform utiliza.

Paso 3: Mapeo de servicios

Los servicios de AWS se mapean a equivalentes de Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Balanceo de carga integrado de App Service
Roles/claves IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Paso 4: Agente crítico

Antes de generar la salida, se ejecuta un agente crítico que detecta dos problemas bloqueantes:

Anti-patrón de build al inicio — el Terraform original ejecutaba npm install && npm run build en EC2 al arrancar. Solución: construir en CI, desplegar un artefacto listo.
Blob Storage innecesario — S3 se usaba para la preparación de artefactos que podría eliminarse con CI/CD adecuado. El agente crítico lo eliminó por completo.

Paso 5: Salida generada

El resultado son ~80 líneas de Bicep en lugar de las 200+ líneas originales de Terraform. El agente creó un nuevo repositorio GitHub con infra/main.bicep y .github/workflows/deploy.yml y eliminó todos los archivos específicos de AWS.

Comparación de postura de seguridad

La migración también produjo una mejora significativa de seguridad:

AWS original	Salida Azure
Solo HTTP	Solo HTTPS, TLS 1.2
SSH abierto a 0.0.0.0/0	Sin exposición SSH
Claves de acceso IAM	OIDC + Managed Identity
Sin monitoreo	Application Insights

Costo: ~13 $/mes vs los 34 $/mes originales.

Qué lo diferencia de un convertidor de sintaxis

El paso del agente crítico es lo que separa esto de una traducción mecánica. Detectó patrones que habrían funcionado en AWS pero serían incorrectos en Azure — y los corrigió en lugar de replicarlos. La salida no es “AWS en sintaxis de Azure”; es un despliegue nativo de Azure que logra el mismo objetivo de manera más limpia.

Consulta el recorrido completo para ver la traza completa del agente y los archivos generados.

La Ingeniería de Plataformas Agéntica Se Está Haciendo Real — Git-APE Muestra Cómo

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

La ingeniería de plataformas ha sido uno de esos términos que suena genial en conferencias pero que normalmente significa “construimos un portal interno y un wrapper de Terraform.” La verdadera promesa — infraestructura self-service que realmente sea segura, gobernada y rápida — siempre ha estado a unos pasos de distancia.

El equipo de Azure acaba de publicar la Parte 2 de su serie sobre ingeniería de plataformas agéntica, y esta es sobre la implementación práctica. Lo llaman Git-APE (sí, el acrónimo es intencional), y es un proyecto open source que usa agentes de GitHub Copilot más servidores Azure MCP para convertir solicitudes en lenguaje natural en infraestructura validada y desplegada.

Qué hace Git-APE realmente

La idea central: en vez de que los desarrolladores aprendan módulos de Terraform, naveguen por UIs de portales o abran tickets al equipo de plataforma, hablan con un agente de Copilot. El agente interpreta la intención, genera Infrastructure-as-Code, la valida contra políticas y despliega — todo dentro de VS Code.

Aquí está la configuración:

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

Abre el workspace en VS Code, y los archivos de configuración del agente son descubiertos automáticamente por GitHub Copilot. Interactúas con el agente directamente:

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

El agente usa Azure MCP Server internamente para interactuar con los servicios de Azure. La configuración de MCP en las opciones de VS Code habilita capacidades específicas:

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

Por qué esto importa

Para los que construimos en Azure, esto cambia la conversación de ingeniería de plataformas de “cómo construimos un portal” a “cómo describimos nuestras barreras de seguridad como APIs.” Cuando la interfaz de tu plataforma es un agente de IA, la calidad de tus restricciones y políticas se convierte en el producto.

El blog de la Parte 1 planteó la teoría: APIs bien descritas, esquemas de control y barreras explícitas hacen las plataformas agent-ready. La Parte 2 lo demuestra funcionando con herramientas reales. El agente no genera recursos ciegamente — valida contra mejores prácticas, respeta convenciones de nomenclatura y aplica las políticas de tu organización.

La limpieza es igual de sencilla:

@git-ape destroy my-resource-group

Mi opinión

Seré honesto — esta es más sobre el patrón que sobre la herramienta específica. Git-APE en sí es una demo/arquitectura de referencia. Pero la idea subyacente — agentes como la interfaz de tu plataforma, MCP como protocolo, GitHub Copilot como host — es hacia donde se dirige la experiencia del desarrollador empresarial.

Si eres un equipo de plataforma buscando cómo hacer tu herramienta interna amigable para agentes, no hay mejor punto de partida. Y si eres un desarrollador .NET preguntándote cómo se conecta esto con tu mundo: el Azure MCP Server y los agentes de GitHub Copilot funcionan con cualquier carga de trabajo de Azure. Tu API ASP.NET Core, tu stack .NET Aspire, tus microservicios contenerizados — todo puede ser el objetivo de un flujo de despliegue agéntico.

Para cerrar

Git-APE es una mirada temprana pero concreta a la ingeniería de plataformas agéntica en la práctica. Clona el repo, prueba la demo y empieza a pensar en cómo las APIs y políticas de tu plataforma necesitarían verse para que un agente las use de forma segura.

Lee el post completo para el walkthrough y videos de demostración.