Episode 1 — The Azure Compute Landscape: Choosing the Right Service

You already know the cloud promise: someone else's datacenter, your workloads, pay for what you use. This episode turns that general idea into a concrete map of Azure's compute services — and gives you a repeatable way to pick the right one.

Learning objectives

• Explain the IaaS → PaaS → serverless spectrum and how the shared responsibility model shifts along it.
• Describe each of Azure's seven main compute services in one or two sentences.
• Choose a compute service for a given scenario using four decision criteria and a decision tree.
• Explain the Azure resource hierarchy (resource → resource group → subscription → management group) and what regions and availability zones are.

Why it matters

Almost every Azure design conversation — and a large share of AZ-104 exam questions — starts with the same question: where should this workload run? Pick a VM when App Service would do, and you inherit years of patching work you didn't need. Pick Azure Functions for a stateful monolith, and you'll fight the platform forever. The compute catalog looks crowded, but it follows one simple axis: how much control you keep versus how much management you hand to Azure. Learn that axis once, and every later episode — VMs, scale sets, App Service, containers — slots into place.

From ownership to outcomes: the IaaS–PaaS–serverless spectrum

Every compute service answers the same underlying question: who manages which layer of the stack?

• IaaS (Infrastructure as a Service) — Azure gives you virtualized hardware: compute, storage, network. You bring and manage the operating system, runtime, and application. Azure Virtual Machines are the canonical example. Maximum control, maximum operational responsibility.
• PaaS (Platform as a Service) — Azure manages the OS and runtime; you bring code and configuration. App Service is the flagship: you deploy an app, Azure patches the servers underneath.
• Serverless — you bring functions or containers and pay per execution or per active replica; the platform handles provisioning and scaling, often down to zero when idle. Azure Functions and Azure Container Apps live here.

These are points on a spectrum, not rigid boxes. AKS, for example, is IaaS-flavored PaaS: Azure manages the Kubernetes control plane, you manage what runs on the nodes.

Shared responsibility at a glance

Read the table bottom-up and one thing stands out: your code, your data, and your access control are always yours. The cloud never takes responsibility for a badly written app or an over-permissioned account — a point exam questions love.

Memory hook — the compute spectrum, most control → most managed: Most Sysadmins Keep Infrastructure; Cloud Architects Favor Functions. Machines (VMs) → Scale Sets → Kubernetes (AKS) → Instances (ACI) → Container Apps → App Service → Functions. The sentence even encodes the meaning: the left half is about keeping infrastructure control, the right half about handing work to the platform.

The Azure compute catalog in seven services

Here is the whole cast, each in a couple of sentences. Later episodes go deep on most of them.

Azure Virtual Machines (VMs) — full IaaS servers, Windows or Linux, with complete OS-level control. The default choice for lift-and-shift migrations, licensed software with special install requirements, and anything the other services can't host. You patch, you secure, you scale.

VM Scale Sets (VMSS) — a group of VMs managed as one resource, with autoscale rules that add or remove instances based on metrics or schedules. Same control as VMs, but built for elastic, load-balanced workloads.

App Service — managed web hosting for HTTP apps and APIs (.NET, Java, Node.js, Python, PHP, or a container image). You get deployment slots, custom domains, TLS, and autoscale without ever seeing the underlying servers.

Azure Container Instances (ACI) — the fastest way to run a single container (or a small container group) without any VM or orchestrator. Billed per second; ideal for burst, batch, and short-lived jobs. No built-in autoscaling or orchestration.

Azure Container Apps (ACA) — serverless containers for microservices, built on Kubernetes and KEDA under the hood — a Kubernetes you never manage. Gives you scale to zero, revisions with traffic splitting, and event-driven scaling, without exposing the Kubernetes API.

Azure Kubernetes Service (AKS) — managed Kubernetes: Azure runs the control plane, you control the cluster, node pools, and everything Kubernetes can do. Choose it when you genuinely need the Kubernetes API — custom operators, service meshes, fine-grained orchestration control.

Azure Functions — event-driven code: small units of logic triggered by HTTP calls, timers, queues, or storage events. On the Consumption plan you pay only while code runs. The natural home for glue logic and reactive automation.

Exercise 1.1 — First match: scenario to service

Match each scenario to the single best compute service. Commit to an answer before reading the solution.

1. A legacy Windows application requires a kernel-level driver from a third-party vendor to be installed on the server.
2. A team ships a .NET web API, wants CI/CD from GitHub, a custom domain, and zero server management.
3. A containerized report generator runs once per night for about 30 minutes, then should disappear (and stop billing).
4. Thumbnails must be generated whenever an image lands in a storage account.

Solution:

1. Virtual Machine. A kernel-level driver means OS-level access, and only IaaS gives you that. Every PaaS/serverless option abstracts the OS away — this requirement disqualifies them immediately.
2. App Service. It's a web API (HTTP workload), the team wants productivity over control, and App Service natively provides GitHub deployment, custom domains, and TLS. A VM would work but adds patching for no benefit.
3. Azure Container Instances. Containerized, short-lived, no orchestration needed, per-second billing that stops when the container stops. ACA would also run it, but ACI is the simpler, cheaper fit for a solo batch job.
4. Azure Functions. A textbook event-driven trigger (blob created → run code). Consumption-plan Functions cost nothing while idle and scale automatically with the event volume.

How to choose: four decision criteria

Four questions resolve most compute decisions:

