Arquitectura Azure — Módulo 3: cómputo, Container Apps y Durable Functions

Las tres preguntas del cómputo — duración, entorno, forma del trabajo — y la convicción de la serie — el agente es trabajo que despierta cómputo — llegan a su tercera nube intactas. Azure responde con un menú que se parece más al de GCP que al de AWS, más una pieza propia que merece atención especial.

Necesidad	En AWS	En GCP	En Azure
Función corta por evento	Lambda	Cloud Run functions	Azure Functions
Contenedor de servicio (escala a 0)	ECS + Fargate	Cloud Run service	Container Apps
Contenedor efímero por tarea	Tarea Fargate	Cloud Run job	Container Apps jobs
Kubernetes organizacional	EKS	GKE	AKS
Orquestación con estado, en código	Step Functions (JSON)	Workflows (YAML)	Durable Functions (código)

La tesis del módulo

Container Apps es el Cloud Run de Azure con un regalo específico para agentes: KEDA integrado — el escalado por métricas de evento, incluido el largo de una cola de Service Bus — de modo que “la cola crece → nacen réplicas del agente → la cola se vacía → mueren” es configuración, no arquitectura artesanal. Y las Durable Functions aportan lo que ni AWS ni GCP dan igual: orquestación con estado escrita como código normal — la pieza que en el módulo 11 hará la aprobación asíncrona más legible de la serie.

Container Apps: el centro del menú

Azure Container Apps corre contenedores estándar sin administrar Kubernetes (aunque Kubernetes vive debajo, invisible): revisiones, tráfico particionado, scale-to-zero, y el diferencial — KEDA (Kubernetes Event-Driven Autoscaling) integrado como ciudadano de primera clase. Donde Cloud Run escala por concurrencia HTTP, Container Apps escala por la métrica de evento que declares: largo de la cola de Service Bus, mensajes en Event Hubs, tamaño de un tópico. Para la plataforma de agentes es el ajuste perfecto: el consumidor de la cola de correos escala con la cola misma — cero réplicas cuando está vacía, N cuando llega el pico — sin código de escalado.

Las dos caras del patrón, como en GCP:

• Apps (servicios): atienden HTTP o consumen eventos de forma continua, escalan por KEDA, llegan a cero. El agente conversacional y los consumidores de colas viven aquí.
• Jobs: la ejecución que corre hasta terminar — manual, programada (cron integrado) o disparada por eventos (un job por mensaje, con paralelismo). El agente reactivo largo y el lote nocturno, con la semántica correcta de terminación y reintentos.

Azure Functions cubre lo corto y liviano con la nota de que sus planes de hosting modernos conviven con el mismo entorno de Container Apps — la frontera function-vs-contenedor es, como en GCP, de empaque más que de duración. Y AKS es el Kubernetes completo con la regla de la serie inalterada: razón organizacional o no.

Durable Functions: la orquestación como código

