Python Azure Functions — Core Concepts

What Azure Functions Actually Is

Azure Functions is Microsoft’s serverless compute platform. You write individual functions in Python, deploy them to Azure, and the platform handles provisioning, scaling, and infrastructure. Each function responds to a specific trigger and can read or write data through bindings.

Think of it as event-driven plumbing: something happens → your code runs → the result goes somewhere.

The Programming Model (v2)

Azure Functions for Python uses a decorator-based programming model (v2) that feels natural to anyone who has used Flask or FastAPI:

import azure.functions as func
import logging

app = func.FunctionApp()

@app.route(route="hello", auth_level=func.AuthLevel.ANONYMOUS)
def hello(req: func.HttpRequest) -> func.HttpResponse:
    name = req.params.get("name", "World")
    return func.HttpResponse(f"Hello, {name}!")

No separate function.json configuration files — everything lives in Python code.

Triggers and Bindings

Triggers start your function. Each function has exactly one trigger:

Trigger Type	Fires When
HTTP	A web request arrives
Timer	A cron schedule fires
Blob Storage	A file is uploaded/changed
Queue Storage	A message lands in a queue
Cosmos DB	A document changes
Event Hub	A streaming event arrives
Service Bus	A message hits the bus

Bindings connect your function to data sources without boilerplate connection code. Input bindings read data; output bindings write it. For example, a function can trigger on an HTTP request, read from Cosmos DB via an input binding, and write to a queue via an output binding — all declared through decorators.

Cold Starts and the Consumption Plan

Azure offers three hosting plans:

• Consumption — scales to zero, pay per execution, but cold starts can add 1-10 seconds of latency on the first invocation after idle time
• Premium — pre-warmed instances eliminate cold starts, costs more but stays ready
• Dedicated (App Service) — runs on always-on VMs you already pay for

For Python specifically, cold starts on the Consumption plan are noticeable because the Python runtime and dependencies need loading. Teams with latency-sensitive endpoints often use the Premium plan or keep a lightweight “ping” timer to prevent full cold starts.

Project Structure

A typical Python Azure Functions project:

my-functions/
├── function_app.py      # all functions defined here
├── host.json            # runtime configuration
├── local.settings.json  # local dev secrets (gitignored)
├── requirements.txt     # Python dependencies
└── tests/
    └── test_hello.py

Local development uses func start from the Azure Functions Core Tools, which runs your functions on localhost with the same trigger/binding system.

Key Differences from AWS Lambda

• Azure Functions has native durable functions (orchestration, fan-out/fan-in, human interaction patterns) built into the platform
• Bindings reduce boilerplate — Lambda requires you to manually call AWS SDKs
• Azure’s v2 model uses decorators; Lambda uses handler functions with event/context parameters
• Azure integrates tightly with the broader Azure ecosystem (Cosmos DB, Event Grid, Service Bus)

Common Misconception

“Serverless means no servers.”

Servers absolutely exist — you just don’t manage them. Azure allocates compute resources behind the scenes. The “serverless” label means you don’t provision, patch, or scale servers yourself. You still need to think about execution timeouts (default 5 minutes on Consumption), memory limits, and concurrency behavior.

The one thing to remember: Azure Functions connects Python code to cloud events through triggers and bindings, letting you build reactive systems without managing infrastructure — but cold starts and execution limits require deliberate design choices.