Azure Functions

Azure Functions is an event-driven serverless compute platform on Azure. You write small pieces of code that run in response to events (an HTTP request, a timer, a message arriving on a queue) and Azure handles the infrastructure: provisioning, scaling, and runtime management.

Functions is the fastest path from “something happened” to “code is running” on Azure.

Core Model: Triggers and Bindings

Every function has exactly one trigger that defines what starts it. Functions can also have bindings that provide declarative connections to other services, removing boilerplate for reading input and writing output.

flowchart LR
    subgraph Triggers
        HTTP["HTTP Request"]
        Timer["Timer / Cron"]
        Queue["Queue Message"]
        Blob["Blob Created"]
        Cosmos["Cosmos DB\nChange Feed"]
        EventHub["Event Hub\nMessage"]
        ServiceBus["Service Bus\nMessage"]
    end

    subgraph Function["Azure Function"]
        Code["Your Code"]
    end

    subgraph Bindings["Output Bindings"]
        OutQueue["Queue"]
        OutBlob["Blob Storage"]
        OutCosmos["Cosmos DB"]
        OutHTTP["HTTP Response"]
    end

    HTTP --> Code
    Timer --> Code
    Queue --> Code
    Blob --> Code
    Cosmos --> Code
    EventHub --> Code
    ServiceBus --> Code

    Code --> OutQueue
    Code --> OutBlob
    Code --> OutCosmos
    Code --> OutHTTP

Triggers start execution. Your code runs because something happened.

Bindings simplify I/O. Instead of writing SDK boilerplate to connect to Cosmos DB or Blob Storage, you declare a binding and the runtime handles connection management and serialization.

Common Triggers

There are also triggers for Event Grid, SignalR, Kafka, RabbitMQ, and others.

Durable Functions

Standard functions are stateless and short-lived. Durable Functions extends the model for stateful orchestration:

• Orchestrator functions define workflows as code, with automatic checkpointing and replay
• Activity functions are the individual steps in the workflow
• Entity functions provide durable, addressable state objects

Common patterns: function chaining, fan-out/fan-in, async HTTP APIs, monitoring (polling loops), and human-in-the-loop approval flows.

Durable Functions is the answer when you need multi-step coordination without bringing in a separate workflow engine.

Hosting Plans

Start with Flex Consumption unless you have a specific reason for another plan. Move to Premium when you need consistent warm capacity or VNet integration. Move to containers when you need full control over the runtime environment.

Language Support

Functions supports C#, JavaScript, TypeScript, Python, Java, PowerShell, Go (custom handler), and Rust (custom handler). The isolated worker model (recommended for .NET) runs your code in a separate process from the Functions host, giving you full control over dependencies.

When Functions Fits

Functions is the right choice when:

• Work is event-driven: something happens, code reacts
• Execution is short-lived (seconds to a few minutes)
• Traffic is bursty or unpredictable
• You want minimal infrastructure management
• The workload is a collection of handlers, not a monolithic service

When To Move Beyond Functions

Consider containers (Container Apps), App Service, or VMs when:

• Long-running processes that exceed execution time limits or are awkward in function boundaries
• Complex runtime dependencies that need full control over the OS or installed software
• Steady, high-throughput workloads where always-on compute is simpler than serverless scaling
• Large application surface area where you are building a service, not a collection of handlers
• Machine-level control for performance tuning, GPU access, or specialized networking

The important thing is recognizing when the workload shape has changed. Functions is great glue; it is not a replacement for a full application server when the problem calls for one.

In Entra-Adjacent Systems

Azure Functions commonly appears in Entra-related automation:

• Graph polling: scheduled functions that call Microsoft Graph delta queries to detect directory changes (new users, group membership updates, app registration changes)
• Webhook handlers: HTTP-triggered functions that receive Graph change notifications or provisioning callbacks
• Event processing: functions consuming identity-related events from Event Hubs or Service Bus, performing enrichment, validation, or routing
• Provisioning helpers: functions that respond to provisioning outcomes, reconcile state between systems, or handle error recovery
• Export pipelines: timer-triggered functions that pull audit logs or reporting data and push it to storage or analytics

A typical pattern: a timer-triggered function calls Graph, detects changes via delta queries, stores checkpoints in Cosmos DB, and enqueues follow-up work in Service Bus. Functions is the compute glue between Graph and the rest of the platform.