Three fundamental ways to run code in Azure — virtual machines, containers, functions — plus the redundancy features and hosting options built on top of them.
Your app gets an unpredictable traffic spike. You want compute that scales out fastest, needs zero babysitting, and bills you only for the seconds it actually runs. Which of the three compute types below fits — and why does it beat the other two on this specific requirement?
| Virtual machines | Containers | Functions | |
|---|---|---|---|
| You manage | OS, patching, everything above hardware | Just the app + its dependencies, packaged together | Just the code |
| Startup speed | Slowest (minutes) | Fast (seconds) | Fastest — wakes on an event |
| Billed for | Time the VM is provisioned | Time the container runs | CPU time while the function executes |
| Best fit | Full OS control, custom configs, lift-and-shift | Microservices, portable/consistent environments | Short, event-triggered, variable-demand work |
Calibration answer: Azure Functions. It's serverless — the term from Lesson 1 — so it wakes on the triggering event, scales automatically, and deallocates the instant it's done, billing only for that CPU time. A VM would sit provisioned (and billed) whether or not it's busy; a container is lighter than a VM but still something you keep running.
An Azure VM is IaaS: you get full control of the OS and installed software, and you're responsible for patching it. Common scenarios: test/dev environments spun up and torn down fast, lift-and-shift migrations, extending an on-prem datacenter into Azure, disaster recovery failover capacity, and general cloud app hosting.
Provisioning a VM means choosing three resource categories: size (CPU cores, RAM — grouped into families like B-series for burstable/cheap dev workloads or N-series for GPU-heavy AI/graphics work), storage disks, and networking (virtual network, public IP, ports).
Reading a VM size name: Standard_D2s_v5 breaks down as D = family (general purpose), 2 = vCPU count, s = supports Premium SSD, v5 = hardware generation.
Virtual machine scale sets — a group of identical VMs that automatically scales out or in based on demand, with built-in load balancing. This is about elastic capacity.
Availability sets — a group of VMs spread across fault domains (shared power/network risk) and update domains (rebooted together during maintenance), so one hardware failure or maintenance event can't take all your VMs down at once. This is about resiliency, not scale — availability sets don't add cost themselves; you pay only for the VM instances.
Azure Virtual Desktop is a separate VM-based option: a managed service that streams full Windows desktops and apps to users' devices, centrally managed and integrated with Microsoft Entra ID. Think distributed or contractor workforces who all need the same standardized desktop, without you building a VM-per-user by hand.
A container packages an app with its dependencies, but — unlike a VM — doesn't include its own OS; containers share the host's OS kernel, which is why they start in seconds instead of minutes and let you run many isolated apps on one host. Azure offers three container services at increasing levels of management:
| Service | What it is |
|---|---|
| Azure Container Instances | PaaS — fastest, simplest way to run a single container, no VMs or orchestration to manage |
| Azure Container Apps | PaaS — like Container Instances plus built-in load balancing and autoscaling |
| Azure Kubernetes Service (AKS) | Orchestration — manages the full lifecycle of a fleet of containers |
Beyond raw compute, Azure App Service is a dedicated PaaS for hosting web apps, REST APIs, and mobile back-ends — with autoscaling and high availability built in, and no infrastructure to manage. It sits at the "least operational effort" end of a spectrum that starts with VMs (most control) and passes through containers along the way.