Container Apps y AKS resuelven cómo ejecutar servicios que están siempre disponibles. Pero buena parte de lo que hace Contoso Airlines no es así. Generar el PDF de una tarjeta de embarque ocupa dos segundos y ocurre cuando un pasajero confirma su reserva. Sincronizar el catálogo de tarifas ocurre cuando cambia un documento en cosmos-contoso-tarifas-pro. Entre un evento y el siguiente no hay nada que hacer, y sin embargo hoy Contoso paga por un contenedor encendido esperando.

Azure Functions es la respuesta: escribes una función, declaras qué la dispara, y Azure se encarga de ejecutarla cuando toca y de que no exista el resto del tiempo. Esta lección va más allá del «hola mundo»: el modelo de desencadenadores y enlaces, los planes de hospedaje con sus contrapartidas reales, las dos funciones de producción de Contoso, la orquestación con Durable Functions y la lección más dura del modelo, que es la idempotencia.

1. Qué es la computación sin servidor y qué se paga
2. Desencadenadores y enlaces: el modelo mental
3. Planes de hospedaje comparados
4. Crear el proyecto y ejecutarlo en local
5. GenerarTarjetaEmbarque: la función de la cola
6. SincronizarTarifas: la fuente de cambios de Cosmos DB
7. Configuración, identidad administrada y Key Vault
8. Durable Functions y el flujo de check-in
9. Idempotencia, reintentos, tiempos de espera y límites
10. Pruebas, despliegue y supervisión
11. Cuándo NO usar funciones
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

«Sin servidor» no significa que no haya servidores; significa que no son asunto tuyo. No eliges tamaño de máquina, no parcheas, no dimensionas: escribes una unidad de código y la plataforma la ejecuta y la escala.

Lo que se paga en el plan de Consumo son tres cosas: el número de ejecuciones, el consumo en gigabytes-segundo (memoria asignada multiplicada por el tiempo de ejecución) y el tráfico saliente. Hay una asignación gratuita mensual generosa, y dos consecuencias prácticas. La primera: una función que no se ejecuta no cuesta nada, y ahí está el ahorro frente al contenedor encendido. La segunda, menos intuitiva: el coste es proporcional al tiempo de ejecución, así que una función lenta cuesta más, y una función que espera bloqueada a una llamada HTTP externa te cobra por esperar.

Aquí está el concepto que hay que interiorizar. Una función tiene exactamente un desencadenador —lo que decide cuándo se ejecuta— y cero o más enlaces de entrada y de salida, que son conexiones declarativas a otros servicios. La plataforma se encarga de la conexión, la autenticación, la deserialización y los reintentos; tú recibes objetos y devuelves objetos.

La diferencia que hace el modelo valioso son los enlaces. Compara:

Seis líneas de fontanería sustituidas por una declaración. Y no es solo brevedad: la conexión, los reintentos y la autenticación con identidad administrada los gestiona el tiempo de ejecución.

Lo que elige Contoso y por qué:

• GenerarTarjetaEmbarque va en Flex Consumo: necesita red virtual para llegar a pe-storage-tarjetas y pe-sql-reservas por punto privado, cosa que el Consumo clásico no permite, y su carga es a ráfagas, con casi cero consumo de madrugada.
• SincronizarTarifas va también en Flex Consumo y en la misma aplicación: comparte red y configuración, y su volumen es bajo.
• La orquestación del check-in con Durable Functions va en Premium. Sus orquestaciones duran horas —esperan a que el pasajero suba un documento—, y ahí el arranque en frío y el límite de duración importan.
• Nada va en el plan de App Service, salvo que quisieran reutilizar plan-contoso-api-pro para aprovechar capacidad ya pagada.

El modelo aislado (dotnet-isolated) es el vigente: la función corre en su propio proceso, desacoplada de la versión del host. Los valores de configuración locales van en local.settings.json, que nunca se confirma al repositorio —está en .gitignore por una razón—; en Azure, esos mismos nombres se leen de la configuración de la aplicación.

Cuando el pasajero completa el check-in, app-contoso-reservas-pro encola un mensaje en cola-emision-tarjetas de stoperacionescontosopro. Esta función lo consume, genera el PDF y lo deja en el contenedor tarjetas-embarque de sttarjetascontosopro.

Lo que hay que entender de este código:

