Service models: IaaS, PaaS, SaaS, and where serverless fits

Every layer of a real application — physical hardware, operating system, runtime, application code, data — has to be managed by someone. The service models in this lesson are really just different answers to: how much of that stack do you manage yourself, and how much does the provider manage for you? Moving up the stack (from IaaS toward SaaS) means giving up control in exchange for giving up operational burden — neither direction is universally correct, and most real organizations use several service models simultaneously for different parts of their systems.

IaaS gives you a virtual machine (and networking, storage) and stops there — you manage the operating system, install and patch software, configure the runtime, and deploy your application onto it, same as you would on physical hardware you owned, just without owning or racking the physical hardware yourself. AWS EC2, Google Compute Engine, and Azure Virtual Machines are the canonical examples.

You manage: OS, runtime, application, data, security patches, scaling. Provider manages: physical hardware, virtualization, networking hardware, power/cooling.

This gives maximum control — you can install anything, configure anything — at the cost of maximum operational responsibility. It's the right fit when you need specific OS-level control, are running something with unusual requirements a managed platform doesn't support, or are migrating existing on-prem infrastructure with minimal changes.

PaaS manages the operating system and runtime for you — you deploy application code (or a container), and the platform handles provisioning, patching, and scaling the infrastructure underneath it. Heroku, Google App Engine, and AWS Elastic Beanstalk are classic PaaS examples; many modern app-hosting platforms (Vercel, Render, Railway) work on the same principle.

You manage: application code, data, application-level configuration. Provider manages: OS, runtime, patching, underlying infrastructure.

PaaS trades some control (you generally can't SSH into the underlying machine and hand-tune the kernel) for a large reduction in operational burden — no OS patching schedule, no manual scaling configuration for common cases. It fits most application backends well, especially for teams who'd rather spend engineering time on the product than on infrastructure maintenance.

SaaS is a complete, ready-to-use application delivered over the internet — you don't manage infrastructure, runtime, or the application code itself, you just use the product. Gmail, Salesforce, Slack, and Notion are SaaS. From a software-engineering-domain perspective, SaaS is usually something you integrate with (via an API) rather than something you build or operate — but it's worth naming explicitly because a huge amount of real business software runs on SaaS products rather than custom-built systems, and knowing where "build vs buy" actually lands is a real engineering decision, not just a business one.

Serverless (specifically, Function as a Service, or FaaS) takes PaaS's "don't manage the OS" a step further: you don't think about a running server at all — you write a function, the platform runs it only when triggered, and scales it (including down to zero) automatically. AWS Lambda, covered in depth later in this domain, is the standard example. It's not really a fourth tier stacked cleanly above SaaS — it's better understood as the far end of the PaaS spectrum, where the platform has abstracted away not just the OS but the entire notion of a persistently-running server process.

A single company might run its core backend on IaaS (EC2, for a workload that genuinely needs OS-level tuning), a set of background jobs on serverless (Lambda, for bursty event-driven work), and rely on SaaS for things like email delivery (a transactional email provider) or customer support tooling — rather than picking one service model and forcing everything into it. Later lessons in this domain (and the dedicated AWS domain) go deep on specific services within these models; the useful takeaway here is the underlying question each service answers — how much of the stack do you want to manage yourself — not memorizing which product name belongs to which letter.