DEV Community

Sri Balaji
Sri Balaji

Posted on • Originally published at thesimplifiedtech.com

IaaS vs PaaS vs SaaS, What You Actually Manage

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.

Note: 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?

In the real world In tech
🏠 Make it from scratch at home On-premises
πŸ›’ Buy a frozen pizza, bake it IaaS
πŸ›΅ Order delivery, eat at home PaaS
🍽️ Eat at the restaurant SaaS

Same dinner, four levels of how much work is yours.

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

As you move right, responsibility (and effort) shifts from you to the provider.

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.

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:

iaas-the-work.sh

# 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...
Enter fullscreen mode Exit fullscreen mode

The same app on a PaaS is usually a config file and a push, servers, scaling, TLS, and patching are the platform's problem:

paas-the-config.yaml

# 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: 10
Enter fullscreen mode Exit fullscreen mode

Where 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.


Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.

Top comments (0)