Abstraction stack: IaaS = lowest (most control) → SaaS = highest (least control). Sources: Cloud Lec 2, Cloud Lec 4.
| Dimension | IaaS | PaaS | SaaS |
|---|---|---|---|
| Abstraction level | Lowest (infrastructure) | Middle (platform) | Highest (application) |
| What you get | VMs, storage, networking, CPU | Runtime, dev tools, middleware | Ready-to-use applications |
| You manage | OS, apps, middleware, some networking | Deployed applications & config | Almost nothing (end user) |
| Provider manages | Physical infra, virtualization, hardware | OS, servers, storage, network | Everything including the app |
| Examples | Amazon EC2, Azure VMs, GCP Compute | Google App Engine, Azure PaaS | Gmail, Salesforce |
| When NOT suitable | — | Need portability, proprietary langs, custom HW tuning | Real-time apps; data cannot be hosted externally |
Function as a Service — serverless model where individual functions run in response to events. Higher abstraction than PaaS in practice; you manage only function code.
| Service | Example on exam |
|---|---|
| IaaS | Amazon EC2 |
| PaaS | Google App Engine |
| SaaS | Gmail, Salesforce |
Cloud delivery models sit at different abstraction levels: IaaS (lowest) provides VMs, storage, and networking — users control OS and apps (EC2). PaaS (middle) provides development platforms — users control apps only, not servers or OS (App Engine). SaaS (highest) delivers ready applications — users manage almost nothing (Gmail, Salesforce). IaaS suits infra control; PaaS suits rapid development; SaaS suits turnkey business apps. Trade-offs include flexibility vs convenience and portability concerns.