Cloud Computing Models
Also Known As
IaaS
PaaS
SaaS
FaaS
shared responsibility model
TL;DR
IaaS (infrastructure), PaaS (platform), SaaS (software), and FaaS (functions) — each level of abstraction trades control for convenience.
Explanation
IaaS (EC2, GCE): raw VMs — you manage OS, runtime, and app. PaaS (Heroku, App Engine, Render): you deploy code, provider manages OS and runtime. SaaS (Gmail, Salesforce): fully managed application. FaaS (Lambda): function-level deployment, fully managed. The shared responsibility model defines what the cloud provider secures vs what you secure. As you move up the stack, you give up control but gain operational simplicity. PHP developers typically work at PaaS or IaaS level.
Diagram
flowchart TD
subgraph You manage
IAAS_YOU[OS, Runtime,<br/>App, Data]
PAAS_YOU[App, Data]
SAAS_YOU[Nothing]
end
subgraph Provider manages
IAAS_P[Physical infra<br/>Hypervisor]
PAAS_P[Physical + OS<br/>+ Runtime]
SAAS_P[Everything]
end
IAAS[IaaS<br/>eg. EC2] --- IAAS_YOU & IAAS_P
PAAS[PaaS<br/>eg. Heroku] --- PAAS_YOU & PAAS_P
SAAS[SaaS<br/>eg. Gmail] --- SAAS_YOU & SAAS_P
FAAS[FaaS / Serverless<br/>eg. Lambda] -.->|you write functions only| PAAS
style IAAS fill:#1f6feb,color:#fff
style PAAS fill:#238636,color:#fff
style SAAS fill:#6e40c9,color:#fff
style FAAS fill:#d29922,color:#fff
Common Misconception
✗ PaaS is always cheaper than IaaS — PaaS convenience has a cost premium; at scale, IaaS often costs less for the same workload.
Why It Matters
Choosing the wrong abstraction level creates either over-engineering (managing VMs for a simple app) or under-control (PaaS constraints blocking needed configuration).
Common Mistakes
- Treating PaaS like IaaS — PaaS platforms have constraints (ephemeral filesystems, managed runtimes) that IaaS does not.
- Assuming SaaS vendors handle all security — the shared responsibility model means you are still responsible for data and access management.
- Not considering vendor lock-in at the PaaS layer — proprietary PaaS features make migration expensive.
- Underestimating the operational overhead of IaaS — 'just spin up a VM' requires patching, monitoring, backups, and security hardening.
Code Examples
✗ Vulnerable
# IaaS with no management — missing the operational burden:
terraform apply # EC2 instance created
# Who patches it? Who monitors it? Who backs it up?
# Who responds when the disk fills? When the process crashes?
# IaaS requires answering all of these — PaaS handles them
✓ Fixed
# Right tool for the job:
# Simple web app → PaaS (Heroku, Render, Railway) — no ops overhead
# Need custom OS config → IaaS (EC2, GCE) — full control
# Event processing → FaaS (Lambda, Bref) — pay per use
# Email service → SaaS (SendGrid, Postmark) — not your core competency
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
29
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
Amazonbot 9
Perplexity 7
Google 3
Unknown AI 2
Ahrefs 2
SEMrush 1
Also referenced
How they use it
crawler 23
crawler_json 1
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Low
⚡ Quick Fix
Choose: IaaS (you manage OS, app — EC2) for maximum control; PaaS (you manage app — Heroku, App Runner) for faster shipping; FaaS (you manage function — Lambda/Bref) for per-request billing
📦 Applies To
any
web
cli
🔗 Prerequisites
🔍 Detection Hints
Over-engineering: Lambda for always-on PHP app; under-engineering: EC2 for simple API that PaaS would serve cheaper
Auto-detectable:
✗ No
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: High
Context: File