• [QueueTrigger] declara el desencadenador. El tiempo de ejecución sondea la cola, deserializa el JSON del mensaje directamente a SolicitudTarjeta y te lo entrega tipado. Si la deserialización falla, el mensaje va a la cola de mensajes fallidos sin ejecutar tu código.
• Connection = "AlmacenOperaciones" no es una cadena de conexión: es el prefijo de un ajuste de configuración. Con AlmacenOperaciones__queueServiceUri apuntando a la cuenta y la identidad administrada asignada, no hay ninguna clave. Este es el punto que más se hace mal.
• [BlobOutput] con la plantilla {Localizador}-{Asiento}.pdf: los campos del mensaje entrante se interpolan en la ruta del blob. El nombre del fichero es determinista, y de ahí sale gratis la comprobación de idempotencia.
• Devolver null no escribe el blob, la forma limpia de cortar sin lanzar una excepción. Y la inyección de dependencias funciona como en cualquier aplicación .NET: el constructor recibe el registrador y el generador de PDF, lo que hace la función probable con pruebas unitarias.

Cuando el equipo comercial actualiza una tarifa en el contenedor tarifas de cosmos-contoso-tarifas-pro, la fuente de cambios que ya conoces de 03-03 entrega el documento modificado a esta función, que refresca el índice de búsqueda y avisa a la caché del motor de disponibilidad.

El contenedor de arrendamientos merece atención: es donde el desencadenador guarda hasta dónde ha leído cada partición. Vive en la misma base de datos, consume sus propias RU/s y, si lo borras, la función reprocesa desde el principio. La función recibe lotes de cambios, no documentos sueltos, y la clave de partición /origenDestino determina el paralelismo: cada partición se procesa en orden y de forma independiente.

Tres ideas: las conexiones con el sufijo __queueServiceUri / __blobServiceUri activan el modo por identidad, sin claves; la referencia a Key Vault con la sintaxis @Microsoft.KeyVault(...) de 04-03 resuelve el secreto en tiempo de ejecución y el valor nunca se ve en el portal; y la identidad necesita sus roles —Colaborador de datos de la cola de Storage, Colaborador de datos de Blob Storage y Usuario de secretos de Key Vault—.

Las funciones normales son sin estado y de corta duración. ¿Y si el proceso tiene varios pasos, tarda horas y hay que saber por dónde iba? Durable Functions añade estado duradero y reanudación: un orquestador describe el flujo con código normal, y su ejecución se persiste automáticamente en cada punto de espera.

Los tres patrones, aplicados:

• Encadenamiento de funciones: ValidarReserva → EmitirTarjeta. Cada paso usa la salida del anterior; si el proceso se cae en el tercer paso, al reanudar no repite los dos primeros.
• Fan-out / fan-in: documentación, asiento y equipaje son independientes; se lanzan en paralelo y se espera a todas. Reduce el tiempo total al del paso más lento.
• Esperar a un evento externo: el orquestador se detiene en WaitForExternalEvent("DocumentoSubido") con un tiempo de espera de 24 horas. Mientras espera no consume cómputo ni factura; es lo que hace inviable resolver esto con una función normal, limitada a minutos.

Regla de oro del orquestador: su código debe ser determinista. Nada de DateTime.Now, Guid.NewGuid() ni llamadas de E/S directas, porque el orquestador se reejecuta desde el principio cada vez que reanuda, reproduciendo su historial. Usa contexto.CurrentUtcDateTime y delega todo lo no determinista en actividades.

Esta es la lección que casi nadie cuenta al principio y que todo el mundo aprende en producción: las colas garantizan la entrega al menos una vez, no exactamente una vez. Si la función se cae después de generar el PDF pero antes de confirmar el mensaje, el mensaje reaparece y la función se ejecuta otra vez con los mismos datos. Sin protección, el pasajero recibe dos tarjetas y el registro contable queda descuadrado.

Cómo se protege, en orden de preferencia:

Sobre los reintentos: la cola reintenta automáticamente (cinco veces por defecto) y luego envía el mensaje a la cola de mensajes fallidos. Un mensaje que falla siempre —un JSON malformado, un vuelo inexistente— se llama mensaje envenenado, y sin cola de mensajes fallidos bloquearía la cola indefinidamente. Vigila esa cola con una alerta: si crece, algo está roto.

Sobre tiempos de espera y límites: 5 minutos por defecto en Consumo (ampliable a 10), configurable en Flex y sin límite en Premium, con el valor en functionTimeout de host.json. Un mensaje de cola grande no cabe (64 KB), así que manda referencias, no cargas: el identificador del blob, no el PDF. Y maxConcurrentCalls limita el paralelismo, que hay que bajar cuando la función escribe en db-reservas, porque mil instancias abriendo conexiones agotan el grupo de la base de datos.

La lógica va en clases inyectadas —IGeneradorPdf, IIndiceTarifas—, así que se prueba con pruebas unitarias normales; la función se limita a orquestar. Para la integración, func start con el emulador de Storage. El despliegue reutiliza el pipeline de 05-04, con ranuras: se despliega en preproduccion, se calienta y se intercambia.

