Service Models
By the end of this lesson
Distinguish infrastructure, platform and software services by responsibility.
The three-letter labels — IaaS, PaaS, SaaS — describe one thing: how much of the stack the provider operates. Nothing more. Once you read them that way they stop being jargon and become a straightforward question about how much work you want to keep.
The labels are also less crisp in practice than in diagrams. Plenty of real services sit between two of them, and arguing about which box a service belongs in is not useful. What is useful is knowing, for any service you are about to use, who patches it and who gets paged when it breaks.
The three models, with what each one leaves you:
- Infrastructure as a service (IaaS)
- You rent a machine, or a network, or a disk. The provider keeps the hardware and the virtualisation running. You install and patch the operating system, install your runtime, configure the web server, and arrange your own restarts. Azure Virtual Machines and Amazon EC2 are the examples.
- Platform as a service (PaaS)
- You hand over an application or a container image and the platform runs it. Operating system patching, the runtime, load balancing and restart-on-crash are the provider's. You lose direct access to the machine. Azure App Service and Azure Container Apps, or AWS Elastic Beanstalk and ECS on Fargate, sit here.
- Software as a service (SaaS)
- You use finished software over the network and configure it. No deployment, no runtime, no patching. Your email, your issue tracker and your identity provider are almost certainly SaaS. Your responsibility shrinks to your data, your users and your settings.
- Serverless
- A marketing word rather than a fourth model, usually meaning a platform service that scales to zero and bills per request. There are still servers. You do not manage them, and you do not pay for them while idle.
The same employees API, deployed two ways:
| On a virtual machine (IaaS) | On a managed platform (PaaS) | |
|---|---|---|
| Who installs the .NET runtime | You, and you upgrade it when a version reaches end of support | The platform, from the version you declare in configuration |
| Who applies OS security patches | You, on a schedule you define and have to actually follow | The provider, usually without you noticing |
| Restart after a crash | Whatever you configured — a service manager, a container runtime, or nothing | Built in, with a health check you configure |
| Adding capacity | Create more machines, put a load balancer in front, keep their configuration identical | Change an instance count or a scaling rule |
| Machine access for debugging | Full. You can attach a profiler and read any file | Limited. Logs, metrics and a restricted console at best |
| Cost at low traffic | You pay for the machine whether or not requests arrive | Often lower, and some platforms scale to zero |
| Suits | Software with unusual OS requirements, or a legacy application that expects a specific machine layout | Most new web services, including the employees API |
The honest default for a new service is the most managed option that can run it. Every layer you take back is a layer you have to keep patched, monitored and documented, and that work never appears in the original estimate.
The reason to move down a level is a specific, stated requirement: an operating system dependency the platform does not offer, a licence that must be installed on the host, a network arrangement the platform will not do, or a compliance rule that names the control you need. If nobody can state the requirement, the requirement is usually a preference for control.
# ---- IaaS: your responsibility starts at the operating system ----
az vm create --name employees-vm --resource-group employees-prod \
--image Ubuntu2204 --admin-username deploy --generate-ssh-keys
ssh deploy@<public-ip>
sudo apt-get update && sudo apt-get install -y dotnet-sdk-8.0 # you own this version
sudo cp employees-api.service /etc/systemd/system/ # you own restarts
sudo systemctl enable --now employees-api # you own the firewall too
# ---- PaaS: your responsibility starts at the container image ----
az containerapp up --name employees-api --resource-group employees-prod \
--image anviregistry.azurecr.io/employees-api:9f4c2ab --target-port 8080 --ingress external- The first block is four separate responsibilities you have just accepted: the runtime version, the service definition, the restart behaviour, and the network rules. None of them is difficult. All of them need revisiting when a security advisory lands.
- The second block hands over an image and a port. The platform supplies the operating system, the TLS certificate for its default hostname, a load balancer and restart-on-failure.
- The image tag in the PaaS command is a commit identifier rather than latest. That is deliberate and is the subject of the artifacts lesson later in this course.
- AWS has direct equivalents: EC2 for the first, and Elastic Beanstalk or ECS on Fargate for the second. The commands differ; the division of responsibility does not.
Summary
- The three models describe how much of the stack the provider operates, and nothing else
- IaaS leaves you the operating system and everything above it; PaaS starts at your application or image; SaaS leaves you your data and settings
- Serverless is a billing and scaling style of platform service, not a separate model
- Default to the most managed option that meets a stated requirement
- Taking back a layer for control means taking back its patching, monitoring and documentation too
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Place the service
For each of these, decide which model it is and name one responsibility it leaves with you: a managed PostgreSQL database; a rented Windows machine you remote into; the issue tracker your team uses; a function that runs when a photo is uploaded.
Show solution
Managed PostgreSQL is platform-shaped: the provider patches and backs up the engine, and you still own the schema, the indexes, the query performance and who can connect.
The rented Windows machine is infrastructure. Everything above the hypervisor is yours, including the operating system updates and the antivirus policy your organisation requires.
The issue tracker is software as a service. You own your projects, your user list and the export you would need if you left.
The upload function is platform, in the flavour usually called serverless. You own the code, its dependencies, and the fact that it might run twice for one upload — which is why it needs to be safe to repeat.
Challenge
Write the requirement down
Someone on your team proposes deploying the employees API to a virtual machine instead of a managed platform. Write the one question that settles the argument, and the answer that would make them right.
Show solution
The question is: which specific requirement can the managed platform not meet? Not which feels safer — which requirement.
Answers that make them right: the API depends on a native library that needs a system package the platform image does not include; a regulator requires a control you can only apply at the operating system level; the service needs a fixed outbound IP address the platform cannot provide.
Answers that do not: we want full control, we have always done it this way, we might need to log in one day. Those are real feelings and they are not requirements, and accepting them costs your team patching work every month for years.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.