The spectrum, from owning a car to hailing one
There is a spectrum to getting somewhere by car. You can own one — total freedom, and every oil change, tyre and insurance renewal is yours. You can run a fleet with a manager who adds cars at rush hour. You can use a car service that keeps the vehicles and simply sends one when you ask. Or you can hail a ride only for the minutes you are actually moving, and pay nothing the rest of the day. Same trips, wildly different amounts of the work you keep. Azure's compute options are exactly this spectrum, and Class Four already told you its shape: as you climb from IaaS toward serverless, the line of accountability rises and the chores fall away.
Four rungs cover almost everything, and this class devotes a part to each. A virtual machine is the owned car: you get the whole operating system and every chore that comes with it. A virtual machine scale set is the managed fleet: many identical VMs that grow and shrink together. App Service is the car service: you hand over code and the platform runs the machines beneath it — and when a plan on shared hardware is not private enough, an App Service Environment gives you the service on hardware that is yours alone. Functions, met properly in Class Forty-One, is the ride you hail: small pieces of code that run on an event and cost nothing when idle.
- Serverless
- Compute where you never see or manage the server — you supply code, the platform runs it on demand, and billing follows execution, not uptime. There are still servers; you have simply stopped being the one who owns them.
The engineering skill is not knowing that these exist. It is placing each workload on the rung that matches how much control it truly needs against how many chores you can afford to carry — and resisting the pull, which this class ends on, to choose the fashionable rung instead of the fitting one.
Choose by appetite for chores, not fashion.
The track — six parts, App Service to bare metal
The rest of Class Eleven is six pages, each a full class in its own right with its own drills and its own lab notes. The first three walk the platform-managed end of the spectrum — the one you should reach for first — and the next two descend into virtual machines for the workloads that genuinely need them. The last part is the decision itself: how to choose between all of it, and the services in neighbouring classes, without being talked into the expensive answer.
- 11a · App Service Plans
- The plan is the machinery and the bill; apps ride on top. Tiers from Free to Isolated, scaling up versus scaling out, and the cost model — including the trap of a second plan you did not need.
- 11b · App Service
- Web apps and APIs with no operating system to patch: deployment slots and the swap, custom domains and free managed TLS, and the app settings and connection strings that carry your configuration and secrets.
- 11c · App Service Environment
- When shared hardware will not do: a single-tenant deployment of App Service into your own virtual network. What ASE v3 buys, what its Isolated v2 plans cost, and the cheaper answer that usually wins.
- 11d · Virtual Machines
- The owned car in full: series and sizing, images, availability sets versus zones, managed disks that outlive the machine, and extensions — the whole IaaS chore list, and how to carry it deliberately.
- 11e · VM Scale Sets
- Elasticity in raw compute: autoscale on a metric or a schedule, the Flexible and Uniform orchestration modes, and rolling upgrades that replace instances without dropping the fleet to zero.
- 11f · The Compute Decision Framework
- The whole spectrum as one decision: App Service versus Container Apps versus AKS versus Functions versus VMs, and the honest questions that place a workload on the lowest-chore rung it can tolerate.
The one table the whole class is built to fill in
Before the parts teach each rung in detail, hold the shape whole. Put the spectrum in one table and the decision stops being about which technology is most impressive and starts being about how many chores each workload justifies.
| Option | You still manage | Azure manages | Scales by |
|---|---|---|---|
| Virtual machine | OS, patching, runtime, app | Hardware, virtualisation | You resize it |
| Scale set (VMSS) | OS image, patching, app | Hardware, instance orchestration | Metric or schedule |
| App Service | App code, config, scale rules | OS, runtime, load balancing, patching | Autoscale (Standard+) |
| Functions | The function code | Everything else | Automatically, to zero |
Read the table top to bottom and the "you still manage" column empties out while the "Azure manages" column fills — that is the whole spectrum in two columns. The right choice is the lowest-chore option a workload can actually tolerate: Functions if the work is short and event-driven, App Service if it is a web app, a scale set if you need real VMs that flex, a plain VM only when something genuinely demands full control.1 Choosing a heavier rung than the workload needs is paying in chores for control you will never use — the compute version of the all-IaaS instinct you costed in Class Four. Part 11f turns this table into a repeatable decision you can defend in a design review.
Where Campux lands, and why
The running client gives the spectrum somewhere to bite. Campux Retail — forty stores, one storefront, a November peak and a January trough — has two workloads that want two different rungs, and the mistake most beginners make is putting both on whichever rung they learned first.
Two workloads, two rungs, each chosen by appetite
The storefront lands on App Service, Standard tier, in the app subnet you surveyed last class. Standard gives it autoscale for the November surge — instances added as load climbs, removed as it falls, the Class Two arithmetic realised — and deployment slots so the six-person team ships new versions with a warm-up and a swap rather than a midnight maintenance window. No operating system to patch, no load balancer to wire; the platform carries all of it. Part 11a sizes its plan and 11b wires its slots, domain and settings.
The POS batch job — the nocturnal reconciliation you refused to migrate hastily in Class Three, now bound for IaaS as Class Four decided — gets a right-sized VM, chosen against what the job actually uses rather than "to be safe," with an auto-shutdown schedule so it is not billed around the clock for three hours of nightly work. Part 11d builds it, and names the catch you will meet in the exam: auto-shutdown stops the machine, but Azure has no built-in auto-start.
Two workloads, two rungs, each chosen by appetite. The parts ahead give each one its hands-on build; this hub is where you learn to make the call.
Does this even need to be a VM?
Finance points at a row of always-on virtual machines. You ask the question the class taught: does this even need to be a VM? Some of it becomes App Service, some scales to zero after hours, and the one box that must stay gets right-sized to its actual graph. You match compute to the workload instead of to a habit, and the line item drops without anything getting slower.
Examination
Four drills, then two situations. These test the judgement the whole track is built on; the hands are built in the six parts. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
C. Short, event-driven, idle-most-of-the-time work is the exact shape Functions on consumption was built for — it scales to zero, so an idle hour costs nothing. A, B and D all keep something running (and billing) around the clock for a job that needs a second or two now and then, which is paying continuously for occasional work. Match the billing model to the workload's rhythm: bursty and rare wants pay-per-execution, not pay-per-hour.
C. A managed web app with no OS chores points to App Service, and the two named requirements — a seasonal surge and downtime-free updates — mean autoscale and deployment slots, both of which begin at Standard. B is the trap: Basic is App Service too, but it scales only by hand and has no slots, so it fails both requirements to save a little money. A brings back the OS chores you were told to avoid; D suits event-driven code, not a continuously served website. The tier is part of the answer, not a detail — Part 11a is where you meet that gate head-on.
OS patching, load balancing, and the underlying VMs and runtime. Those are the chores the PaaS bargain takes off your plate. The two you keep are the two that were always yours: your application code, and the scaling rules — App Service runs the autoscale machinery, but you decide when it should add an instance and when it should stop. Confusing "Azure runs autoscale" with "Azure decides my thresholds" is how a storefront either fails to scale for November or scales into a surprise bill.
COMPUTE PLAN — Campux
1. Storefront -> App Service, Standard, autoscale for November.
2. POS nightly reconciliation (~3 hours) -> Azure Functions, consumption.
3. Internal admin tool -> App Service, its own Standard plan.
4. Shared dev VM -> auto-shutdown schedule at 19:00.
Line two. A three-hour job does not belong on a consumption-plan Function, which is built for short bursts and times out at five minutes by default and ten minutes at the absolute most — the job would be killed long before it finished. Functions scaling to zero is seductive for a nightly task, but "nightly" here means "runs for hours once a day," which is a VM or a container job, not a serverless function. Lines one, three and four are sound.
Consider the consequence. Shipped as written, the reconciliation appears to deploy fine, then silently times out every night; the books never reconcile, and nobody notices until a month-end total is wrong and the logs show a function terminating at the timeout. Matching a workload's duration to the service's limits — not just its rhythm — is the check this drill trains.
Separate the two questions the invoice is blurring. Right-sizing is about the machine being the correct size; this bill is about it being on when no work is happening. The VM can be perfectly sized and still cost four times too much because it runs 24 hours for 3 hours of work. Your manager is right that it was sized, and that is not the problem in front of them.
Diagnose: the machine has no shutdown schedule. A nocturnal job that runs three hours needs the VM up for those three hours, not the other twenty-one. This is the "pay-for-what-you-forget" leak from Class One, wearing a compute costume — capacity left running out of habit.
The fix, with its catch. Add an auto-shutdown schedule so the VM stops after the nightly window. But name the catch before it bites: Azure's auto-shutdown does not auto-start, so you also need a scheduler — Azure Automation or a Logic App — to start the VM before the job and let auto-shutdown stop it after. Shutdown alone would fix the bill and break the job; the pair fixes both. That is the difference between "we turned it off" and "we ran it only when needed."
This is fashion arguing with fit. Kubernetes is genuinely excellent for a certain scale and shape of problem, and it is also a large standing set of chores — cluster upgrades, node pools, networking, the people who understand all of it on call. "Industry standard" describes what large engineering orgs run; it does not describe what a six-person team serving one storefront should carry.
Answer in chores and people, not status. App Service already gives the storefront autoscale, slots and TLS with almost no operational burden. Moving to AKS would add an entire platform for the team to run, in exchange for flexibility this workload does not need. The right question is never "what do serious engineers use" but "what does this workload need, and what will running it cost us in attention?"
Concede where the argument has a future. If Campux's needs grow — many services, complex orchestration — containers become worth revisiting, and Class Twenty-Seven prices exactly that decision honestly, including the people-cost. Part 11f of this class lays the same choice out as a framework. Today, choosing App Service is not choosing "beginner"; it is choosing the fewest chores that do the job, which is the most senior instinct there is.
Five things worth carrying out of this hub
- Compute is a spectrum from VM to Functions: as you climb it, control falls and chores fall with it. Pick the lowest-chore rung that fits.
- The platform end comes first — App Service and its plan, then ASE when hardware must be private — because it is where most web workloads belong.
- Virtual machines and scale sets are the owned car and the managed fleet: full control, and the full chore list that comes with it.
- The whole class is built to fill in Table 1: what you manage, what Azure manages, and how each rung scales.
- Choose by appetite for chores, not fashion. Part 11f makes that a decision you can defend, not a mood.
- Serverless has its own edges worth knowing before you lean on it: consumption-plan Functions have a cold-start delay after idle and a capped execution time, which is why long or latency-critical work moves to a Premium or Flex plan, or off Functions entirely. "Scales to zero" is a genuine saving and a genuine constraint at once. Class Forty-One is where Functions gets its own full treatment; this class places it on the spectrum and no more. ↩