Cloud Computing Models
debt(d7/e7/b7/t5)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints indicate automated detection is 'no'. Choosing the wrong cloud model (over-engineering with Lambda for always-on apps, under-engineering with EC2 for simple APIs) cannot be caught by any automated tool — it requires architectural review, cost analysis, and understanding of workload patterns. Only manual review or production cost/performance metrics reveal the mismatch.
Closest to 'cross-cutting refactor across the codebase' (e7). Migrating between cloud models (IaaS to PaaS, or vice versa) is not a one-line fix. The quick_fix describes choosing between EC2/Heroku/Lambda — but switching after initial deployment requires infrastructure rewrites, CI/CD pipeline changes, deployment script overhauls, and potentially code changes to accommodate platform constraints (e.g., ephemeral filesystems on PaaS). Common mistakes cite 'proprietary PaaS features make migration expensive.'
Closest to 'strong gravitational pull' (b7). The cloud computing model choice shapes deployment, scaling, monitoring, and operational workflows. Every infrastructure decision, CI/CD configuration, and capacity planning activity is influenced by this choice. It applies to both web and cli contexts per applies_to. While not quite b9 (you can migrate with effort), the gravitational pull is strong — you build your operational practices around the chosen model.
Closest to 'notable trap' (t5). The misconception explicitly states 'PaaS is always cheaper than IaaS' — a documented gotcha that experienced developers eventually learn but newcomers often believe. Common mistakes include treating PaaS like IaaS (ignoring constraints), assuming SaaS vendors handle all security (misunderstanding shared responsibility), and underestimating IaaS operational overhead. These are learnable traps, not catastrophic ones where the obvious approach is always wrong.
Also Known As
TL;DR
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
Why It Matters
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
# 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# 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
https://aws.amazon.com/types-of-cloud-computing/