Azure App Service & Serverless
Azure App Service hosts web apps, APIs and mobile backends with managed scaling, TLS and deployment slots. Azure Functions runs event-driven code without provisioning servers. Learn what App Service offers, how Functions fits the serverless model, and when to reach for each.
What is this?
Azure App Service is a fully managed platform for hosting web apps, REST APIs and mobile backends. It handles TLS, patching, load balancing and scaling, and adds CI/CD integration plus deployment slots for zero-downtime releases. Azure Functions is the event-driven serverless option: you deploy a function with a trigger (HTTP, timer, queue, blob) and Azure runs it only when events arrive, billing per execution.
Why do you need it?
- App Service removes server management — deploy code, get HTTPS, scaling and slots for free.
- Deployment slots enable staged rollouts and instant rollback without redeploying.
- Functions lets you build event-driven glue and APIs that cost almost nothing when idle.
- Both are core answers to 'how do you ship without managing infrastructure?' in interviews.
- App Service Plans let you choose shared, dedicated or elastic compute with autoscaling.
Mental model
A managed restaurant with a catering service
App Service and Azure Functions
App Service is the restaurant: you bring the recipes (code), and the house handles the building, staff and fire safety (patches, TLS, scaling). The catering kitchen (Azure Functions) only cooks when a booking arrives — a wedding (HTTP trigger), a shipment (queue trigger) or the daily schedule (timer) — and you pay per event rather than for a rented kitchen sitting idle.
How it works
- You create an App Service Plan, which defines the compute tier (shared, dedicated, or elastic premium).
- A web app in the plan holds your code and config; App Service binds TLS, load-balances and runs the app on managed VMs.
- Deployment slots are separate live environments (staging, production) you swap to release with rollback.
- Azure Functions apps run on a Consumption plan that scales to zero and bills per execution, or on a premium/dedicated plan for warm instances.
- Triggers (HTTP, Timer, Queue, Blob, Event Grid) invoke a function when an event occurs; bindings wire inputs and outputs.
Serving a web app with slots and triggering serverless functions.
Key commands
az appservice plan create --name dev-plan --resource-group rg-dev --sku B1 --is-linuxCreate an App Service plan on the Basic tier.
az webapp create --name devops-app --resource-group rg-dev --plan dev-plan --runtime "NODE|20-lts"Create a Linux web app on the plan.
az webapp deployment slot create --name devops-app --resource-group rg-dev --slot stagingCreate a staging deployment slot.
az webapp deployment slot swap --name devops-app --resource-group rg-dev --slot staging --target-slot productionSwap staging into production with zero downtime.
az functionapp create --name devops-fn --resource-group rg-dev --consumption-plan-location eastus --runtime nodeCreate a serverless function app on the consumption plan.
az functionapp list --resource-group rg-dev --output tableList function apps in the resource group.
Examples
Create an App Service plan, web app and a Function App
$ az appservice plan create --name dev-plan --resource-group rg-dev \ --sku B1 --is-linux{ "id": "/subscriptions/.../serverfarms/dev-plan", "sku": { "name": "B1", "tier": "Basic" }} $ az webapp create --name devops-app --resource-group rg-dev \ --plan dev-plan --runtime "NODE|20-lts"{ "name": "devops-app", "defaultHostName": "devops-app.azurewebsites.net", "state": "Running"} $ az functionapp create --name devops-fn --resource-group rg-dev \ --consumption-plan-location eastus --runtime node{ "name": "devops-fn", "defaultHostName": "devops-fn.azurewebsites.net"}The plan decides compute and cost. The web app gets a public default hostname and an App Service runtime (here Node 20). The function app on a consumption plan needs no dedicated compute — Azure provisions it on demand and bills per execution, so it costs nothing while idle.
In production
- Host customer-facing web apps and REST APIs on App Service with slots for every release.
- Use Functions for webhooks, queue workers, file-processing pipelines and scheduled jobs.
- Apply autoscaling rules on the plan to grow with traffic and shrink at night.
- Gate deployments with App Service Authentication and bring your own identity via Managed Identity.
- Combine Functions with Event Grid or Service Bus to react to platform events across your estate.
Best practices
- Deploy to a staging slot, smoke-test, then swap — never push straight to production.
- Put connection strings and keys in App Settings backed by Key Vault, not in code or config files.
- Keep Functions short-lived and idempotent so retries are safe under at-least-once delivery.
- Set autoscale minimums that avoid both cold-start latency and idle spend.
- Use the premium plan when Functions need VNet access, longer timeouts or always-warm instances.
Common mistakes
- Choosing a dedicated plan that is far bigger than the load and paying for idle cores.
- Deploying straight to production and only discovering the breakage from the pager.
- Writing long-running stateful work in Functions, which expects stateless short-lived invocations.
- Hard-coding secrets in app code instead of App Settings / Key Vault.
- Ignoring the plan's scaling limits — a B1 plan does not autoscale.
Common issues
HTTP 503 The service is unavailableThe app crashed, is still starting, or the plan is over its compute or disk quota.
Tail logs with az webapp log tail, confirm the runtime string, and check plan usage against SKU limits.
Function timeout after 5 minutesThe consumption plan caps execution duration (default 5 minutes).
Move to the premium plan for longer timeouts, or split the work into smaller messages processed per invocation.
Slot swap succeeds but the app misbehavesSlot-specific settings (connection strings, app settings) did not carry over as expected.
Configure slot settings so configuration follows the slot, and validate against staging before the swap.
Debugging tips
- Check the App Service logs (Log Stream) before guessing — errors appear instantly on deployments.
- Use az webapp log tail to follow live logs from a slot during a staged rollout.
- For Functions, look at Invocation details in Application Insights to see duration, retries and failures.
- Verify the runtime string matches the platform (NODE|20-lts vs NODE|18-lts) — mismatch breaks startup.
- Test a slot swap with a dry-run using the same health-check settings you use in production.
Interview checkpoint
Hands-on lab
- Create production and staging environments
- Deploy a version to staging and promote it with a swap
- Simulate an HTTP-triggered function
- Roll back to the previous version
Simulate Slot Staging and Event-Driven Functions
20 min · beginner
Quick quiz
Which App Service feature allows zero-downtime releases with instant rollback?
An Azure Function on the consumption plan costs nothing when no events trigger it.
A queue-triggered function processes each order twice. What is the most likely cause?
Cheat sheet
App Service PlanCompute tier — shared, basic, premiumWeb appHosts code with TLS and scaling managedDeployment slotStaging env, swap for zero-downtimeApp SettingsConfig, secrets via Key VaultConsumption planScales to zero, pay per executionPremium planAlways warm, VNet, longer timeoutsTriggersHTTP, timer, queue, blob, Event GridBindingsDeclarative inputs/outputs