Microsoft Azure
Beginner 13 min read Microsoft Azure

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.

App Serviceweb appdeployment slotplanauto-scalingAzure Functionsserverlesstriggereventconsumption plan
Introduction

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.

Motivation

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.
Think about it

Mental model

Imagine

A managed restaurant with a catering service

Think of

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.

Mechanics

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.

Create App Service Plan
Deploy code to a web app
Validate in staging slot
Swap to production
Events hit Functions
Scale on demand
Reference

Key commands

az appservice plan create --name dev-plan --resource-group rg-dev --sku B1 --is-linux

Create 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 staging

Create a staging deployment slot.

az webapp deployment slot swap --name devops-app --resource-group rg-dev --slot staging --target-slot production

Swap staging into production with zero downtime.

az functionapp create --name devops-fn --resource-group rg-dev --consumption-plan-location eastus --runtime node

Create a serverless function app on the consumption plan.

az functionapp list --resource-group rg-dev --output table

List function apps in the resource group.

Hands-on

Examples

Create an App Service plan, web app and a Function App

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.

Real world

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.
Guidelines

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.
Watch out

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.
Root cause analysis

Common issues

Error
HTTP 503 The service is unavailable
Root cause

The app crashed, is still starting, or the plan is over its compute or disk quota.

Fix

Tail logs with az webapp log tail, confirm the runtime string, and check plan usage against SKU limits.

Error
Function timeout after 5 minutes
Root cause

The consumption plan caps execution duration (default 5 minutes).

Fix

Move to the premium plan for longer timeouts, or split the work into smaller messages processed per invocation.

Error
Slot swap succeeds but the app misbehaves
Root cause

Slot-specific settings (connection strings, app settings) did not carry over as expected.

Fix

Configure slot settings so configuration follows the slot, and validate against staging before the swap.

When things break

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.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Slot Staging and Event-Driven Functions
20 min · beginner
In progress
Objectives
  • 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

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which App Service feature allows zero-downtime releases with instant rollback?

2

An Azure Function on the consumption plan costs nothing when no events trigger it.

3

A queue-triggered function processes each order twice. What is the most likely cause?

Quick reference

Cheat sheet

App Service
App Service PlanCompute tier — shared, basic, premium
Web appHosts code with TLS and scaling managed
Deployment slotStaging env, swap for zero-downtime
App SettingsConfig, secrets via Key Vault
Serverless
Consumption planScales to zero, pay per execution
Premium planAlways warm, VNet, longer timeouts
TriggersHTTP, timer, queue, blob, Event Grid
BindingsDeclarative inputs/outputs
Go deeper

Official documentation