Every cloud bill tells you what you rent, but not what you still have to do yourself. Two companies can both say "we're on AWS" and mean completely different things: one runs fifty virtual machines that its engineers patch every month, the other deploys code to a managed platform and never logs into a server at all. The difference between them is the difference between IaaS vs PaaS vs SaaS – the three service models that make up most of what people mean by cloud computing. Understanding them is less about vocabulary and more about knowing where your team's time will go.
Cloud computing explained in one picture
Think of any running application as a stack of layers, from bottom to top:
- Physical data centre, power, cooling, network
- Servers and storage hardware
- Virtualisation
- Operating system
- Runtime (Node.js, Python, Java, .NET) and middleware
- Your application code
- Your data and user configuration
Before the cloud, a company owned all seven. Each cloud model moves the line of who manages what further up the stack:
| Layer | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data centre & hardware | You | Provider | Provider | Provider |
| Virtualisation | You | Provider | Provider | Provider |
| Operating system | You | You | Provider | Provider |
| Runtime & middleware | You | You | Provider | Provider |
| Application code | You | You | You | Provider |
| Data & user access | You | You | You | You |
Notice the bottom row. In every model, your data, who can access it and how it is configured stays your responsibility. Cloud providers call this the shared responsibility model, and misunderstanding it is behind many cloud data leaks – a storage bucket left publicly readable is not the provider's mistake.
IaaS: renting the building blocks
Infrastructure as a Service gives you virtual machines, storage volumes and networks on demand. Amazon EC2, Azure Virtual Machines, Google Compute Engine, and smaller providers like DigitalOcean and Hetzner are typical examples.
You choose the operating system, install the software, configure the firewall and keep everything patched. In return you get near-total control: any OS, any database version, any odd piece of legacy software that needs a particular kernel module.
IaaS makes sense when:
- You are migrating existing systems ("lift and shift") and cannot rewrite them yet.
- You need specialised configuration – GPU workloads, unusual networking, licensed software tied to a machine.
- You have, or want to build, an operations team comfortable with Linux administration, monitoring and backups.
The trap is that IaaS feels like the cloud but behaves like owning servers. Someone still has to apply security updates at 2 a.m. when a critical vulnerability lands.
PaaS: bring your code, skip the servers
Platform as a Service takes the operating system and runtime off your plate. You push code; the platform builds it, runs it, scales it and restarts it when it crashes. Heroku popularised the model. Google App Engine, Azure App Service, AWS Elastic Beanstalk, Render, Fly.io and front-end platforms like Vercel and Netlify all sit in this category, as do managed databases such as Amazon RDS or Google Cloud SQL.
Serverless functions – AWS Lambda, Azure Functions, Google Cloud Functions – push the idea further. You do not even run a long-lived application; you upload functions that execute in response to events and are billed per invocation. Many people treat "Functions as a Service" as its own category; it is easiest to think of as PaaS with the dial turned all the way up.
PaaS is usually the right default for new web applications and APIs because it removes the least differentiated work. Nobody chooses your product because you patched Ubuntu particularly well.
The trade-offs are real, though:
- Less control. You run on the versions and configurations the platform supports.
- Lock-in. Platform-specific features (queues, auth, proprietary config files) make leaving harder. Containerising your app keeps the exit door open.
- Cost curves. PaaS is cheap at small scale and can become expensive at large, steady scale, where well-run IaaS or containers on a managed Kubernetes service may be cheaper per unit of compute.
SaaS: using finished software
Software as a Service is a complete application you use through a browser or app: Gmail and Google Workspace, Microsoft 365, Salesforce, Slack, Zoom, Shopify, Xero, Notion. You manage nothing technical except your users, your settings and your data.
For anything that is not your core business, SaaS is almost always the sensible choice. Building your own email server or HR system rarely pays off. The decisions that matter shift from engineering to governance:
- Identity: connect SaaS tools to single sign-on so leavers lose access everywhere at once.
- Data export: check you can get your data out in a usable format before you commit.
- Configuration: sharing defaults, MFA enforcement and admin roles are still yours to get right.
- Integration: SaaS tools that cannot talk to each other create manual copy-paste work.
IaaS vs PaaS vs SaaS: a worked example
Say you run an online furniture shop. A sensible architecture might use all three models at once:
- SaaS for the things every business needs: Google Workspace for email, Xero for accounting, Zendesk for support, Shopify for the store's checkout.
- PaaS for the parts that make you different: a custom room-planner app deployed on a managed platform, backed by a managed Postgres database.
- IaaS only where you have a specific reason: perhaps a single virtual machine running an old warehouse integration that only works on a particular Windows Server version.
This mix is normal. Very few companies are purely one model, and the question is never "which cloud model are we?" but "which model fits this particular workload?"
How to choose the right cloud service model
Work through these questions for each system:
- Is this core to how we compete? If not, look for SaaS first.
- If we build it, does it need unusual control over the OS or hardware? If not, choose PaaS or serverless.
- Do we have people who will patch, monitor and back up servers? If not, avoid IaaS unless a managed service provider does it for you.
- What does it cost at ten times today's usage? Model the bill before you are locked in.
- How would we leave? Standard containers, standard databases and documented exports keep options open.
When we build custom platforms at Mraviko, the starting assumption is managed services for everything that is not the product itself, with infrastructure as code so the setup can be recreated or moved.
The short version
IaaS rents you computers, PaaS rents you a place to run code, and SaaS rents you finished software. Moving up the stack trades control for time. For most businesses, the winning pattern is SaaS for commodity tools, PaaS for custom software, and IaaS only where there is a clear reason – with your data, access and configuration treated as your job in every case. Get that division of responsibility right, and cloud computing does what it promised: lets your team spend its hours on the work only it can do.
