Azure Functions

After this lesson, you will be able to: Build Azure Functions: HTTP / timer / queue triggers, bindings, and local development with Azure Functions Core Tools.

Functions is Azure's serverless. Same model as Lambda but with cleaner input/output binding semantics.

Prerequisites:App Service

Functions vs Lambda

Same idea: write a function, AWS / Azure runs it on a trigger. Azure's edge: BINDINGS. Declare 'this Function reads from queue X' or 'writes to blob Y' in the function metadata; SDK injects values, you don't write boilerplate. Pricing: Consumption (pay per execution + GB-s) or Premium (warmer, more memory, VNet support) or App Service plan (run with your other apps; flat cost). Cold starts: similar to Lambda. Use Premium plan if cold starts hurt.

An HTTP-triggered Function (Node.js v4 model)

Modern programming model; no separate function.json needed.

bash

// src/functions/hello.js
import { app } from '@azure/functions';

app.http('hello', {
  methods: ['GET', 'POST'],
  authLevel: 'anonymous',
  handler: async (request, context) => {
    const name = request.query.get('name') ?? 'world';
    context.log(`Hello, ${name}`);
    return { body: `Hello, ${name}!` };
  },
});

// Local dev:
npm install -g azure-functions-core-tools@4
func start                            # runs locally on http://localhost:7071

// Deploy:
az functionapp create -n myfunc-yourname -g rg-myapp \
  --storage-account <storage-name> --consumption-plan-location eastus \
  --runtime node --runtime-version 20 --functions-version 4
func azure functionapp publish myfunc-yourname

Triggers + bindings

Trigger: what fires the function. HTTP, Timer (cron), Queue, Blob, Cosmos DB, Service Bus, Event Grid. Input binding: data injected into the function (e.g. 'read blob X and pass as a parameter'). Output binding: data the function returns goes to (e.g. 'write the return value to Queue Y'). Bindings reduce boilerplate. A function that reads a queue + writes to a blob can be 10 lines.

Timer trigger (cron)

Most common pattern after HTTP.

python

import { app } from '@azure/functions';

app.timer('cleanup', {
  schedule: '0 0 3 * * *',          // every day at 03:00 UTC
  handler: async (timer, context) => {
    context.log('Daily cleanup running');
    // ... your cleanup logic
  },
});

// Schedule format: NCRONTAB (sec min hour day month dayOfWeek)
// 0 */15 * * * *   every 15 minutes
// 0 0 9 * * 1-5    weekdays at 09:00

When NOT to use Functions

Long-running jobs (> 10 min on Consumption, > 30 min on Premium). Use Container Apps Jobs. Heavy CPU / GPU work. Use VMs. Stateful workloads. Use Durable Functions (a stateful Functions extension) or step into a real DB. Apps that need full HTTP server features (websockets, long polling). Use App Service.

Common mistakes only experienced engineers avoid

Initializing SDK clients per invocation. Cold-start hit. Reuse across warm calls. Storing secrets in app settings unencrypted. Use Key Vault references. Forgetting to set timeout / memory. Defaults often wrong for real workloads. Not using bindings. Reading queues / blobs manually duplicates code the platform handles for free. Skipping Application Insights. Functions + App Insights is one toggle; you'll need the traces.

Quick Check

What's the advantage of Azure Functions bindings over Lambda's event payload model?

Pick the cleanest answer.

←Azure App Service

Back to Cloud Platforms — Microsoft Azure

Azure Blob Storage→