The spectrum, from owning to hailing
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. 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 Functions 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.
VM families and the cost of "to be safe"
When you do need a virtual machine, Azure offers families tuned for different balances of processor, memory and disk — the letters are a rough shorthand worth recognising. General purpose (B, D-series) for balanced everyday work; compute optimised (F) for processor-heavy jobs; memory optimised (E, M) for databases and caches; storage optimised (L) for high disk throughput; and specialised GPU families for graphics and machine learning. The B-series is worth a note of its own: it is burstable, banking credit while idle and spending it during short spikes, which fits a machine that is quiet most of the time and busy occasionally.
The trap here is the phrase that has cost more cloud money than any other: "size it large, to be safe." An oversized VM is safe in exactly one direction — it will not run short of capacity — and dangerous in the direction that shows up on the invoice, because you pay for every core and gigabyte whether the workload touches it or not. Class One warned you about the machine "sized to be safe"; this is where you meet it as a menu choice.
Size to the workload you measured, not the one you fear, and lean on the platform's ability to change your mind later — a VM can be resized, and a scale set adds instances precisely so no single machine has to be huge "just in case." "To be safe" is a forecast dressed as caution, and Class Two already taught you what forecasting capacity costs.
Scale sets and the November problem
Campux's whole shape is a seasonal spike — a November that needs everything and a January that needs almost nothing — and a single fixed VM answers that problem badly in both months. A virtual machine scale set answers it properly.
- VMSS
- A virtual machine scale set — a group of identical VMs managed as one, which adds and removes instances automatically according to a metric or a schedule.
This is Class Two's elasticity made concrete in compute. Instead of buying one machine large enough for the busiest hour of the year, you run a small number most of the time and let the scale set add instances when a metric — processor load, request queue length — crosses a threshold, then remove them when the peak passes. You can also scale on a schedule, which suits a spike you can see coming: more instances every day through the holiday season, fewer in the trough.
The payoff is exactly the arithmetic from Class Two: capacity follows demand in both directions, so November is served and January is not billed for capacity nobody is using. The discipline the class insisted on returns here too — autoscale is a set of rules you write and test before the peak, not a switch that ships flipped. A scale set with no rules, or rules never tested against a real surge, is just several fixed VMs waiting to disappoint you on the busiest day.
App Service: the PaaS bargain
For a web application, though, you rarely want to manage VMs at all — even a scale set of them. App Service is the PaaS bargain from Class Four applied to web apps: you deploy code, and Azure runs the operating system, the patching, the load balancing and the scaling underneath.
- App Service plan
- The set of virtual machines your web apps run on, chosen as a pricing tier. The plan decides the power, the features, and how far you can scale; the apps sit on top of it.
The tier is the decision that matters, because features switch on as you climb it. Free and Basic are for experiments and small sites — Basic can scale, but only by hand. Standard is the first serious production tier: it brings autoscale and deployment slots. Premium adds more power and private-network integration; Isolated runs your apps on dedicated, network-isolated hardware for the strictest needs.1 The line to remember: autoscale and slots begin at Standard, so a storefront that must survive November belongs at Standard or above, not on Basic to save a little.
Deployment slots are the quietly brilliant feature. A slot is a live staging copy of the app; you deploy the new version to it, warm it up, test it against production settings, then swap it into production in seconds — and swap back just as fast if it misbehaves. It is how a small team ships without a maintenance window, and the reason it starts at Standard is the reason Campux's storefront lands there.
What App Service takes off your plate is worth listing precisely, because it is what "PaaS bargain" actually means:
- Azure handles
- Operating-system patching, the runtime and framework, load-balancing across instances, the autoscale machinery, TLS/HTTPS termination, and health monitoring of the instances.
- You still handle
- Your application code and its configuration, the scaling rules and tier you choose, your custom domains and which secrets it reads — the half of the model that, as ever, never leaves you.
Choose by appetite, not fashion
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 |
Choose by appetite for chores, not fashion.
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.3 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.
And the fashionable rung is not always the fitting one. The pull toward running everything on a Kubernetes cluster because that is what serious engineers are seen to do is real, and it is answered honestly in Class Twenty-Seven by pricing what that cluster costs in people. For now, hold the discipline: the service that quietly does the job with the fewest chores beats the one that looks best in a conference talk.
Placing Campux's workloads on the spectrum
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.
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. One caution you will carry into the exam: auto-shutdown stops the machine on a schedule, but Azure has no built-in auto-start — bringing it back for the nightly run needs a scheduler such as Azure Automation, or the job simply never runs.2
Two workloads, two rungs, each chosen by appetite. Next class gives them somewhere to keep their data.
The official module, and a CAMPUX overview
Host a web application with Azure App Service
learn.microsoft.com/training/modules/host-a-web-app-with-azure-app-service/
The other end of the spectrum: Introduction to Azure virtual machines
learn.microsoft.com/training/modules/intro-to-azure-virtual-machines/
A short walkthrough of the compute spectrum, App Service tiers, and auto-shutdown will live here. Video to be added.
Put the storefront on App Service the CLI way
You will create an App Service plan and a web app on it — the storefront's home from this class — and meet the tier decision head-on: autoscale and deployment slots begin at Standard, not Basic.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)
Create a group and an App Service plan — the set of VMs your apps run on — then a web app on it:
az group create --name rg-campux-lab --location westeurope az appservice plan create --resource-group rg-campux-lab \ --name plan-campux --sku B1 --is-linux az webapp create --resource-group rg-campux-lab --plan plan-campux \ --name campuxweb$RANDOM --runtime "NODE:20-lts"
What just happened: the plan is the tier; the app rides on it. B1 (Basic) runs the app but cannot autoscale and has no deployment slots — that is the trap from the class, chosen here so you feel the limit.Browse the running site, then read its plan's tier:
az webapp show --resource-group rg-campux-lab \ --name <your-app-name> --query defaultHostName -o tsv az appservice plan show --resource-group rg-campux-lab \ --name plan-campux --query sku.name -o tsv
On screen: Azure patched the OS, provisioned the runtime, and put the app behind a load balancer — none of which you touched. That is the PaaS bargain in Class Four made concrete.Move the plan to Standard so autoscale and slots become available:
az appservice plan update --resource-group rg-campux-lab \ --name plan-campux --sku S1
The lesson: the storefront belongs at Standard or above precisely because November needs autoscale — the tier is part of the answer, not an afterthought. (Standard bills more than Basic; delete promptly after the lab.)Tear down:
az group delete --name rg-campux-lab --yes --no-wait
Create a web app by hand
Now build it by clicking — the Basics tab is where you choose the pricing tier, and that single choice decides whether the storefront can survive November. Use a throwaway resource group.
Go to portal.azure.com and sign in.
In the search bar at the top, type App Services, select it, then click + Create → Web App.On screen: a create flow whose Basics tab bundles the runtime, the operating system, the region, and — the decision that matters — the pricing plan.
Basics tab: subscription, a throwaway resource group, a unique app name, a runtime (e.g. Node), and a region.
Still on Basics, open the Pricing plan picker and read the tiers.On screen: Free and Basic are cheap but Basic scales only by hand and offers no slots; Standard is the first tier with autoscale and deployment slots. This picker is the class's §4 as a dropdown — choose Standard for anything that must survive a peak.
Review + create, then Create. Open the app and click its default URL to see it serving.
Tear down: delete the throwaway resource group.
Portal wording drifts; if a label here does not match your screen, the anchors are the App Services create flow and its Pricing plan picker.
Read control and chores on the blades
Open a web app and a VM and let their blades show you where each sits on the control-versus-chores spectrum.
On your web app, open Deployment slots, then Scale up (App Service plan), then Scale out (App Service plan).On screen: Scale up changes the tier (bigger machines, more features); Scale out adds instances and, at Standard+, lets you write autoscale rules. Slots is greyed out below Standard — the tier gate, visible.
If you have a VM, open its Auto-shutdown blade (under Operations).On screen: a daily stop time you can set in one toggle — the fix for the January bill. Note there is no matching auto-start; bringing it back needs a scheduler, the catch from the case file.
Read the web app's Overview and notice what is absent.The point: there is no OS to patch, no disk to manage, no load balancer to wire — the chores a VM would hand you are simply not on this blade. That absence is the PaaS bargain.
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. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
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.
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 carries a default execution timeout measured in minutes — 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. 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 class
- 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.
- VM families tune the balance of CPU, memory and disk — but "size it large to be safe" is a forecast that bills every day.
- Scale sets are Class Two's elasticity in compute: add instances for November on a metric or schedule, remove them for January.
- App Service is the PaaS bargain for web apps; autoscale and deployment slots begin at the Standard tier, not Basic.
- Choose by appetite for chores, not fashion. The fashionable service is often more operational burden than the workload earns.
- Tier names and their exact contents shift — Premium has moved through v2 and v3, Isolated through v1 and v2, and the precise feature and instance limits change with them. Hold the shape rather than the version string: Free and Basic for small or manual workloads, Standard as the first tier with autoscale and slots, Premium and Isolated for scale, network integration and dedicated hardware. Verify the current tier details before you quote a limit. ↩
- This asymmetry catches people: enabling auto-shutdown on a VM schedules a stop but never a start, because Azure ships the stop natively and leaves the start to a scheduler you configure — Azure Automation, a Logic App, or similar. A nocturnal batch job therefore needs a start trigger before its window and relies on auto-shutdown only to close it. Configure the stop and forget the start, and the job quietly stops running. ↩
- 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; the newer Flex Consumption plan is Microsoft's current recommendation for new serverless work and softens some of these edges. ↩