Cloud Models (IaaS/PaaS/SaaS)

The overview made the point that the shared-responsibility line moves — that where “our problem” ends and “their problem” begins depends on what you rent. This page makes that idea precise. IaaS, PaaS, and SaaS aren’t three separate products; they’re three positions on a single ladder of abstraction. Climb a rung and you hand more of the stack to the provider. The only question that matters is: which rung is right for this workload?

The stack, and who manages what

Every running application sits on the same vertical stack, from the building at the bottom to your code at the top. The cloud model you choose is just where you draw the line between what you manage and what the provider manages.

                            On-prem   IaaS      PaaS      SaaS
   ────────────────────────────────────────────────────────────
   Your data / users         YOU       YOU       YOU       YOU
   Application code           YOU       YOU       YOU      ░prov░
   Runtime / language        YOU       YOU      ░prov░    ░prov░
   OS / patching              YOU       YOU      ░prov░    ░prov░
   Virtualization             YOU      ░prov░    ░prov░    ░prov░
   Servers / hardware         YOU      ░prov░    ░prov░    ░prov░
   Networking / data center  YOU      ░prov░    ░prov░    ░prov░
   ────────────────────────────────────────────────────────────
   YOU manage:                all     middle    little     ~none
   provider manages (░prov░): nothing  bottom    most     almost all

Read it top to bottom and the pattern is obvious: the line between YOU and prov slides upward as you climb the ladder. On-prem, you own everything down to the cooling. IaaS, the provider owns the hardware and virtualization but hands you a bare OS. PaaS, they own the OS and runtime — you just push code. SaaS, you own nothing but your data and how you use the product.

The three rungs, concretely

Model	You give the provider…	They give you back…	Canonical examples
IaaS	a request for raw resources	a virtual machine, disk, network — a bare OS you log into	EC2, Compute Engine, a DigitalOcean droplet
PaaS	your application code	a running app — no OS, no patching, no servers to see	Heroku, App Engine, Cloud Run, Vercel
SaaS	nothing but your usage	a finished product over a browser/API	Gmail, Stripe, Datadog, GitHub

IaaS — Infrastructure as a Service. You rent the raw primitives: compute, storage, networking. You get a machine and a root login, and from there it’s your Linux server — you patch it, you install the runtime, you run the app. This is maximum control and maximum work. A raw VM is just a Linux box you didn’t have to rack.

PaaS — Platform as a Service. You stop thinking about machines. You hand the platform a build of your code (or a git push) and it runs it: provisions servers, patches the OS, installs the runtime, wires up load balancing and TLS. You never SSH anywhere. The trade is that you live inside the platform’s assumptions — its supported languages, its scaling model, its way of doing things.

SaaS — Software as a Service. The whole application is the product. You don’t deploy Stripe; you call Stripe. There is no infrastructure for you to see at all — only configuration and your data. This is the top of the ladder: nearly all convenience, nearly no control.

Containers and Kubernetes are not a fourth rung

Where do containers and Kubernetes sit? Roughly between IaaS and PaaS. Raw Kubernetes-on-VMs is close to IaaS — you still own nodes, upgrades, and a lot of plumbing. A managed control plane (EKS/GKE/AKS) lifts the control-plane half toward PaaS, because the provider runs the masters. Serverless containers (Cloud Run, Fargate) push almost all the way to PaaS — you bring an image, they run it and scale it. Same ladder; the difference is just how much of the stack you kept.

The one trade-off behind all of it: control vs convenience

Every rung is the same bargain in a different proportion: you spend control to buy convenience.

   more control  ◄───────────────────────────────────►  more convenience
   more work                                              less work
   ──────────────────────────────────────────────────────────────────
   On-prem      IaaS         PaaS              SaaS
   (own metal)  (own OS+app) (own app only)    (own nothing but data)

Going up the ladder, you gain:

• Less operational toil — fewer servers to patch, scale, secure, and wake up for.
• Faster time to value — a PaaS can take you from git push to a live URL with TLS in minutes.

Going up the ladder, you lose:

• Control — you live inside the provider’s choices. If PaaS doesn’t support your runtime, your background-job model, or your network topology, you’re stuck.
• Visibility — when something is slow inside a managed layer, you can’t always see in to debug it.
• Portability — the higher you climb, the more provider-specific your dependencies, which is the lock-in cost in its purest form.

Choose the highest rung you can tolerate

The default instinct of experienced teams is to climb as high as the workload allows — buy the managed thing, push code instead of running servers — and only drop down a rung when a hard requirement forces it (a runtime PaaS won’t support, a compliance rule, a cost cliff at scale). Control is not a virtue in itself; it’s a cost you pay only when you actually need it.