Application Insights viene integrado y es donde se ve todo: ejecuciones con éxito y con error, duración, telemetría de dependencias y la traza de extremo a extremo desde la cola hasta el blob. Su explotación es 07-03; aquí basta con saber que se habilita al crear la aplicación y que sin él una función que falla es una caja negra.

• Procesos de larga duración con estado en memoria: usa Durable Functions o un contenedor. Y cargas constantes y altas: si el código se ejecuta sin parar, un plan fijo o Container Apps sale más barato que pagar por ejecución.
• Latencia mínima garantizada en la primera petición: el arranque en frío del plan de Consumo no es aceptable para la ruta de compra.
• Aplicaciones con mucha lógica compartida y despliegue conjunto: si las «funciones» son un monolito troceado que siempre se despliega junto, es una API, y su sitio es App Service o Container Apps. Lo mismo con conexiones persistentes o dependencias pesadas de arranque: cada instancia nueva paga ese arranque, y con escalado agresivo el destino sufre.

• No hacer la función idempotente. Se manifiesta como duplicados esporádicos imposibles de reproducir. Diséñalo desde el primer día.
• Usar cadenas de conexión con clave en los ajustes de Connection. Usa el sufijo __blobServiceUri con identidad administrada.
• Meter la carga completa en el mensaje. Límite de 64 KB en colas de Storage: manda la referencia.
• Escribir código no determinista en un orquestador. DateTime.Now o Guid.NewGuid() producen resultados incoherentes al reanudar.
• Ignorar la cola de mensajes fallidos, donde acaban los mensajes envenenados; si nadie la mira, los errores son invisibles. Y no limitar la concurrencia cuando la función escribe en db-reservas: mil instancias agotan el grupo de conexiones.
• Confirmar local.settings.json. Contiene credenciales locales. Compruébalo en la revisión de 05-02.
• Consejo: mide la duración en Application Insights; bajar una función de 4 s a 1,5 s reduce la factura de Consumo casi en la misma proporción. Y una función, una responsabilidad: si tiene tres desencadenadores lógicos distintos, son tres funciones.

Ejercicio 1. Contoso Millas necesita una función que, cuando un pasajero completa un vuelo, sume las millas correspondientes a su perfil en cosmos-contoso-tarifas-pro. Los eventos llegan por cola-vuelos-completados.

1. Elige desencadenador, enlaces y plan de hospedaje, y justifícalo.
2. El primer día en producción, algunos pasajeros aparecen con las millas duplicadas. Explica la causa exacta, da dos formas de arreglarlo, e indica las etiquetas del recurso y la alerta que configurarías desde el día uno.

Ejercicio 2. Diseña con Durable Functions el proceso de reembolso de un billete: validar la solicitud, comprobar en paralelo penalización y saldo de la pasarela, esperar la aprobación de un supervisor (máximo 72 horas) y, si se aprueba, ejecutar el abono y notificar.

1. Indica qué patrón cubre cada tramo y por qué no se puede resolver con una función normal en el plan de Consumo.
2. Escribe en pseudocódigo la espera del supervisor con su caducidad y di qué pasa si el orquestador se reinicia mientras espera.

Ejercicio 3. Una función con desencadenador HTTP consulta db-reservas y responde en 200 ms cuando hay poco tráfico, pero al abrir la venta de plazas devuelve errores de tiempo de espera de la base de datos.

1. Explica el mecanismo del fallo.
2. Propón tres medidas correctoras.

Solución 1:

1. Desencadenador de cola de Storage sobre cola-vuelos-completados, con enlace de salida a Cosmos DB al contenedor perfiles. Plan Flex Consumo: volumen a ráfagas concentradas al aterrizar los vuelos, coste casi cero de madrugada, y necesita red virtual para llegar al punto privado de Cosmos.
2. La causa es la entrega al menos una vez: si la función suma las millas y se cae antes de confirmar el mensaje, este reaparece y se vuelve a sumar. Sumar es la operación no idempotente por excelencia. Arreglo (a): guardar en el documento del perfil el conjunto de identificadores de vuelo ya acreditados y descartar el evento si ya está —comprobación previa dentro de la misma escritura—. Arreglo (b): registrar el identificador del mensaje en la tabla registroembarques antes de sumar, y descartar si ya existe. La (a) es preferible porque no añade otro almacén ni otra ventana de fallo. Etiquetas: entorno, proyecto=contoso-millas, centro-coste=CC-2077 y propietario. La alerta del primer día es sobre la longitud de la cola de mensajes fallidos: en cuanto crece, hay mensajes envenenados y pasajeros sin sus millas.

