Si alguna vez escuchaste “serverless” y pensaste que era solo marketing, entendible. El nombre confunde porque los servidores siguen existiendo, simplemente dejás de encargarte de ellos. Azure Functions es el servicio serverless de Microsoft y en 2026 es uno de los más usados para construir backends event-driven, APIs livianas, pipelines de datos y, cada vez más, herramientas para agentes de IA.
Este post es para developers que nunca tocaron serverless y quieren entender qué es en la práctica, no en teoría.
Qué resuelve Azure Functions
El modelo tradicional para desplegar código en la nube implica provisionar un servidor o contenedor, configurarlo, mantenerlo activo aunque no haya tráfico, y pagar por ese tiempo aunque esté idle. Funciona bien para aplicaciones que reciben tráfico constante, pero es ineficiente para tareas que se ejecutan cuando pasa algo: llega un archivo, alguien hace un request HTTP, se cumple un horario, llega un mensaje a una cola.
Azure Functions invierte ese modelo. Escribís el código, definís qué lo dispara, y Azure se encarga de ejecutarlo cuando eso pasa. No pagás cuando no corre. No configurás servidores. No pensás en escalado porque el servicio escala solo en respuesta a la demanda.
El modelo tiene un nombre técnico más preciso: Functions as a Service (FaaS). Serverless es el paraguas más amplio, pero FaaS es lo que Azure Functions implementa concretamente.
Lenguajes soportados
Azure Functions soporta C#, Java, JavaScript, TypeScript, Python y PowerShell de forma oficial. También tiene soporte para Go y Rust, aunque con menos integración nativa. Si venís del mundo web y trabajás con JavaScript o TypeScript, podés empezar con lo que ya sabés.
Los dos conceptos que tenés que entender bien
Antes de escribir una sola línea de código, hay que tener claros dos conceptos que van a aparecer en toda la documentación.
Triggers son los eventos que hacen correr tu función. Una función tiene exactamente un trigger. Algunos ejemplos reales:
- Un request HTTP llega a una URL (HTTP trigger)
- Se cumple un horario definido, por ejemplo todos los días a las 3am (Timer trigger)
- Llega un mensaje a una cola de Azure Storage (Queue trigger)
- Se sube un archivo a un blob container (Blob trigger)
- Llega un evento de Azure Event Grid o Event Hubs
Bindings son declaraciones que conectan tu función con otros servicios de Azure sin que tengas que escribir el código de esa conexión a mano. Hay bindings de entrada (leer datos) y de salida (escribir datos).
Un ejemplo concreto: tenés una función que se dispara cuando llega un archivo a Blob Storage, lee ese archivo, lo procesa, y escribe el resultado en una tabla de Cosmos DB. En lugar de escribir el SDK de Blob y el SDK de Cosmos DB dentro de la función, declarás esas conexiones como bindings y Azure se encarga de la autenticación y la inyección de los datos.
// Azure Function con HTTP trigger en JavaScript
const { app } = require("@azure/functions");
app.http("miPrimeraFuncion", {
methods: ["GET", "POST"],
authLevel: "anonymous",
handler: async (request, context) => {
context.log("Función ejecutada");
const nombre = request.query.get("nombre") || "mundo";
return { body: `Hola, ${nombre}` };
},
});
Los planes de hosting y cuál elegir hoy
Esta es la parte donde más gente se pierde porque la documentación lista muchas opciones y no siempre queda claro cuándo usar cada una.
En 2026, Microsoft recomienda explícitamente el Flex Consumption plan para nuevos proyectos serverless. Es importante saberlo porque mucho material en internet todavía habla del Consumption plan clásico como si fuera la opción estándar, y eso está cambiando.
Consumption plan es el más conocido. Incluye un free grant mensual de 1 millón de ejecuciones y 400,000 GB-s por suscripción. El problema es que no tiene integración con redes virtuales, tiene un límite de ejecución de 10 minutos, y los cold starts en .NET aislado pueden llegar a entre 2 y 7 segundos. Microsoft anunció el retiro del plan Linux Consumption para septiembre de 2028.
Flex Consumption plan es el reemplazo recomendado. Tiene cold starts más rápidos, integración con virtual networks, escalado por función individual (no todas las funciones del app escalan juntas), concurrencia configurable y múltiples tamaños de instancia. El free grant es de 250,000 ejecuciones y 100,000 GB-s por mes por suscripción. Tiene SLA de 99.95%.
Premium plan elimina los cold starts completamente con instancias pre-calentadas. El costo es de alrededor de 146 dólares por mes como mínimo, lo que lo hace justificable solo cuando los cold starts afectan la experiencia de usuarios reales.
Dedicated plan corre en un App Service existente. Tiene sentido si ya tenés infraestructura pagada y querés aprovecharla, pero pierde gran parte del valor de serverless.
La decisión práctica para alguien que arranca es esta: si el proyecto es nuevo, usá Flex Consumption. Si tenés funciones existentes en el Consumption plan clásico sobre Linux, lo correcto es migrarlas antes de que el plan se retire.
Algo que tenés que saber si usás .NET
El modelo in-process de Azure Functions, donde el código corre en el mismo proceso que el host, está programado para retirarse en noviembre de 2026. El modelo que hay que usar hoy es el isolated worker model, que corre el código en un proceso separado. Esto le da más flexibilidad en versiones de .NET y mejor aislamiento, pero si encontrás documentación que habla de in-process como si fuera la opción vigente, ese material está desactualizado.
Durable Functions para cuando una ejecución no alcanza
Azure Functions tiene un límite de tiempo de ejecución. Si necesitás orquestar un flujo de trabajo más largo, como procesar miles de archivos en secuencia, coordinar múltiples llamadas a APIs externas, o manejar aprobaciones humanas que pueden tardar horas, existe Durable Functions.
Durable Functions es una extensión que permite escribir workflows con estado en un entorno serverless. El runtime maneja checkpoints, reintentos y recuperación automáticamente. Si una instancia falla en el medio de un workflow, el sistema retoma desde donde estaba.
# Ejemplo de orquestación con Durable Functions en Python
import azure.durable_functions as df
def orchestrator_function(context: df.DurableOrchestrationContext):
resultado1 = yield context.call_activity("ProcesarDatos", "input1")
resultado2 = yield context.call_activity("EnviarEmail", resultado1)
return resultado2
main = df.Orchestrator.create(orchestrator_function)
Azure Functions y agentes de IA en 2026
Una tendencia real en 2026 es usar Azure Functions como infraestructura serverless para agentes de IA. El soporte para servidores MCP (Model Context Protocol) alcanzó disponibilidad general con autenticación OBO (On-Behalf-Of), lo que permite que agentes de IA accedan a herramientas y datos externos de forma segura usando identidades de Microsoft Entra ID.
En términos prácticos, esto significa que podés deployar un servidor MCP en Azure Functions y que agentes de GitHub Copilot, Microsoft 365 Copilot u otros clientes compatibles puedan invocar las herramientas que exponés, con autenticación empresarial incluida y sin gestionar infraestructura propia.
Dónde practicar sin gastar nada
La cuenta gratuita de Azure incluye créditos y el free grant del Consumption plan cubre ampliamente el uso de aprendizaje. Para el Flex Consumption plan, las primeras 250,000 ejecuciones del mes no tienen costo.
Microsoft Learn tiene un módulo oficial de introducción a Azure Functions que podés seguir en el navegador con un sandbox gratuito, sin necesitar suscripción propia:
👉 https://learn.microsoft.com/azure?wt.mc_id=studentamb_510930
La curva de entrada de Azure Functions es más suave de lo que parece. Si sabés escribir una función en cualquier lenguaje y entendés qué es un evento, ya tenés lo necesario para empezar. El resto se aprende construyendo cosas reales.
Carlos José Castro Galante es Desarrollador Full Stack y Azure AI Engineer certificado por Microsoft (AI-102, AI-900, AZ-900) e ITBA. Disponible para proyectos freelance desde Argentina.