It actually happened — Heroku ends its free tier (2022)

Heroku was the canonical PaaS — git push heroku main and your app was live, free, in minutes. For a decade its free dynos and free Postgres ran countless side projects, prototypes, and class assignments. Then in August 2022 its owner, Salesforce, announced Heroku would delete all free plans, effective 28 November 2022; free dynos, free Postgres, and free Redis simply stopped. Overnight, thousands of projects had to migrate or pay. Nothing was hacked and nothing broke technically — and that’s the point. The higher you climb the convenience ladder, the more the provider owns the terms, and “the provider changes the deal” is a control-and-portability cost you accept the moment you stop running your own servers.

The thread: what manual step each rung removes

The recurring question — what manual, error-prone step does this remove? — has a different answer at every rung, and they stack:

• IaaS removes racking, powering, and capacity-planning physical hardware. You still patch the OS.
• PaaS removes that and OS patching, runtime installation, load-balancer wiring, and TLS setup — the whole “stand up and maintain a server” chore. You just ship code.
• SaaS removes building and operating the capability at all. You don’t run a payments system or a metrics backend; you use one.

Production gets safer at each rung because the parts the provider runs are parts they run at scale, with expertise, and with their own on-call — an unpatched OS or a misconfigured load balancer is one fewer thing that can be your 2 a.m. page. The cost is the control and portability you traded away to get there, which is why the choice is per-workload, not a religion.

Now that you know which rung you’re standing on, the next page goes down to the bottom of the ladder and names the raw materials everything is built from: Core Primitives.

The architect’s lens

Five questions for choosing a rung on the ladder:

• Why does it exist? Because the stack from hardware to your code has to be owned by someone — IaaS/PaaS/SaaS are three positions on one ladder marking where you draw the line between you and the provider.
• What problem does it solve? It frames every infrastructure call as one trade — spend control to buy convenience — so you can take the rung that removes the most toil a workload allows (PaaS removes OS patching and TLS wiring; SaaS removes building the capability at all).
• What are the trade-offs? Climbing buys less toil and faster time-to-value but costs control, visibility, and portability — the lock-in that bites when the provider changes the terms (Heroku killing its free tier in 2022).
• When should I drop down a rung? Only when a hard requirement forces it — an unsupported runtime, a compliance rule, a need for deep-debug visibility, or a cost cliff at scale.
• What breaks if I ignore the model? You mismatch rung to workload — over-controlling plumbing you should have bought, or buying convenience that boxes in a workload that actually needed control.

Check your understanding

1. IaaS, PaaS, and SaaS are described as “rungs on one ladder,” not three separate products. What is the single dimension that changes as you climb, and what slides as a result?
2. For each of IaaS, PaaS, and SaaS, name one thing you manage and one thing the provider manages.
3. Where do managed Kubernetes and serverless containers fall on the ladder, and why isn’t “containers” a fourth rung?
4. State the core trade-off behind the whole ladder in one sentence, then give one concrete thing you gain and one you lose by climbing a rung.
5. Using the book’s thread, explain why “choose the highest rung you can tolerate” is good default advice — and name a concrete reason you might deliberately drop down a rung.

Show answers

1. The dimension is how much of the vertical stack the provider manages (hardware → virtualization → OS → runtime → app). As you climb, the line between “you manage” and “provider manages” slides upward, so your operational toil falls and your control falls with it.
2. IaaS: you manage the OS/runtime/app; provider manages hardware and virtualization. PaaS: you manage your app code and data; provider manages OS, runtime, servers. SaaS: you manage only your data and configuration; provider manages essentially everything else, including the application itself.
3. Between IaaS and PaaS. Raw k8s-on-VMs is near IaaS (you own nodes/upgrades); a managed control plane (EKS/GKE/AKS) moves toward PaaS; serverless containers (Cloud Run/Fargate) push nearly to PaaS. It’s not a fourth rung because it’s just another position on the same ladder, defined by how much of the stack you kept versus handed over.
4. You spend control to buy convenience. Climbing a rung you gain less operational toil and faster time to value; you lose control, visibility, and portability (provider lock-in).
5. Because control is a cost, not a virtue — every rung you don’t climb is servers you must patch, scale, and be paged for, so taking the highest rung removes the most manual toil and hands those failure modes to the provider’s on-call. You drop down when a hard requirement forces it: an unsupported runtime, a compliance constraint, a need for deep visibility, or a cost cliff at scale.