Cloud Fundamentals
Beginner 14 min read Cloud Fundamentals

Cloud Service Models

Who manages what, and the control-versus-velocity trade-off

IaaS, PaaS and SaaS are layers of the stack the provider manages for you. Lower layers give control; higher layers give velocity. Serverless and FaaS sit inside the PaaS family.

IaaSPaaSSaaSFaaSserverlessmanaged services
Prerequisites: What is Cloud Computing?
Before we start

What you will learn

  • Place IaaS, PaaS and SaaS on the stack-map of responsibility
  • Choose a service model from team capacity and compliance requirements
  • Map common cloud products (VMs, DBs, functions, SaaS apps) to their model
In 60 seconds

IaaS rents you raw infrastructure, PaaS rents you a managed platform for your code, SaaS rents you finished software. Each one moves a slice of responsibility from you to the provider.

Introduction

What is this?

Cloud service models describe how much of the stack the provider operates. With IaaS (Infrastructure as a Service) you manage the OS and everything above, provider handles hardware. With PaaS (Platform as a Service) the provider also manages the runtime — you bring code. With SaaS (Software as a Service) the provider manages everything, you bring users and data. The abstraction is a ladder: more provider responsibility, less customer control.

Motivation

Why do you need it?

  • Buying only the layer you need avoids paying to maintain things you don't want to operate.
  • PaaS and SaaS cut release cycles from weeks to hours because patching and scaling are managed.
  • Compliance sometimes forces you down to IaaS — some audited environments can't use shared runtimes.
  • Serverless (FaaS) is the PaaS endpoint: zero servers, pay per function invocation.
Think about it

Mental model

Imagine

Renting a kitchen, a restaurant slot, or a caterer

Think of

IaaS, PaaS, SaaS

IaaS rents you the kitchen and appliances (you cook, you maintain). PaaS rents you the whole restaurant including the chef's line but the menu is yours. SaaS is the caterer delivering finished meals from a fixed menu.

Mechanics

How it works

  • IaaS offers virtual machines, storage and networks via API; you're responsible for OS patches, hardening and app config.
  • PaaS (app services, managed databases, function platforms) handles runtimes, scaling and patches; you write code and deploy.
  • SaaS delivers complete applications (email, CRM, collaboration) you configure and consume, never operate.
  • FaaS (Function as a Service) runs your event-driven code in milliseconds-scale billing units with no provisioned server.
  • The same provider serves all layers; products blur boundaries (e.g., a managed DB is PaaS running atop IaaS).

The responsibility ladder across service models.

You manage hardware ↑
IaaS
PaaS
SaaS
Real world

In production

  • A regulated fintech runs payment cores on IaaS VMs (controlled OS and crypto), while its customer portal uses a PaaS app service and email uses SaaS.
  • A data team uses a managed warehouse (PaaS) and function-scale transforms (FaaS), never touching virtual machines.
  • A small business uses SaaS for office suites, PaaS for its storefront and IaaS for a legacy self-managed database.
Guidelines

Best practices

  • Stay as high up the abstraction ladder as compliance and team skills allow — less operations is fewer incidents.
  • Keep the escape hatch: run workloads in ways that can move between IaaS and PaaS if cost or control changes.
  • Document your responsibility boundary per system so on-call knows who patches the OS.
  • For PaaS, still own the resources not the provider: data, IAM, budgets, backups.
Watch out

Common mistakes

  • Choosing IaaS out of habit and running full server ops for features a PaaS gives for free.
  • Assuming SaaS means 'no responsibility' — access control and data protection are still on you.
  • Locking an app to a PaaS API so tightly that no migration is possible when the platform pricing changes.
  • Paying for SaaS seats nobody uses, the quiet cousin of idle VMs.
Root cause analysis

Common issues

Error
PaaS app restarts on its own
Root cause

Out-of-memory or a liveness probe the platform enforces

Fix

Raise the container/app memory setting and check logs for OOM-kill markers.

Error
SaaS integration returns 'scope missing'
Root cause

OAuth scope requested doesn't match what the integration needs

Fix

Check the app's consented scopes and re-consent with the full required scope set.

Error
IaaS VM shows high CPU from 'System'
Root cause

Host-level noise or antivirus/backup agent load, not your app

Fix

Compare across instances and correlate with scheduled agent jobs before blaming your code.

When things break

Debugging tips

  • Classify the failure layer first: is the error in your code, the platform runtime, or the underlying infrastructure?
  • Check service health status pages before debugging your own app against a broken platform.
  • For PaaS 'works on dev, broken on prod', diff the platform-level config (scaling, region, secrets).
  • Know the platform's max limits (concurrency, request size) — 'weird' PaaS failures are often limit errors.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

You deploy code to a platform that patches the runtime and scales automatically — which model is this?

2

With SaaS, the customer is still responsible for access control and data protection.

Go deeper

Official documentation

NIST SP 800-145 — service models
spec
AWS — Overview of Amazon Web Services
docs