Solución 2:

1. Validar → comprobar → abonar → notificar es encadenamiento; penalización y saldo en paralelo son fan-out / fan-in; la aprobación del supervisor es esperar a un evento externo. No cabe en una función normal porque la espera dura hasta 72 horas y el plan de Consumo corta a los 5 o 10 minutos; además haría falta persistir el punto exacto del proceso, y una función normal es sin estado.
2. var evento = contexto.WaitForExternalEvent<Decision>("AprobacionSupervisor"); junto a var plazo = contexto.CreateTimer(contexto.CurrentUtcDateTime.AddHours(72), cts.Token); y un Task.WhenAny sobre ambos; si gana el plazo se rechaza por caducidad, y si gana el evento se cancela el temporizador. Si el orquestador se reinicia mientras espera, no pasa nada: la instancia no está ocupando cómputo, su historial está persistido y al reanudar se reproduce hasta el punto de espera. Esa es exactamente la propiedad que aporta el modelo duradero.

Solución 3:

1. La función escala a decenas o cientos de instancias en paralelo, y cada instancia abre sus propias conexiones a db-reservas. El grupo de conexiones del servidor se agota, las peticiones se encolan y acaban expirando. El síntoma aparece en la base de datos, pero la causa es el escalado descontrolado de la función.
2. (a) Limitar la concurrencia en host.json y fijar functionAppScaleLimit a un techo compatible con la base de datos. (b) Reutilizar el cliente de base de datos como estático o singleton en lugar de crear uno por invocación, para que las conexiones se agrupen. (c) Quitar la sincronía del camino: encolar la petición y responder de inmediato, o poner una caché delante para las consultas repetidas. Como refuerzo, revisar el nivel de sql-contoso-reservas-pro (03-02), aunque escalar la base de datos sin arreglar la concurrencia solo mueve el límite.

Ya sabes qué significa de verdad «sin servidor»: no hay máquina que elegir ni parchear, se paga por ejecuciones y gigabytes-segundo, una función parada cuesta cero y una función lenta cuesta más. Tienes interiorizado el modelo mental de desencadenadores y enlaces —un desencadenador que decide cuándo, enlaces de entrada y salida que eliminan la fontanería de conectarse, autenticarse y reintentar— y conoces los más usados con su encaje en Contoso. Sabes comparar los planes de hospedaje por arranque en frío, escalado, red virtual, duración y coste, y por qué las funciones de Contoso van en Flex Consumo mientras la orquestación del check-in necesita Premium.

Has escrito las dos funciones reales: GenerarTarjetaEmbarque, disparada por cola-emision-tarjetas, con enlace de salida al contenedor tarjetas-embarque mediante una plantilla de nombre determinista que regala la idempotencia; y SincronizarTarifas, alimentada por la fuente de cambios de cosmos-contoso-tarifas-pro con su contenedor de arrendamientos y su procesamiento por lotes. Las has configurado con conexiones por identidad (__blobServiceUri, __queueServiceUri) y referencias a kv-contoso-pro, sin una sola clave. Con Durable Functions has orquestado el check-in aplicando encadenamiento, fan-out/fan-in y espera de evento externo durante 24 horas sin consumir cómputo, respetando la regla del orquestador determinista. Y te llevas la lección dura: al menos una vez, no exactamente una vez, con sus tres estrategias de idempotencia, la cola de mensajes fallidos que hay que vigilar, los tiempos de espera, el límite de 64 KB y la concurrencia que hay que frenar cuando detrás hay una base de datos. Sabes desplegar con ranuras desde el pipeline, supervisar con Application Insights (07-03) y, sobre todo, cuándo no usar funciones.

Queda una pieza incómoda. Cuando un vuelo se retrasa, Contoso tiene que buscar los pasajeros afectados en db-reservas, avisarles por correo y por mensaje, publicar en el canal del equipo de operaciones y abrir un incidente en el sistema de soporte. Nada de eso es lógica de negocio compleja: es pegar sistemas entre sí, y escribirlo como código significa mantener a mano cuatro integraciones con sus autenticaciones, sus reintentos y sus formatos. Además, quien conoce ese proceso no es Diego, es el equipo de operaciones, que no programa. La lección siguiente, Azure Logic Apps, es exactamente para eso: flujos de trabajo visuales sobre un catálogo de más de mil conectores, con su definición en JSON versionable, su control de flujo, su gestión de errores y su historial de ejecuciones, y con el criterio para saber cuándo toca una aplicación lógica, cuándo una función y cuándo Data Factory.