Before you can design anything in the cloud, you need a precise mental model of what the provider gives you and what you must build yourself. The three classic service models, IaaS, PaaS, and SaaS, are not marketing labels; they are boundaries that determine your operational workload, your security obligations, and your flexibility.
Infrastructure as a Service
IaaS hands you virtual machines, block storage, and networks. You control the operating system, patching, middleware, and everything above it. Architects choose IaaS when workloads need custom runtimes, specific kernel settings, or lift-and-shift migrations where rewriting the application is not yet an option. The cost is operational: you own more maintenance.
Platform as a Service
PaaS abstracts the operating system away. You deploy code or containers, and the platform handles patching, scaling hooks, and runtime management. Managed databases, app services, and serverless functions all sit in this band. The tradeoff is reduced control: you accept the platform’s supported runtimes and limits in exchange for far less undifferentiated maintenance work.
Choosing a Default Posture
Experienced architects set a default: prefer the highest abstraction that still meets requirements, then step down only when a constraint forces it. This keeps teams small, reduces patching surface, and concentrates engineering effort on the product rather than on plumbing that every competitor also has to run.
Action Step
List three workloads you know well, real or hypothetical. For each, write one sentence choosing IaaS, PaaS, or SaaS and the single constraint that drove your choice. Keep this list; later modules will test your reasoning against availability and cost concerns.
This lesson is educational content, not professional advice. Results depend on your own situation and effort; no outcome is guaranteed.