The line was always going to move
There are three ways to have bread. You can grow the wheat, mill it, and bake — owning every step and every failure. You can buy the dough and bake it yourself, letting someone else handle the parts that are tedious and easy to get wrong. Or you can buy the loaf. All three end in bread; they differ only in how much of the work you kept, and the right choice depends entirely on whether you are a farmer, a household, or simply hungry.
Cloud service models are the same decision applied to the stack you met in Class One. Back then you were shown seven layers and a red line of accountability, and told plainly that the line would move — that you would draw it three more times in this class. Here they are. IaaS, PaaS and SaaS are not three products. They are one stack with the line drawn at three different heights.1
The higher the line sits, the more the provider carries and the less you touch. What never changes — and this is the callback worth tattooing on — is the top of the stack. In every model, your data and your identities stay above the line. You can rent the baking; you cannot rent being the one accountable for what comes out.
IaaS — maximum control, maximum chores
- IaaS
- Infrastructure as a Service. You rent virtual machines, disks and networks; the provider runs the hardware and virtualisation, and everything above — operating system, patches, runtime, application — is yours.
IaaS is the closest thing to the server you used to buy, minus the loading dock. You choose the size, install the operating system, and from that moment you own its upkeep: the security patches on the second Tuesday of the month, the disk that fills silently, the runtime that needs upgrading, the backup that must be tested rather than merely configured. In exchange you get near-total control — any operating system, any software, any peculiar dependency a fifteen-year-old application insists upon.
That control is the reason to choose it and the price you pay for choosing it. Control is not a trophy; it is a to-do list. Every layer the provider hands back to you is a layer you are now on call for. IaaS earns its keep when a workload genuinely needs that latitude — a legacy application, a licence bound to a specific environment, software the managed platforms will not host — and quietly punishes you when it does not, by handing back chores you never actually wanted.
PaaS — the trade that usually wins
- PaaS
- Platform as a Service. You deploy your code and your data; the provider runs the operating system, the runtime, the patching and the scaling machinery beneath it.
PaaS raises the line one notch, and that single notch is where most modern workloads want to live. You bring the application and its configuration; the platform absorbs the operating system, the runtime, the patch cycle and the tedium of scaling. Azure App Service, Azure SQL Database and Azure Functions are all PaaS — you hand over code or queries, and the second-Tuesday patch is somebody else's calendar entry.
Control is a cost, not a prize.
The reason PaaS "usually wins" is that most teams do not actually want to administer an operating system; they want their software to run, scale, and stay patched without a human remembering to. PaaS trades a slice of control for a large reduction in chores, and for the majority of applications that is the trade that pays.3 It has limits — less freedom to install arbitrary software, occasional constraints on runtime versions — but for a storefront that needs to survive a November peak without a team babysitting virtual machines, those limits are a fair price. You will spend Phase Two putting Campux's storefront exactly here.
SaaS — buying the whole loaf
- SaaS
- Software as a Service. You use a finished application over the internet. The provider runs all of it; you bring only your data, your users and your configuration.
SaaS is buying the loaf. Microsoft 365, Salesforce, a payroll system reached through a browser — you do not deploy code or manage a runtime, you sign in and use software someone else builds, runs and patches. The line sits at its highest here, leaving you only the two layers that can never be delegated: your data, and the question of who is allowed to see it.
Which is precisely why the "we own nothing" objection misreads the model. You still own the two layers that matter most — and they are the two that breach. A misconfigured sharing setting, a departed employee whose access was never revoked, a mailbox rule quietly forwarding invoices to an outside address: none of those are the provider's to prevent. SaaS removes the chores of running software; it does not remove the responsibility for your data and your identities. That responsibility does not delegate, in any model, ever.
Choose per workload, not per company
The most common mistake at this point is to pick a model for the whole organisation — "we're a PaaS company," "we're going all-IaaS for control." A company is not one workload. The correct unit of decision is a single system, and a healthy estate almost always runs all three models at once.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical & network | Provider | Provider | Provider |
| Virtualisation | Provider | Provider | Provider |
| OS & patching | You | Provider | Provider |
| Runtime & middleware | You | Provider | Provider |
| Application | You | You | Provider |
| Configuration & settings | You | You | You |
| Data | You | You | You |
| Identity & access | You | You | You |
Read the bottom three rows across all three columns. They say You every time — your settings, your data, your identities.2 That is Figure 1 from Class One, restated as a table: the line moves, the top never does. Note the split the table makes that the figure cannot: in SaaS the provider runs the application, but how it is configured — who can share what, which rules forward where — never stops being yours.
One company, three models
You map Campux's systems to the models, one workload at a time. The e-commerce storefront goes to PaaS — Azure App Service — because it needs to scale for November without anyone administering an operating system, and it carries no exotic dependency that would forbid a managed platform. The POS batch job stays on IaaS, a self-managed virtual machine, for now — its licence is bound to a specific machine, exactly the case where IaaS control is not a luxury but a requirement, and the reason you refused to migrate it in Class Three. Staff email is already SaaS on Microsoft 365, and nobody sane proposes running a mail server to save money.
Three workloads, three models, one company — and the reasoning for each is a property of the workload, not a slogan about the company. When leadership asks "so which are we," the honest answer is "all three, on purpose." Hold this map; Phase Two builds every piece of it.
How much of the stack do you want to own?
"Should we run our own database server?" You draw the three tiers on the whiteboard and ask the only question that matters: how much of the stack do we want to be responsible for? The team does not need to patch an operating system to store orders, so PaaS wins — you trade away control you never wanted for a Saturday you get back. The acronym stops being trivia and becomes a decision.
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.
A. Owning the operating system and its patch cycle is the signature of IaaS — the provider stops at the virtualisation layer and hands you everything above. D is the trap for someone who half-remembers Class One: a self-patched VM is still on-demand, networked and metered, so it is very much cloud; it is simply the model where the most chores stay with you. If you can name who applies the patches, you can name the model.
C. A finished application used over the internet is SaaS. The sharp distinction is between C and D: SaaS lifts away the software chores, but the top two layers never move — Campux still owns the mailbox contents and the accounts that reach them. D is the belief that ends with a former employee's account still live three months after they left, or a forwarding rule nobody audited siphoning invoices out. "We own nothing" is how SaaS breaches happen.
App Service, Azure SQL Database, Azure Functions. In each you supply code or data and never touch the operating system beneath. The self-managed VM running SQL Server is IaaS — you own the OS and the patching — and it is the trap, because "SQL" appears in both it and Azure SQL Database while the models are opposite. Microsoft 365 is SaaS. The test is never the product's name; it is which layer you stop being responsible for.
SERVICE-MODEL ASSIGNMENT — Campux migration
1. Storefront on Azure App Service ............ PaaS
2. POS batch on a self-managed VM ............. IaaS
3. Staff email on Microsoft 365 .............. SaaS
4. Orders database on Azure SQL Database ..... IaaS
Line four. Azure SQL Database is a managed platform service — PaaS, not IaaS. You hand Microsoft the queries and the data; they run the operating system, the patching and the engine. IaaS would be SQL Server that you installed on a VM you patch, which is line two's situation, not line four's.
Consider the consequence. Labelled IaaS, that database gets a work item to "patch the OS monthly" that no one can ever action, an on-call expectation for a layer Microsoft already owns, and a security review that hunts for a server that does not exist. A wrong model label quietly manufactures phantom chores and phantom accountability. Getting the label right is what makes the responsibility map true.
Control is not free; it is paid in chores, and chores are paid in people. Do not argue that the director is wrong to want control — argue what all-IaaS actually costs. Every workload on IaaS means your six people now own operating-system patching, runtime upgrades, scaling configuration and backup testing for every system, forever. That is not control; it is a second job none of them applied for.
Cost it in their units. The storefront on PaaS survives November because the platform scales it; on IaaS, someone configures and tests that scaling by hand before the peak, and is awake during it. Put a number on the salary-hours all-IaaS adds, and set it against the zero features it produces. Control that buys nothing is just overhead wearing a confident word.
Offer the real principle: choose the lowest-chore model each workload can tolerate, and reserve IaaS for the workloads that genuinely need it — like the POS batch job, whose licence forces it. "Control where it pays, managed everywhere else" is the answer that respects the director's instinct without staffing a data centre to satisfy it.
The model follows the workload, not the company. Consistency across an estate is a comfort, not a virtue — the thing to be consistent about is the method, not the answer it produces. Applied honestly, one method routinely yields three different models under one roof.
Walk them through the two workloads. The storefront has a sharp peak, no exotic dependency, and every reason to avoid babysitting an operating system — so it takes the lowest-chore model that fits, PaaS. The POS batch job has a licence nailed to one physical machine; that single constraint forbids a managed platform and forces IaaS, chores and all. Same method, different facts, different result.
Give them the reusable rule: pick the model with the fewest chores each workload can actually tolerate, and let requirements — not tidiness — decide. Once they hold that, "isn't it inconsistent?" answers itself: it is consistent, in the only place that matters.
Five things worth carrying out of this class
- IaaS, PaaS and SaaS are one stack with the accountability line drawn at three heights — not three separate products.
- The line rises from IaaS to SaaS, but never above your data and identities. The top of the stack is yours in every model.
- IaaS is maximum control and maximum chores; PaaS trades a little control for far fewer chores, and usually wins.
- SaaS removes the software chores, never the responsibility for your data and who can reach it.
- Choose per workload, not per company. A healthy estate runs all three at once, each for a reason you can name.
- The three-model split is a teaching model, and the real world blurs its edges. Containers and serverless sit between IaaS and PaaS; "managed" versions of open-source databases keep shifting the line upward. Treat IaaS/PaaS/SaaS as three named points on a continuum, not three sealed boxes — the continuum is the truth, the three names are the handles. ↩
- Different vendors draw the responsibility boundaries slightly differently, and some charts split "application" or "identity" into shared rows. The exact cell shading varies; the load-bearing fact does not, and it is the one to defend in an interview: data and identity never leave the customer's side of the line. ↩
- "Usually wins" is a tendency, not a law. Plenty of sound architectures are mostly IaaS for good reasons — specialised software, licensing, regulatory isolation. The claim is only that for a typical web workload run by a small team, PaaS is the default that should have to be argued out of, not into. ↩