La pieza propia. Las Durable Functions extienden Azure Functions con orquestaciones con estado escritas en tu lenguaje (C#, Python, JavaScript…): una función orquestadora describe el flujo — llama actividades, espera resultados, duerme días — y el runtime la des-hidrata mientras espera (sin cómputo facturando) y la re-hidrata cuando llega el evento. Los patrones que trae de fábrica leen como el índice del módulo 11:

• Encadenamiento y fan-out/fan-in: el pipeline del agente y el reparto paralelo, como funciones que se llaman.
• Monitoreo con timers durables: el polling paciente sin contenedor vivo.
• Interacción humana (waiting for external events): la orquestación que emite un evento esperable, notifica al humano, y espera dormida con un timer de timeout en paralelo — el patrón de aprobación asíncrona, con el timeout conservador como una rama if legible.

Frente a Step Functions (máquina en JSON) y Workflows (pasos en YAML), la propuesta de Durable es cultural: el flujo es código — debuggeable, testeable, versionado con el resto. El precio: el orquestador exige disciplina (determinismo — nada de efectos directos en la función orquestadora; el trabajo va en las actividades) y es específico de Azure Functions. Para equipos que viven en código, suele ser la forma más mantenible de las tres nubes; para los que prefieren declarativo, Logic Apps (el hermano low-code, con conectores incluidos hacia correo/Teams/aprobaciones) cubre el mismo espacio desde el otro extremo — el módulo 11 los enfrenta en su terreno.

     ¿DÓNDE CORRE EL AGENTE EN AZURE?

START ──► ┌──────────────────────┐
          │ ¿atiende peticiones/ │
          │ eventos o ejecuta    │
          │ tareas?              │
          └─────┬──────────┬─────┘
    continuo    │          │   por tarea
                ▼          ▼
        ┌────────────┐  ┌────────────┐
        │ Container  │  │ Container  │
        │ App        │  │ Apps job   │
        │ (KEDA:     │  │ (cron o    │
        │ escala por │  │ evento)    │
        │ la cola)   │  └────────────┘
        └────────────┘
   flujo multi-paso con esperas:
   Durable Functions (código) / Logic Apps

Ojo — KEDA escala por la señal correcta: el regalo trae su decisión: ¿por qué métrica escala cada agente? El consumidor de correos, por largo de cola (obvio); el conversacional, por peticiones concurrentes; el que llama a un modelo con cuota dura (módulo 7), quizás por nada automático — un máximo fijo de réplicas alineado a la cuota, porque escalar más rápido que tu límite de tokens solo fabrica errores 429 en paralelo. El auto-escalado es política, y la política incluye sus topes — el eco del freno de capa 1 del FinOps.

Lo que no cambia cierra rápido: la espera fuera del cómputo (Durable duerme gratis, el job nace por evento), el estado fuera del contenedor (módulo 6), y la identidad adjunta — cada app y cada job con su managed identity del módulo 2.

Errores comunes

• Ignorar KEDA y escalar por HTTP todo. El consumidor de cola escalando por peticiones que no recibe es el traductor de Cloud Run en piloto automático. La señal correcta existe como configuración; declárala.
• Tareas disfrazadas de apps. El lote como servicio invocado por HTTP interno: mismo anti-patrón, tercera nube. Jobs para tareas — con su cron y su disparo por evento incluidos.
• AKS por prestigio. Última llamada de la serie: razón organizacional o Container Apps.
• Efectos directos en el orquestador de Durable. La función orquestadora que llama APIs o escribe bases rompe el determinismo del replay y produce bugs fantasmales. El orquestador decide; las actividades trabajan — la disciplina es el precio del código.
• Escalar más rápido que tus cuotas. Cien réplicas contra un límite de tokens por minuto es una fábrica de 429. El tope de réplicas se alinea con las cuotas de modelo — el escalado también tiene FinOps.
• Elegir Durable vs. Logic Apps por bando. Es una decisión de equipo y mantenibilidad (código vs. conectores low-code), no de superioridad. El módulo 11 da el criterio en el caso concreto de las aprobaciones.

La frase para llevarse

“Container Apps con KEDA hace que el agente escale con su cola — cero cuando está vacía, N cuando llega el pico — y las Durable Functions convierten el flujo con esperas en código que duerme gratis. Las tres preguntas de siempre eligen la pieza; los topes de escalado se alinean con las cuotas, porque correr más rápido que tu límite solo fabrica errores en paralelo.”

Qué viene

Módulo 4: redes. La VNet y sus piezas — NSGs, private endpoints, la salida controlada — con las diferencias de Azure: el private endpoint como el mecanismo universal hacia los servicios PaaS (más central aún que en AWS), y Azure Firewall como el filtro de egress por dominio que la lista corta del agente agradece.

Material relacionado

• Módulo 2: identidad y managed identities
• Módulo 4: redes — la VNet del agente
• Curso de AWS — Módulo 3: cómputo para agentes
• Curso de GCP — Módulo 3: cómputo — Cloud Run
• Glosario de Arquitectura Azure para Agentes de IA