AZ-104
Deep Dive
Azure Functions es la plataforma serverless de Azure: ejecutas código bajo demanda sin gestionar infraestructura. El AZ-104 evalúa principalmente los planes de hospedaje, triggers comunes y la diferencia con otros servicios de cómputo.
Contenido
Azure Functions permite ejecutar pequeños fragmentos de código (funciones) en respuesta a eventos, sin necesidad de aprovisionar ni gestionar servidores. Es el servicio serverless de Azure — pagas solo por las ejecuciones reales.
Event-driven
Se ejecutan en respuesta a eventos: HTTP request, mensaje en cola, blob nuevo, timer, etc.
Serverless
No gestionas VMs ni App Service Plans (en Consumption). Azure escala automáticamente de 0 a N instancias.
Pay-per-execution
En Consumption plan: pagas por número de ejecuciones y tiempo de CPU. 1M ejecuciones/mes gratis.
Lenguajes soportados (runtime v4)
El plan de hospedaje determina el escalado, el costo y las caracterÃsticas disponibles. Es uno de los conceptos más evaluados del AZ-104 sobre Functions.
| Plan | Escalado | Cold Start | Timeout máx. | VNet Integration | Costo |
|---|---|---|---|---|---|
| Consumption | 0 → ilimitado (automático) | âš ï¸ Sà | 5 min (configurable hasta 10 min) | ⌠No (solo salida via triggers VNet) | Por ejecución + GB-s |
| Flex Consumption | 0 → 1000 instancias (automático, granular) | âš ï¸ Reducido | 30 min | ✅ Sà (ingress y egress) | Por instancia-segundo activo |
| Premium (EP1/EP2/EP3) | Manual + automático. Instancias pre-calentadas. | ✅ Sin cold start | Ilimitado | ✅ Completa | Por instancia/hora (siempre encendida) |
| Dedicated (App Service) | Manual. Comparte instancias con App Service. | ✅ Sin cold start | Ilimitado | ✅ Completa | Por App Service Plan |
Consumption
Cargas esporádicas. Bajo presupuesto. No necesitas VNet ni ejecuciones largas.
Premium
Sin cold start crÃtico. Necesitas VNet Integration. Ejecuciones largas. Tráfico predecible.
Dedicated
Ya tienes App Service Plan subutilizado. Quieres siempre encendido a costo controlado.
Un trigger define el evento que activa la función. Cada función tiene exactamente 1 trigger.
| Trigger | Cuándo se activa | Ejemplo de uso |
|---|---|---|
| HTTP Trigger | Petición HTTP GET/POST/etc. (es una API/webhook) | API REST sin servidor, webhooks de terceros |
| Timer Trigger | Expresión CRON: "0 */5 * * * *" (cada 5 min) | Jobs de limpieza periódica, reportes automáticos |
| Blob Trigger | Nuevo blob en contenedor o modificación de blob existente | Procesar imágenes al subirse, transformar datos CSV |
| Queue Trigger (Storage) | Nuevo mensaje en Azure Storage Queue | Procesamiento asÃncrono, worker patterns |
| Service Bus Trigger | Mensaje en Service Bus Queue o Topic/Subscription | Integración empresarial, mensajerÃa garantizada |
| Event Hub Trigger | Evento en Azure Event Hub (streaming masivo) | TelemetrÃa IoT, análisis de logs en tiempo real |
| Event Grid Trigger | Evento de Azure Event Grid | Reaccionar a cambios en recursos Azure (blob deleted, VM stopped) |
| CosmosDB Trigger (Change Feed) | Cambio en documentos de CosmosDB | Sincronizar datos, invalidar caché |
Los bindings son conexiones declarativas a servicios externos. Se definen en function.json(o via atributos en C#/Python). Evitan escribir código de conexión manual.
Input Binding
Lee datos adicionales al ejecutarse. Ej: leer un blob o fila de CosmosDB al recibir una petición HTTP.
Trigger
El evento que activa la función. Es un tipo especial de binding. Cada función tiene exactamente 1 trigger.
Output Binding
Escribe datos al completarse. Ej: enviar un mensaje a Queue, escribir a CosmosDB, llamar a otro servicio.
// function.json — HTTP trigger + Blob output binding
{
"bindings": [
{
"type": "httpTrigger", // Trigger
"direction": "in",
"authLevel": "function",
"methods": ["post"]
},
{
"type": "http", // HTTP output (response)
"direction": "out",
"name": "$return"
},
{
"type": "blob", // Output binding: escribe blob
"direction": "out",
"name": "outputBlob",
"path": "output/{rand-guid}.json",
"connection": "StorageConnectionString"
}
]
}Durable Functions es una extensión de Azure Functions que permite escribir workflows stateful en un entorno serverless. Resuelve el problema de coordinar múltiples funciones con estado.
Orchestrator Function
Coordina la ejecución de activity functions. Define el flujo: secuencial, paralelo, condicional. No debe tener I/O directo — todo via await ctx.callActivity().
Activity Function
Unidad de trabajo individual. Realiza la tarea real (llamar API, procesar datos, escribir DB). Sin estado propio — el estado lo gestiona el orchestrator.
Entity Function (Grain)
Representa un objeto stateful que persiste entre invocaciones. Permite modelar actores o entidades con estado mutable.
Client Function
Inicia, termina, envÃa eventos o consulta el estado de una orquestación. Puede ser cualquier tipo de trigger (HTTP, Queue, etc.).
Patrones comunes de Durable Functions
| Aspecto | Azure Functions | App Service | Logic Apps |
|---|---|---|---|
| Modelo | Serverless / Microservicio | PaaS, app completa | Serverless workflow visual |
| Código | Código propio (C#/Python/JS) | Código propio completo | Sin código (no-code/low-code) |
| Ejecución | Event-driven, short-lived | Always-on, request-response | Event-driven, steps workflow |
| Estado | Stateless (Durable para stateful) | Stateful | Stateful (workflow state) |
| Escalado | Automático (Consumption) | Manual / auto-scale | Automático |
| Costo mÃnimo | Gratis (1M ejecuciones/mes) | Plan B1: ~$13/mes | Por acción: ~$0.000025/acción |
| Mejor para | Micro-tareas, APIs serverless, integración | Web apps, APIs REST completas | Integración de sistemas, orquestación sin código |
En el plan Consumption, cuando una función no ha sido invocada recientemente, su instancia es desactivada. La siguiente invocación sufre un cold start: el tiempo que tarda en iniciar la instancia antes de ejecutar el código.
Factores que afectan el cold start
Soluciones al cold start
Escalado en Consumption Plan
Azure escala automáticamente desde 0 hasta 200 instancias (por plan) basándose en la carga. El escalado es por Function App, no por función individual. Todas las funciones del mismo Function App comparten las mismas instancias.
Consumption plan no soporta VNet Integration (entrada)
En Consumption, las funciones no tienen VNet Integration para tráfico entrante — no puedes exponer una función en una VNet privada. Para acceso privado necesitas Premium Plan o Dedicated (App Service). Consumption sà puede acceder a servicios en VNet via Virtual Network triggers en algunos casos.
Timeout de Consumption plan es 5 minutos por defecto (máximo 10 min)
En Consumption, el timeout predeterminado es 5 minutos, configurable hasta 10 minutos. Premium y Dedicated no tienen lÃmite de timeout. Si tu función tarda más de 10 minutos en Consumption, fallará — usa Premium o Durable Functions.
Cada función tiene exactamente 1 trigger, pero puede tener múltiples bindings
Un trigger activa la función. Los bindings de input/output son adicionales. Puedes tener: 1 HTTP trigger + 1 Blob input binding + 2 output bindings (Queue + CosmosDB). No puedes tener 2 triggers en la misma función.
Premium Plan elimina el cold start pero NO es "gratis"
El Premium Plan tiene instancias pre-calentadas que eliminan el cold start. Sin embargo, siempre tienes al menos 1 instancia activa, por lo que el costo mÃnimo es el de esa instancia (aprox. $175+/mes para EP1). No hay opción de escalar a 0 en Premium.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene una Azure Function con HTTP Trigger que procesa pedidos crÃticos y no puede tolerar cold starts. La función necesita acceder a recursos en una VNet privada. Actualmente está en plan Consumption. ¿Cuál es el plan de hospedaje correcto?