How many nines?
On Dashain the momo shop takes more orders in a day than in a normal month. If the site is down for an hour, that's real money. Azure publishes an SLA for each service — a promised percentage of uptime — but your site is several services chained together, and the chain is weaker than any one link.
Today you'll meet Azure's main ways to run code, from renting a whole VM to handing over just a function, and work out what uptime a whole architecture can promise.
From VMs to functions
- Virtual machines (IaaS): you choose the size (D-series general purpose, B-series burstable…), OS image, disks and network, and you patch the OS. Scale sets add identical VMs automatically.
- App Service (PaaS): deploy web code or a container; an App Service plan supplies the VMs. Free and Basic tiers for dev/test, Standard and Premium for production (autoscale, deployment slots), Isolated for a private App Service Environment.
- Azure Functions: event-triggered code. On the Consumption plan you pay per execution and Azure scales to zero; Premium and dedicated plans trade cost for warm, predictable performance.
- Containers: Azure Container Instances runs one container group with no servers to manage; Azure Container Apps runs microservices; Azure Kubernetes Service (AKS) gives you managed Kubernetes for many containers; images live in Azure Container Registry.
The further down this list you go, the less you manage and the less you control. A good rule: pick the most managed service that still does what you need, so Microsoft carries the patching, scaling and failover.
Deployment slots (App Service Standard tier and up) let you deploy to a staging copy, warm it up, then swap it into production with no downtime — and swap back if it breaks.