Azure Functions Overview: Serverless Compute for Event-Driven Tasks

What serverless actually means

Serverless does not mean no servers — it means servers are abstracted away from you. Azure Functions runs your code on shared compute infrastructure managed entirely by Microsoft. You do not provision instances, configure scaling rules, or patch operating systems. Your function runs, Azure bills for the duration of that run, and then the compute resource returns to the pool.

The operational model is fundamentally different from VMs or App Service. With a VM, you pay whether or not requests are coming in. With Functions on the Consumption plan, you pay only when your code is actively executing. For workloads that run infrequently — a few thousand invocations per day — Functions can cost a fraction of a cent per day.

Triggers: what starts a function

Every Azure Function has exactly one trigger — the event that causes it to execute. Common triggers:

The trigger system is what makes Functions powerful for event-driven architectures. Rather than polling for changes (expensive, slow, complex), you declare what event should cause your code to run and Azure handles the rest.

Your first function: HTTP triggered

A minimal Python HTTP-triggered function:

# function_app.py
import azure.functions as func
import json
import logging

app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)

@app.route(route="hello")
def hello_http(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('HTTP trigger function processed a request.')

    name = req.params.get('name') or 'world'

    return func.HttpResponse(
        json.dumps({"message": f"Hello, {name}!"}),
        mimetype="application/json",
        status_code=200
    )

Deploy with the Azure Functions Core Tools or CLI:

# Install Azure Functions Core Tools
npm install -g azure-functions-core-tools@4 --unsafe-perm true

# Create a new Function App in Azure
az functionapp create \
  --resource-group my-rg \
  --consumption-plan-location eastus \
  --runtime python \
  --runtime-version 3.11 \
  --functions-version 4 \
  --name my-unique-func-app \
  --storage-account mystorageaccount

# Deploy from your local project directory
func azure functionapp publish my-unique-func-app

Hosting plans: Consumption, Premium, and Dedicated

The hosting plan determines how your functions are billed and what performance characteristics they have:

Consumption plan

Pay only for execution time and memory consumed. Scales to zero between invocations — no charge when idle. Maximum execution duration: 10 minutes. Risk of cold starts when the runtime has been idle. Best for workloads with intermittent, unpredictable traffic or very infrequent jobs.

Flex Consumption plan (newer)

Microsoft’s updated Consumption model with faster scaling, per-instance concurrency control, and virtual network integration. Similar billing to Consumption but with improved cold start behaviour. Recommended over the original Consumption plan for new functions deployments as of 2024.

Premium plan

Pre-warmed instances eliminate cold starts. Minimum one always-running instance (you pay for it even when no functions execute). Maximum unlimited execution duration. VNet integration for private resource access. Best for functions that need consistent low-latency response times or access private Azure resources.

Dedicated (App Service) plan

Functions run on the same App Service Plan you configure — no cold starts, unlimited duration, predictable cost. Best for long-running functions or when you already have an App Service Plan with spare capacity. Loses the cost-per-execution billing model entirely.

Bindings: reading from and writing to services

Azure Functions has a bindings system that simplifies connecting functions to Azure services. Instead of writing code to open a Storage Queue connection, poll for messages, and acknowledge them, you declare a Queue trigger in the function definition and Azure handles the infrastructure:

@app.queue_trigger(arg_name="msg", queue_name="work-queue",
                   connection="AzureWebJobsStorage")
def process_queue_item(msg: func.QueueMessage) -> None:
    logging.info(f"Processing message: {msg.get_body().decode('utf-8')}")

    # Your processing logic here
    # Azure automatically acknowledges the message when the function returns
    # If the function throws an exception, the message returns to the queue

Output bindings write to services without manual connection management:

@app.route(route="create-task")
@app.queue_output(arg_name="outputQueueItem",
                  queue_name="work-queue",
                  connection="AzureWebJobsStorage")
def http_create_task(
    req: func.HttpRequest,
    outputQueueItem: func.Out[str]
) -> func.HttpResponse:

    task_data = req.get_json()
    outputQueueItem.set(json.dumps(task_data))

    return func.HttpResponse("Task queued", status_code=202)

The output binding queues the message automatically when the function returns. No queue client code, no connection string management in the function body.

When Functions is the right choice

• Short-lived event processing (image resizing, document conversion, notification sending)
• Scheduled tasks that run on a CRON schedule (nightly cleanup, daily reports)
• Webhook handlers for external service events
• Asynchronous background work triggered from a queue
• Glue code between other Azure services (reacting to Event Grid events, bridging Service Bus to a database)

Functions is a poor choice for:

• Long-running processing (over 10 minutes on Consumption plan)
• Low-latency APIs where consistent sub-100ms response times are required (cold starts make this unpredictable on Consumption)
• Stateful workflows where data must persist across function invocations (use Durable Functions for this)