Azure Functions as a compute primitive for event-driven workloads has matured significantly through 2019-2020. The integration with Azure Event Grid, Service Bus, and Cosmos DB change feed provides a rich event-driven programming model.
Durable Functions for stateful workflows
Azure Durable Functions extends Functions with an orchestration model for stateful, long-running workflows. The orchestrator function defines the workflow; activity functions do the actual work. The Durable Functions framework handles state persistence, retries, fan-out/fan-in patterns, and human approval steps. The orchestrator function is replayed from the event log on each step, making stateful workflows possible without a database for workflow state management.
The trigger ecosystem
Azure Functions support triggers from: HTTP, Timer, Azure Blob Storage, Azure Queue Storage, Azure Service Bus, Azure Event Hub, Cosmos DB change feed, Event Grid, and more. Each trigger type handles the polling, connection management, and message leasing automatically. The developer writes only the function logic; the trigger binding handles the integration with the event source.
Output bindings
Output bindings allow Functions to write to Azure services without SDK code in the function body. A Function triggered by a blob upload can write a message to a Service Bus queue by declaring an output binding, no Service Bus client code required. Output bindings reduce boilerplate but can obscure the dependencies of a function. For complex workflows, explicit SDK usage with clear dependency injection may be more maintainable.
The Consumption plan cold start
The Consumption plan scales to zero and charges only when functions are executing. The trade-off is cold start latency: when a function that has been idle receives a request, the Functions host must be loaded, the .NET runtime initialised, and any startup code executed before the function can handle the request. For .NET 3.1 and 5 functions, cold starts add 1-3 seconds. The Premium plan keeps instances warm; the App Service plan is always-on. The right plan depends on latency requirements.