One question, asked the same way every time
Five parts gave you the rungs; this one gives you the ladder as a decision. The mistake the framework exists to prevent is choosing compute by fashion — reaching for Kubernetes because it is prestigious, or a VM because it is familiar — instead of by fit. The single question that replaces all of that is the hub's thesis made operational: what is the lowest-chore rung this workload can actually tolerate? Not the most powerful, not the most impressive, not the one you know best — the lowest one that still meets the workload's real requirements.
Answered honestly, that question sorts almost every workload, because the requirements that force a heavier rung are specific and nameable: a duration, an OS dependency, a scale number, a compliance rule. When none of those is present, the lighter rung wins, and "but everyone uses X" is not a requirement. The rest of this part is that question turned into an order of asking — a flow you run top to bottom, taking the first rung whose conditions the workload meets, so two engineers reasoning from the same facts reach the same defensible answer.
The order of asking
Run the questions from lightest rung to heaviest and stop at the first "yes," because taking a lighter rung when it fits is always the cheaper, lower-chore choice. Is the work short and event-driven? — a job triggered by a message, a file, a timer, running for seconds and idle most of the time — then Functions, which scales to zero and bills per execution (Class Forty-One). Is it a standard web app or API with no unusual OS needs? — then App Service, the default from Parts A and B. Is it containerised and needing elastic, possibly scale-to-zero container hosting without a cluster to run? — then Azure Container Apps.
Only past those do the heavy rungs appear. Do you need full Kubernetes orchestration — many services, complex networking, a platform team to run it? — then AKS (Class Twenty-Seven), whose people-cost that class prices honestly. Do you need full control of the operating system — a licensed app that must see a real OS, a legacy dependency, a lift-and-shift not yet refactored? — then a VM, or a scale set if it must also flex (Parts D and E). The order is the whole discipline: you arrive at a VM or AKS only after every lighter rung has failed a real requirement, never before.1
Take the first rung that fits, not the heaviest that works.
The spectrum on one line
Held as a table, the five rungs and their forcing conditions become a reference you can carry into any design review. The left column is the rung; the middle is the single question that selects it; the right is the chore you are signing up for by choosing it. Reading down, the chores grow — which is the cost you pay for control — so the table also reads as a warning: every step down is more of your attention spent forever.
| Rung | Choose it when | What you sign up to own |
|---|---|---|
| Functions | Work is short, event-driven, idle-heavy | Only the function code; watch timeouts |
| App Service | Standard web app or API, no unusual OS need | Code, config, scale rules |
| Container Apps | Containerised, wants elastic hosting, no cluster | Containers and their scaling; less than a cluster |
| AKS | Full Kubernetes: many services, a platform team | The whole cluster — the heaviest managed rung |
| VM / scale set | Full OS control, legacy, or licensed software | Everything above the hardware, across a fleet |
The table also exposes the two most common expensive mistakes, which are mirror images. Reaching too high — AKS or a VM for a standard web app — buys control the workload never uses and a chore list it did not need, the all-IaaS instinct from Class Four. Reaching too low — a Function for a three-hour job, App Service Basic for a surging site — saves a little and fails a real requirement, the trap the hub's own drills set. The framework's value is that it catches both: it stops you climbing past the fitting rung, and it stops you undershooting it.
Defending the call in the room
A framework is only worth having if it survives contact with a design review, where someone senior and sceptical asks "why not Kubernetes?" The answer the framework arms you with is never about status; it is about requirements and chores. "This is a single stateless web app with no unusual OS needs, so App Service meets every requirement it has, and moving to AKS would add a whole platform for the team to operate in exchange for flexibility this workload will never use." That sentence wins the room because it is reasoning from the workload, not from the résumé.
The same shape answers every version of the pressure. To "shouldn't this be serverless?" for a long-running job: "Functions has an execution timeout this job exceeds, so it belongs a rung heavier." To "why not just a VM, we know those?": "nothing here needs OS control, so the VM's chore list is pure overhead." Each defence names the specific requirement that decides it and prices the alternative in chores and attention. The Container Apps versus AKS versus App Service blog note on this site is a worked version of exactly this argument if you want to see it laid out.
Campux's whole estate, placed by the framework
Run the flow across everything Campux runs and the estate sorts itself. The storefront is a standard web app with a seasonal surge and no OS needs: App Service, Standard tier — first "yes" at row two. The nightly price import is short and event-driven, a few minutes on a timer: Functions — first "yes" at row one. The POS reconciliation runs three hours and was placed, in Class Four, on IaaS: a right-sized VM at the bottom of the flow, because a three-hour job fails the Functions timeout and nothing lighter fit. Three workloads, three different rungs, each chosen by a named requirement.
And the rung Campux did not take is the framework working just as hard. When a senior developer pushed for AKS "because it's the industry standard," the flow answered: the storefront never reaches row four, because it is a single web app, not many services needing orchestration, and it has no platform team to run a cluster. Class Twenty-Seven prices that AKS decision honestly for the day Campux genuinely grows into it; today the framework keeps a six-person team from operating a platform to run one storefront. That restraint — not the cleverness — is the senior instinct this whole class was built to teach.
What you carry out of Class Eleven
The track walked the whole spectrum — plans and App Service and the ASE at the managed end, VMs and scale sets at the controlled end — and this part tied them into one question you can ask about any workload for the rest of your career. That question is also the through-line of the bootcamp restated in compute's terms: the chores a provider will take off your hands are real, but the half they never take — your code, your config, the judgement of what runs where — is precisely the half you are paid to hold. Choosing the fitting rung is that judgement.
Carry three things forward. The spectrum is a ladder of chores, not a ranking of quality; the lowest rung a workload tolerates is the right one; and the reason to know all five rungs is so you can defend picking the light one when the room reaches for the heavy one. Class Twelve turns to storage — where the same discipline, lowest-chore-that-fits, decides how Campux keeps its data. You leave Class Eleven able to place any workload on the compute spectrum and say, in requirements and chores, exactly why.
The architecture review where "why not Kubernetes" comes up
You present an App Service design and the senior architect asks why it is not on AKS. You do not get defensive; you run the framework out loud. "It is a single stateless web app, no unusual OS needs, so App Service meets every requirement — AKS would add a platform to operate for flexibility this workload never uses." The panel nods, because you argued from the workload, not the trend. You did not win by knowing Kubernetes; you won by knowing when not to reach for it, which is the harder and more valued skill.
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.
C. The whole framework collapses to placing a workload on the lowest-chore rung it can tolerate — the fewest responsibilities that still meet its real requirements. A, B and D are the three fashions the framework exists to resist: most powerful, most prestigious, largest scale. Each of those picks a rung by an attribute the workload may not need, which is how a single web app ends up on Kubernetes and a nightly job ends up on an always-on VM. The discipline is fit, priced in chores — not power, status, or headline scale.
C. Container Apps runs containers on an elastic, serverless platform that can scale to zero, without you operating a cluster — exactly the stated shape. A scale set (A) would run containers but hand back the entire VM chore list you containerised to avoid. AKS (B) gives full Kubernetes and the cluster you explicitly said you do not want to operate. An ASE (D) is single-tenant App Service hardware, not a container-orchestration rung, and it does not scale to zero. When the workload is containers plus elasticity minus a cluster, Container Apps is the rung the flow lands on.
The OS-control requirement, the timeout-exceeding job, and the genuine Kubernetes-orchestration need. Each names a concrete condition a lighter rung fails, which is what legitimately forces the climb. The two rejects are the impostors the framework is built to reject: "looks good on résumés" and "feels more serious" are not requirements — they are fashion and status, and letting either drive a compute choice is precisely how workloads land on rungs whose chores they will pay for forever without benefit. A forcing requirement can be pointed at; a preference cannot.
COMPUTE PLACEMENTS — Campux
1. Storefront (web app, seasonal surge) -> App Service Standard.
2. Nightly price import (~4 min, timer) -> Functions, consumption.
3. Internal reporting site (dozens of users) -> AKS cluster.
4. POS reconciliation (~3 hrs nightly) -> right-sized VM.
Line three. A small internal reporting site for dozens of users is a standard web app — it lands at row two of the flow, App Service, and never reaches AKS, which is for many interdependent services needing orchestration and a team to run the cluster. Putting it on AKS buys an entire Kubernetes platform to operate for a workload that has none of the requirements that justify one: reaching too high, the all-IaaS instinct in Kubernetes clothing. Lines one, two and four are correct placements — surge web app to App Service, short timer job to Functions, and a three-hour job (which fails the Functions timeout) to a VM.
Consider the consequence. The reporting site runs fine on AKS — that is the trap — but the six-person team now operates a cluster, its upgrades, its node pools and its on-call, all to serve an internal page a single App Service app would have hosted for a fraction of the attention. The cost is not an outage; it is a permanent tax on the team's time, justified by nothing the workload actually needed. Catching "this doesn't need that rung" is the entire job the framework trains.
Concede the legitimate half first. Consistency is a genuine engineering value — one platform to learn, one way to deploy, fewer moving parts of a different kind. And Kubernetes really is how many large orgs run at scale. Open by granting that, so the disagreement is about fit and cost, not about who is more serious. An answer that starts by respecting the point earns the right to complicate it.
Then price the consistency being proposed. "Everything on Kubernetes for consistency" means running a cluster — upgrades, node pools, networking, on-call expertise — for workloads that individually need none of it. For a single stateless web app, that is a large standing chore bought to match a pattern, not to meet a requirement. Consistency has a price, and here the price is a platform the team must operate forever to host something App Service would run with almost no attention.
Reframe consistency at the right layer. The consistency worth having is in how you deploy and observe — pipelines, IaC, monitoring — not in forcing every workload onto the heaviest runtime. Offer the calibrated position: App Service for this workload now, a shared deployment and observability standard across everything, and a genuine move to AKS if and when Campux grows into many services that need orchestration, which Class Twenty-Seven is ready to price. That holds your ground on fit while honouring the real value under the senior's objection.
Start from the fear, not the rule. The manager is not really asking for VMs; they are asking not to be burned again. Name that out loud and agree with it — reliability is the goal, and it is the right goal. The disagreement is only about whether "everything on VMs" is the way to get it, and treating the fear as legitimate is what makes the rest of the conversation land.
Show that "full control" moves the risk toward you, not away. A VM hands you the OS, patching, availability, disks, scheduling and monitoring — every one a chore, and every chore a new way to cause the next outage. Managed rungs like App Service take most of those off the team precisely so there is less to get wrong. A blanket VM rule does not buy safety; it buys the largest possible chore list on every workload, including the ones that were never going to fail. Control you do not need is not protection; it is surface area.
Offer the rule that actually reduces outages. Replace "everything on VMs" with "the lowest-chore rung each workload can tolerate, plus real standards for deployment, monitoring and rollback." That is what prevents the next incident — fewer chores to fumble, and disciplined operations across all of them. Keep VMs for the workloads whose requirements genuinely force them. The mature answer to a past outage is not more control everywhere; it is less to own and more rigour in owning it — which is the framework, restated as a safety policy.
Five things worth carrying out of Part F
- The whole decision is one question: the lowest-chore rung this workload can tolerate — not the most powerful, prestigious, or largest-scale.
- Ask in order, take the first yes: event-driven → Functions; standard web app → App Service; containers without a cluster → Container Apps; full Kubernetes → AKS; full OS control → VM or scale set.
- Only named requirements force a heavier rung — a duration, an OS dependency, a scale number, a compliance rule. "Looks serious" is not one.
- Both directions cost: reaching too high buys unused chores; reaching too low fails a real requirement. The framework catches both.
- Defend the call in requirements and chores, never status. Knowing when not to reach for the heavy rung is the senior skill.
- Real estates are messier than a clean top-to-bottom flow, and the framework is a first-pass sorter, not a verdict machine — a workload can sit near a boundary, and factors the flow does not ask about (an existing team's skills, a portability requirement, a migration deadline) legitimately tip a close call. Treat the order of questions as the default reasoning that gets you to the right rung in most cases, and expect to defend the handful of edge cases on their specific facts. The value is in preventing the gross errors — a web app on Kubernetes, a three-hour job on a Function — not in adjudicating every borderline choice by rote. ↩
- The rungs themselves keep shifting as Azure adds options — Container Apps, for instance, is a relatively recent rung that sits between App Service and AKS and did not exist for earlier cohorts, and more will appear. Hold the principle (lowest chore that fits) as the durable thing and treat the specific list of services as current-state that you should refresh periodically. A framework that survives new products is one built on the question, not on a fixed menu; the menu is expected to grow. ↩