A stack of responsibilities
Every computer system is built in layers. At the bottom are buildings, power and physical machines. Above them sit networking, storage and virtualization, then an operating system, then the runtime and tools that applications need, then the application itself, and finally the data that people put into it.
The three common cloud service models differ in where the provider’s work stops and yours starts. The further up the stack the provider goes, the less you manage, and also the less you can customize.
Infrastructure as a Service (IaaS)
With IaaS, the provider supplies the basic building blocks: virtual servers, storage and networking. You choose how large a server to rent and which operating system to install, then manage everything from there.
The provider typically manages: the physical facilities, hardware and the virtualization layer.
You typically manage: the operating system, security updates, installed software, configuration, the application and its data, and the settings that control who may connect.
Suits: teams that need control over the environment, want to move existing software with few changes, or run unusual configurations. It asks for real administration skill, since tasks like patch management fall to you.
Watch for: servers left running that nobody needs, and the effort of keeping systems consistent. Writing the setup down as code, as in infrastructure as code, helps with the second problem.
Platform as a Service (PaaS)
With PaaS, the provider also manages the operating system and the runtime environment. You supply your application code, and the platform takes care of running it, often including scaling and many routine updates.
The provider typically manages: everything in IaaS, plus the operating system, middleware and runtime.
You typically manage: your application, its configuration and its data, plus access controls.
Suits: development teams that want to ship features without administering servers. A platform often fits well with continuous delivery, since pushing new code is a smooth, repeatable step.
Watch for: the platform defines which languages, versions and features you can use. Features unique to one platform can make moving later harder, which is the heart of vendor lock-in.
Software as a Service (SaaS)
With SaaS, you use a finished application, usually through a web browser. Email, document editing, customer records and accounting tools are common examples of this kind of product. The provider runs the software and the infrastructure under it.
The provider typically manages: nearly the whole stack, including the application and its updates.
You typically manage: your data, your user accounts and permissions, and how the product is configured. Decisions about sign-in, such as single sign-on and multi-factor authentication, usually still belong to the customer organization.
Suits: needs that are common across many organizations, where building and maintaining your own software would be a poor use of time.
Watch for: limited customization, dependence on the provider’s roadmap, and the question of how you would get your data out. Contract terms and service level agreements matter more here, because you cannot fix the software yourself.
Comparing the three
| IaaS | PaaS | SaaS | |
|---|---|---|---|
| You get | Virtual servers, storage, network | A place to run your code | A finished application |
| You manage | OS and up | Application and data | Data, users, settings |
| Control | Highest | Medium | Lowest |
| Effort | Highest | Medium | Lowest |
| Typical user | System administrators | Developers | Everyday staff |
An analogy
Think of getting a meal. IaaS is like buying ingredients and a kitchen to use: you cook everything. PaaS is like a meal kit and a prepared kitchen: you assemble and finish the dish. SaaS is ordering the finished dish at a restaurant. The more you leave to someone else, the less you control the result, though the more time you save.
Where other terms fit
You may also see “serverless” and “containers” mentioned alongside these layers. They are not a fourth model so much as styles that sit between IaaS and PaaS in how much the customer manages. Serverless computing hides server management almost entirely, while software containers package applications so they run consistently in different places.
Responsibility never fully disappears
In all three models, the customer remains responsible for some things, such as deciding who gets access and what data is stored. The exact boundary shifts by model, which is the central point of shared responsibility. A common mistake is to assume that “managed” means “someone else handles security”. Read each provider’s documentation to see where the line falls.
How to choose
- Start with the need. If a ready-made product does the job, SaaS is usually the least work.
- Consider the skills you have. IaaS asks for people comfortable with operating systems and networks; PaaS asks for developers; SaaS asks mainly for good administration of accounts.
- Weigh control against effort. More control means more time spent maintaining.
- Think about leaving. The higher up the stack, the more specific the dependence tends to be.
- Compare total cost, not just the price list. Staff time is a cost too.
It is also normal to combine models. An organization might use SaaS for email, PaaS for a customer-facing website and IaaS for one legacy system that needs a particular setup. The goal is to choose the layer that fits each job rather than to standardize on one.