LinkedIn

Cloud  /  Azure

Microsoft Azure 26 guides · updated 2026

Practical guides to Azure compute, networking, storage, and data services — built for engineers running production workloads on Microsoft's cloud.

Azure Functions: Event-Driven Serverless Compute With Rich Trigger Options

Azure Functions runs a piece of code in response to an event. You do not provision a server, configure autoscaling rules, or manage an OS. The runtime handles all of that — you write a function, choose what event fires it, and deploy. Azure scales from zero invocations per day to millions per hour without any configuration change on your part.

Functions shine for work that is intermittent, short-lived, or event-driven: processing a file upload, responding to an HTTP webhook, reacting to a new database record, or sending a notification after a queue message arrives.

Real-World Scenario

A retail company receives order CSVs from hundreds of franchises via blob upload every night. Each file lands in a container, triggers a Blob trigger function, the function parses the CSV, writes validated rows to Cosmos DB, and posts malformed rows to a dead-letter queue for manual review. The whole pipeline runs without a single server and costs almost nothing during the day when no files arrive.

Trigger and Binding Model

Functions use a declarative binding model. A trigger fires the function. Input bindings read data. Output bindings write data. You configure bindings in code attributes or a function.json file, and the runtime handles connection management, serialisation, and retry behaviour.

Function Binding Flow
----------------------
[External Event]
     |
  TRIGGER
     |
 FUNCTION CODE
  /        \
INPUT    OUTPUT
BINDING  BINDING
  |          |
Read      Write
data      data

Common triggers and their use cases:

Trigger          | Typical Use Case
-----------------|-----------------------------------------
HttpTrigger      | Webhook receivers, lightweight APIs
TimerTrigger     | Nightly reports, periodic cleanup jobs
BlobTrigger      | File processing pipelines
QueueTrigger     | Async task workers
ServiceBusTrigger| Ordered message processing with sessions
EventHubTrigger  | IoT telemetry, high-volume event streams
CosmosDBTrigger  | React to database change feed
EventGridTrigger | Cloud event routing and fan-out

Hosting Plans

The plan you choose has a direct impact on latency, cost, and capabilities:

Hosting Plan Comparison
-----------------------
Consumption Plan
  Billing:   Per execution + GB-seconds
  Scale:     0 to N instances automatically
  Cold start: Yes (mitigated by Premium or Always-on)
  VNet:      No


Premium Plan (Elastic Premium)
  Billing:   Per vCPU-second (minimum 1 warm instance)
  Scale:     Pre-warmed instances, no cold start
  VNet:      Yes (VNet Integration supported)
  Use when:  Sub-second latency needed, VNet access required


Dedicated (App Service Plan)
  Billing:   Plan capacity, whether used or not
  Scale:     Manual or autoscale rules
  VNet:      Inherits from App Service Plan
  Use when:  Long-running functions, predictable load


Flex Consumption (Preview)
  Combines per-execution billing with VNet support
  and faster scale-out than Consumption

For most production scenarios that need private connectivity, Premium is the practical choice. For cost-sensitive workloads with infrequent invocations and no VNet requirement, Consumption is hard to beat.

Cold Start Mitigation

Cold start happens when a Consumption-plan function has no warm instance. The runtime must load the host, your code, and any dependencies before handling the first request. Typical cold starts range from 1–3 seconds for compiled languages to 5–15 seconds for interpreted runtimes with large dependency trees.

Strategies to reduce cold start impact:

Durable Functions

Durable Functions extend Azure Functions with stateful workflows. The Durable Task Framework checkpoints state to Azure Storage between activities, so a long-running workflow survives restarts and host recycling.

Orchestration Patterns
-----------------------
Function Chaining:
  Starter -> Orchestrator -> Activity A -> Activity B -> Activity C


Fan-out / Fan-in:
  Orchestrator -+-> Activity A
                +-> Activity B   all in parallel
                +-> Activity C
                |
             WhenAll() -> Aggregate Results


Human Approval (External Event):
  Orchestrator waits for external event
  (e.g., manager clicks "Approve" in an email link)
  Resumes after event received


Monitor (Polling):
  Orchestrator checks a condition every N minutes
  until it's true or times out

The orchestrator function must be deterministic — it replays from history on every continuation. Never put I/O, random numbers, or DateTime.Now calls directly in the orchestrator; delegate them to activity functions.

HTTP-Triggered Function Example (Python)

import azure.functions as func
import json
import logging


app = func.FunctionApp()


@app.function_name(name="OrderProcessor")
@app.route(route="orders", methods=["POST"])
def process_order(req: func.HttpRequest) -> func.HttpResponse:
    try:
        body = req.get_json()
    except ValueError:
        return func.HttpResponse("Invalid JSON", status_code=400)


    order_id = body.get("order_id")
    if not order_id:
        return func.HttpResponse("Missing order_id", status_code=422)


    logging.info("Processing order %s", order_id)
    # business logic here
    return func.HttpResponse(
        json.dumps({"status": "accepted", "order_id": order_id}),
        mimetype="application/json",
        status_code=202
    )

Timer-Triggered Function With Output Binding (C#)

[Function("NightlyReport")]
[BlobOutput("reports/{DateTime}-summary.json", Connection = "AzureWebJobsStorage")]
public static string Run(
    [TimerTrigger("0 0 2 * * *")] TimerInfo timer,
    FunctionContext ctx)
{
    var log = ctx.GetLogger<Program>();
    log.LogInformation("Nightly report started at {Time}", DateTime.UtcNow);


    var report = new { GeneratedAt = DateTime.UtcNow, RecordCount = 5432 };
    return System.Text.Json.JsonSerializer.Serialize(report);
}

The BlobOutput binding writes the return value directly to Blob Storage without any SDK calls in the function body.

Architecture: Event-Driven Order Pipeline

[E-commerce Site]
      |
  HTTP POST /orders
      |
[OrderIngestion Function]  (HttpTrigger, Premium Plan)
      |
  Publishes to Service Bus queue
      |
[OrderProcessor Function]  (ServiceBusTrigger)
      |
  +---+---+
  |       |
Write   Write
to      to
CosmosDB  Event Hub
      |
[NotificationFunction]  (EventHubTrigger)
      |
  Sends email / SMS via SendGrid output binding

Key Interview Points

Best Practices