What Is Serverless Compute?
Azure Functions lets you deploy a single function — a discrete unit of code — that Azure automatically triggers, scales, and bills per execution, rather than requiring you to provision and run a server continuously. On the Consumption plan, you pay only for the compute time your function actually consumes (measured in gigabyte-seconds) plus the number of executions, and Azure scales your function instances from zero up to handle bursts of trigger events, then scales back to zero when idle, so there's no cost for idle capacity.
Cricket analogy: Azure Functions on the Consumption plan is like a stadium hiring extra ground staff only for match days and paying them by the hour worked, instead of keeping a full-time crew on payroll year-round for a ground used only occasionally.
Triggers and Bindings
A function is invoked by exactly one trigger — an HTTP request, a new message on a Service Bus queue or Storage Queue, a Timer on a CRON schedule, a new blob uploaded to Storage, or a Cosmos DB change feed event, among others — and can additionally use input and output bindings to declaratively read from or write to other services (like writing a document to Cosmos DB) without hand-writing the SDK connection code. This declarative binding model means a function that reads a queue message and writes a database row can often be written with almost no boilerplate connection logic — the trigger and bindings handle it via configuration.
Cricket analogy: A trigger is like the exact ball that dismisses a batter — a yorker, a googly, a slower ball — while bindings are like the fielder positioned to complete the catch automatically once the ball is in the air, without needing separate instructions.
Hosting Plans
Beyond the Consumption plan, the Premium plan keeps a configurable number of 'pre-warmed' instances always ready to eliminate cold starts, supports VNet integration, and allows longer execution timeouts; the Dedicated (App Service) plan runs functions on the same VMs as an App Service Plan you already own, useful when you want predictable, always-on capacity; and the newer Flex Consumption plan combines scale-to-zero economics with configurable always-ready instances. Choosing the right plan is a tradeoff between cost, cold-start latency tolerance, and whether the function needs private network access.
Cricket analogy: Choosing a hosting plan is like deciding between fielding a specialist bowler only for the death overs (Consumption) versus keeping a warmed-up strike bowler on standby in the changing room the whole innings so there's zero delay bringing them on (Premium).
import azure.functions as func
import logging
app = func.FunctionApp()
@app.function_name(name="HttpProcessOrder")
@app.route(route="orders", methods=["POST"])
@app.cosmos_db_output(
arg_name="orderDoc",
database_name="shopdb",
container_name="orders",
connection="CosmosDbConnection")
def process_order(req: func.HttpRequest, orderDoc: func.Out[func.Document]) -> func.HttpResponse:
order = req.get_json()
logging.info(f"Processing order {order['id']}")
orderDoc.set(func.Document.from_dict(order))
return func.HttpResponse(status_code=201)Durable Functions extend Azure Functions with stateful orchestration patterns — function chaining, fan-out/fan-in, and human-interaction workflows — letting you coordinate multiple functions as a reliable, checkpointed workflow without managing your own state machine.
Consumption-plan functions have a default execution timeout of 5 minutes (configurable up to 10). A function performing a long-running task like a large file conversion will be killed mid-execution unless you redesign it as a Durable Function orchestration or move to a plan with a longer timeout.
Cold Starts and Performance
A cold start happens when the Consumption plan needs to allocate a new instance to handle a trigger after scaling to zero — the runtime must initialize the host, load your function's dependencies, and run any startup code before the first request completes, adding noticeable latency (often 1-10+ seconds depending on language and dependency size). You can reduce cold-start impact by keeping deployment packages small, avoiding heavy dependency injection at startup, using a compiled language (like C# or Go) over an interpreted one for latency-sensitive paths, or moving to the Premium plan's pre-warmed instances if consistent low latency matters more than minimizing idle cost.
Cricket analogy: A cold start is like a substitute fielder coming on cold from the boundary rope and needing a few overs to find their rhythm and reaction time, compared to a fielder who has been active and warmed up throughout the innings.
- Azure Functions is serverless: Azure scales instances from zero and bills per execution (gigabyte-seconds) on the Consumption plan.
- A function has exactly one trigger (HTTP, Timer, Queue, Blob, Cosmos DB change feed, etc.) plus optional input/output bindings.
- The Premium plan eliminates cold starts via pre-warmed instances and supports VNet integration and longer timeouts.
- Consumption-plan functions default to a 5-minute execution timeout (max 10); long-running work needs Durable Functions or a different plan.
- Cold starts add latency when scaling from zero; smaller packages and compiled languages reduce their impact.
- Durable Functions add stateful orchestration patterns like fan-out/fan-in on top of the core Functions model.
Practice what you learned
1. What is the defining characteristic of the Azure Functions Consumption plan?
2. How many triggers can a single Azure Function have?
3. What causes a 'cold start' in Azure Functions?
4. Which Azure Functions feature is best suited for coordinating a multi-step, stateful workflow across several functions?
5. What is the default execution timeout on the Consumption plan?
Was this page helpful?
You May Also Like
Azure App Service
Azure App Service is a fully managed Platform-as-a-Service for hosting web apps, REST APIs, and mobile backends without managing the underlying VMs or OS.
Azure Container Instances
Azure Container Instances (ACI) runs individual containers directly in Azure without provisioning VMs or managing a container orchestrator like Kubernetes.
VM Scale Sets
Azure Virtual Machine Scale Sets let you deploy and manage a group of identical, load-balanced VMs that automatically grow or shrink based on demand.