On this page
The only question that matters: who manages what?
Every cloud service sits somewhere on one spectrum: how much of the stack do you operate, versus how much does the provider operate for you? At one end you manage almost everything (more control, more work). At the other, you manage almost nothing (less work, less control). IaaS, PaaS, and SaaS are just three points on that line.
Who this is for
Beginners deciding how to host an app, or anyone who's nodded along to these acronyms without being 100% sure of the difference.
The pizza analogy that makes it click
Think of it as 'pizza as a service': how much of dinner do you make yourself, and how much is done for you?
On-prem: you buy flour, own the oven, do everything. IaaS: the provider supplies the kitchen and oven (servers, storage, network), you still assemble and bake (OS, runtime, your app). PaaS: they cook it too; you just say what you want (deploy your code, they handle servers, scaling, patching). SaaS: you don't cook at all; you just use the finished product (Gmail, Slack, Notion).
Who manages each layer
Here's the same idea as the layers you're actually responsible for. ✅ = you manage it, ☁️ = the provider does.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Your application & data | ✅ you | ✅ you | ☁️ provider |
| Runtime & dependencies | ✅ you | ☁️ provider | ☁️ provider |
| Operating system & patching | ✅ you | ☁️ provider | ☁️ provider |
| Servers, storage, network | ☁️ provider | ☁️ provider | ☁️ provider |
| Example | EC2, a bare VM | App Runner, Heroku, Vercel | Gmail, Slack |
When to choose each
Choose IaaS when…
You need full control, custom OS tuning, specific networking, legacy software, or you're running something the managed platforms don't support. The cost is that you now own patching, scaling, and uptime. Great power, great pager duty.
Choose PaaS when…
You want to ship product, not babysit servers. You push code; the platform builds, runs, scales, and patches it. Perfect for most web apps, APIs, and startups. The trade-off: you live within the platform's supported runtimes and limits.
Choose SaaS when…
The problem is already solved by someone else. Don't build an email server, a CRM, or a payroll system, buy the SaaS. Build only what's actually your differentiator.
Pro tip
Default to the highest level that fits. Most teams over-choose IaaS, then drown in ops work that a PaaS would have handled. Reach for IaaS only when you have a concrete reason PaaS can't meet.
The same app, two ways
Deploying a Node app on IaaS means provisioning and maintaining a server yourself:
# You rent a bare VM... then YOU do all of this, forever:
ssh ubuntu@your-server
sudo apt update && sudo apt upgrade -y # patching = your job
sudo apt install -y nodejs nginx # runtime = your job
# configure nginx, TLS certs, a process manager,
# log rotation, firewall, auto-restart, scaling...The same app on a PaaS is usually a config file and a push, servers, scaling, TLS, and patching are the platform's problem:
# Describe what you want; the platform runs it.
service: my-api
runtime: nodejs20
build: npm ci && npm run build
start: npm start
instances:
min: 2 # platform handles scaling + restarts
max: 10Where to go next
The whole article in 4 lines
- It's one spectrum: **how much you manage vs how much the provider manages.**
- **IaaS** = you get raw infrastructure and run everything on top (max control, max work).
- **PaaS** = push code, the platform runs it (ship fast, less control).
- **SaaS** = use a finished product. Default to the highest level that fits your need.
- Related lesson: Compute Models, the IaaS building blocks.
- Next read: Compute Models: VMs vs Containers vs Serverless.
- See it in context in the Cloud Engineer path.
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.