Compare the cloud service models and pick the right one for a workload.
Why it matters
"Put it in the cloud" can mean very different things. You might rent a bare virtual machine and install everything yourself, or you might upload a single function and never think about a server at all. Each choice moves work (and control) between you and the provider. Picking the wrong model is one of the most common reasons a cloud project costs too much or takes too long to run.
The core idea: who manages which layer
Think of an application as a stack of layers, from the bottom up: physical data centre, network, servers and storage, virtualisation, operating system, runtime (for example Python or Node.js), your application code, and your data. The service models differ only in where the line sits between "the provider manages it" and "you manage it".
| Model | Provider manages | You manage | Examples |
|---|---|---|---|
| On-premises | nothing | everything | your own server room |
| IaaS (Infrastructure as a Service) | hardware, network, virtualisation | OS, patches, runtime, app, data | AWS EC2, Azure Virtual Machines, Google Compute Engine |
| PaaS (Platform as a Service) | everything up to the runtime | app code, configuration, data | AWS Elastic Beanstalk, Azure App Service, Google App Engine |
| Serverless / FaaS | servers, scaling, runtime | individual functions and data | AWS Lambda, Azure Functions, Google Cloud Run functions |
| SaaS (Software as a Service) | the whole application | your data and user settings | Gmail, Microsoft 365, Salesforce |
A useful analogy is getting a meal. On-premises is cooking at home from scratch. IaaS is renting a kitchen: the room and appliances are provided, but you buy ingredients and cook. PaaS is a meal kit: the hard parts are done, you assemble. SaaS is eating at a restaurant. Serverless is ordering a single dish only when you are hungry and paying per plate.
What serverless really means
Serverless does not mean there are no servers. It means you never see, size or patch them. You upload code, say what event should trigger it (an HTTP request, a file landing in storage, a timer), and the provider runs it on demand. You pay per request and per unit of compute time, and when nothing is happening you usually pay nothing. The trade-offs are limits on how long one run can last, a "cold start" delay when a function has not run recently, and less control over the environment.
Managed databases (AWS RDS, Azure SQL Database, Google Cloud SQL) sit between IaaS and PaaS: the provider patches and backs up the database engine, and you design the schema and queries.
Worked example: three workloads
1. A legacy accounting application that needs a specific Windows version and a licensed add-on. It must control the operating system, so IaaS (a virtual machine) is the realistic choice. You will patch it yourself.
2. A new web API written in Python by a team of three who do not want to manage servers. PaaS (or a container platform) lets them push code and get load balancing, scaling and HTTPS. They still own the code and the data.
3. A thumbnail generator that runs whenever a user uploads an image, a few hundred times a day. Long idle periods and short bursts are the ideal shape for serverless: a function triggered by each upload, costing almost nothing at low volume.
And if the company just needs email and shared documents, it should buy SaaS rather than build anything.
How to choose
Ask these questions in order:
- Does a SaaS product already do this well enough? If yes, buy it.
- Does the workload need control of the operating system, special drivers or a licence tied to a machine? If yes, IaaS.
- Is it event-driven, short-running and spiky? Consider serverless.
- Otherwise, a PaaS or managed container service is usually the best balance of control and effort.
Common mistakes
- Lifting everything onto VMs because it feels familiar, then paying for idle servers around the clock and patching them forever.
- Forcing long jobs into serverless. A batch job that runs for hours does not fit function time limits; use a VM, a container job or a batch service.
- Forgetting that "managed" still has a customer side. On PaaS you are still responsible for your code's security and your data.
- Comparing only the price per hour. Include the people-time spent on patching, scaling and on-call work.
Quick recap
- The models differ in which layers the provider manages: IaaS (you manage the OS and up), PaaS (you manage the app), SaaS (you manage your data), serverless (you manage functions).
- Serverless still runs on servers; you just never manage them, and you pay per use.
- Choose SaaS first, IaaS when you need OS control, serverless for short event-driven work, and PaaS for most new applications.