1. Control vs productivity. Do you need OS access, custom agents, or special drivers? If yes, you're on the IaaS side (VM/VMSS). If not, every step toward PaaS/serverless deletes operational work — patching, hardening, capacity planning.
2. Lift-and-shift vs cloud-native. Migrating an existing server mostly as-is? VMs minimize change. Building new? Start from the managed end of the spectrum and move left only when a requirement forces you to.
3. Containerized? If the workload ships as a container image, your shortlist is ACI, Container Apps, AKS (and App Service, which can also run containers). The tiebreaker: do you need the Kubernetes API (→ AKS), a microservices platform with scale to zero (→ ACA), or just one container, now (→ ACI)?
4. Event-driven? If the workload is "run this code when X happens" rather than "keep this service running", Functions (code) or Container Apps (containers, via KEDA) are built exactly for that shape — and cost nothing between events.

A useful architect's habit: justify moving toward control, not toward productivity. "We chose App Service because we had no reason not to" is a perfectly good design rationale.

The decision tree

Treat the tree as a first-pass filter, not a verdict. Real designs add constraints — networking, compliance, team skills, cost — but if your instinct disagrees with the tree, you should be able to say why.

Exercise 1.2 — One company, three workloads

Contoso Retail is moving to Azure. Place each workload and justify your choice with the criteria above; also note one condition that would change your answer.

• (a) A 10-year-old ERP system, certified by its vendor only on Windows Server with a specific agent installed; migration must be low-risk and fast.
• (b) A new storefront built as ~12 containerized microservices; the team knows Docker well but has no Kubernetes experience; dev environments should cost nothing overnight.
• (c) The platform engineering team is standardizing on Kubernetes across clouds, with custom operators and a service mesh already in use elsewhere.

Solution:

• (a) Virtual Machine. Vendor certification tied to an OS plus a mandatory agent means full OS control — the tree exits at the first branch. Low-risk-and-fast confirms lift-and-shift. Answer would change if the vendor offered a containerized or SaaS edition — then re-run the tree.
• (b) Azure Container Apps. Containerized: yes. Kubernetes API needed: no (and no team skills for it — a real cost). Microservices with scale to zero for idle dev environments is precisely ACA's sweet spot: KEDA scaling, revisions, traffic splitting, none of the cluster operations. Answer would change if the team later needs custom operators or Kubernetes-level control — that's the signal to graduate to AKS.
• (c) Azure Kubernetes Service. The requirement is explicitly the Kubernetes API (operators, service mesh) and multi-cloud consistency. ACA hides the API, so it's disqualified despite being "less work". Answer would change if the mesh/operators turned out to be nice-to-haves — then ACA would remove a whole layer of cluster operations.

Foundations you'll reuse: regions, zones, and the resource hierarchy

Two concepts underpin everything in the next seven episodes.

Regions and availability zones. A region (e.g., westeurope) is a set of datacenters in one geographic area; you pick one for every resource you create. Within many regions, Azure exposes availability zones: at least three physically separate locations, each with independent power, cooling, and networking. Deploying copies of a workload across zones protects you from a whole-datacenter failure — spreading VMs across zones is what unlocks the highest VM SLA (99.99%). Episode 4 builds on this heavily.

The resource hierarchy. Everything you deploy is a resource (a VM, a disk, a NIC). Resources live in a resource group — a lifecycle container: things deployed, managed, and deleted together belong together. Resource groups live in a subscription, the billing and access boundary. Subscriptions can be organized under management groups for governance at scale (policy and access applied once, inherited by all subscriptions below).

You will create resource groups constantly, so here is the one command worth memorizing already:

az group create \
  --name myRG \
  --location westeurope

Note that a resource group itself has a location (it stores metadata there), but it can contain resources from any region. Rule of thumb: group by lifecycle, not by type — one application environment per resource group is a solid default.

Key takeaways

• All Azure compute sits on one axis: control (IaaS) ↔ productivity (serverless); moving right deletes operational work.
• Shared responsibility shifts along that axis — but your code, data, and access control are always yours.
• The seven services: VMs, VM Scale Sets, AKS, ACI, Container Apps, App Service, Functions — Most Sysadmins Keep Infrastructure; Cloud Architects Favor Functions.
• Four criteria decide most cases: control needed? lift-and-shift? containerized? event-driven?
• Justify moving toward control, not toward productivity — default to the most managed service that meets the requirements.
• Availability zones are physically separate datacenters within a region; spreading across them is the strongest in-region resilience play.
• Hierarchy: resource → resource group → subscription → management group; group resources by lifecycle.

Quick recall

Q: A workload needs a custom kernel module. Which part of the compute spectrum are you on, and what responsibility comes with it? A: IaaS (Virtual Machines) — you take on OS patching, hardening, and scaling configuration yourself.

Q: Containerized microservices, no Kubernetes expertise, dev environments should scale to zero. Which service? A: Azure Container Apps — serverless containers with KEDA-based scale to zero, no Kubernetes API to manage.

Q: When is AKS the right call instead of Container Apps? A: When you genuinely need direct Kubernetes API access — custom operators, service meshes, fine-grained orchestration control.

Q: ACI vs Container Apps in one line each? A: ACI runs a single container group for burst/batch work with per-second billing; Container Apps is a serverless microservices platform with autoscaling, revisions, and traffic splitting.

Q: Recite the resource hierarchy from smallest to largest. A: Resource → resource group → subscription → management group.

Q: What makes availability zones different from just "more servers in the same building"? A: Each zone is a physically separate location with independent power, cooling, and networking — a whole-datacenter failure takes out at most one zone.

Coming up

You can now pick the right service — next, we go deep on the one at the full-control end of the spectrum. In Episode 2 — Virtual Machines: Anatomy and Provisioning, you'll see what a VM deployment really creates behind the scenes, learn to decode size names like Standard_D4s_v5, and provision your first VM from the CLI — including the billing trap hiding in the difference between "stopped" and "deallocated".