Serverless compute

Azure Functions

Event-driven, serverless code: write the function, declare what triggers it and what data it binds to, and the platform handles servers, scale (including to zero) and connections. The unit of design is the event, not the server.

Triggers & bindings

Triggers start execution (exactly one per function). Bindings declaratively connect inputs/outputs so your code receives a queue message or writes a Cosmos DB doc without SDK plumbing.

flowchart LR
    subgraph Triggers
        H[HTTP request]
        Q[Service Bus / Storage queue]
        E[Event Grid / Event Hubs]
        Ti[Timer / cron]
        CD[Cosmos DB change feed]
        B[Blob created]
    end
    F["Function code
C# · Python · JS/TS · Java · PowerShell"]
    subgraph Output bindings
        O1[Cosmos DB]
        O2[Service Bus]
        O3[Blob / Table]
        O4[SignalR]
        O5[HTTP response]
    end
    H --> F
    Q --> F
    E --> F
    Ti --> F
    CD --> F
    B --> F
    F --> O1
    F --> O2
    F --> O3
    F --> O4
    F --> O5
      

Hosting plans

Durable Functions

Code-first orchestration on top of Functions: orchestrator functions await activities, sleep for days, and survive restarts via event-sourced state. The core serverless workflow patterns:

flowchart TB
    subgraph Chaining[Function chaining]
        A1[F1] --> A2[F2] --> A3[F3]
    end
    subgraph FanOut[Fan-out / fan-in]
        B0[Orchestrator] --> B1[Work 1]
        B0 --> B2[Work 2]
        B0 --> B3[Work N]
        B1 --> BA[Aggregate]
        B2 --> BA
        B3 --> BA
    end
    subgraph Human[Human interaction]
        C1[Request approval] --> C2{Wait for event
or 72h timeout}
        C2 -->|approved| C3[Proceed]
        C2 -->|timeout| C4[Escalate]
    end
      

• Async request-reply: HTTP starter returns 202 + status URL; orchestration runs minutes/hours; client polls. Pairs perfectly with APIM.
• Durable entities: small stateful objects (per-device, per-user counters/aggregators).
• Saga / compensation: orchestrator calls compensating activities when a step fails mid-transaction.

Functions in AI architectures

• Agent tools: HTTP functions registered as tools for AI Foundry agents (or exposed as MCP tools via APIM) — deterministic actions the model can invoke.
• Remote MCP servers: build MCP servers on Functions with the MCP tool trigger — serverless tool hosting with auth and scale handled.
• RAG ingestion: blob trigger → chunk/embed → push to AI Search; change-feed triggers keep indexes fresh.
• Real-time AI: Event Hubs trigger for streaming enrichment/inference at scale.

Detailed use cases

Best practices

• Prefer Flex Consumption for new apps; use always-ready instances for latency-sensitive HTTP.
• Keep functions idempotent — every trigger type can deliver at-least-once.
• Use managed identity in bindings (identity-based connections), not connection strings.
• One responsibility per function; compose with Durable Functions or queues, not giant handlers.
• Set maxConcurrentCalls/batch sizes deliberately for queue/stream triggers; measure, don't guess.

Key references

• Functions documentation
• Flex Consumption plan
• Durable Functions patterns
• Triggers & bindings reference