Cloud models: IaaS, PaaS, SaaS

How much to hand to the cloud

You can use the cloud in different ways. You can take a bare virtual machine and set up everything yourself, or you can take a ready-made service where you don't see any servers or OS. Between these extremes lie three models: IaaS, PaaS, and SaaS. They differ in how many layers the provider manages and how many you do.

The model decides who patches the OS, who makes backups, and who's responsible when something breaks. Mix it up, and the work falls on no one: you think the provider does it, and the provider thinks it's yours.

The responsibility ladder

An application stack has layers, bottom to top: hardware and data center, virtualization, OS, runtime, application, data. Cloud models differ in where the line falls between "the provider manages this" and "you manage this".

                      IaaS        PaaS        SaaS
data and access       you         you         you
application           you         you         provider
runtime               you         provider    provider
OS                    you         provider    provider
virtualization        provider    provider    provider
hardware, datacenter  provider    provider    provider

The higher the model, the more the provider takes on and the less is left to you. But the top row never changes: data, accounts, and access permissions stay with you in every model.

Providers call this the shared responsibility model. That's the name to search for in a specific cloud's documentation. The terms IaaS, PaaS, and SaaS themselves are defined in NIST SP 800-145.

IaaS: infrastructure as a service

IaaS gives you virtual resources: virtual machines, networks, disks, load balancers. The provider is responsible for the hardware and virtualization, while the OS, runtime, and application are on you. This is what Terraform describes in the IaC lesson: you order a virtual machine and install everything else on it yourself.

The upside of IaaS is maximum control and flexibility. You pay for it in work: patching the OS, configuring services and the firewall, watching over everything yourself.

PaaS: platform as a service

PaaS gives you a platform you push code or data to, without thinking about servers or the OS. A managed database (say, managed PostgreSQL) and services of the "upload code, we run it" kind count as PaaS. The provider maintains the OS, runtime, and updates, while you're responsible for your application, its configuration, and its data.

The upside is less operational work: no patching the OS or manually setting up database replication. In exchange, you lose some control and get tied to the platform.

The line for a specific service can fall differently. Managed Kubernetes usually sits somewhere in the middle: the provider runs part of the cluster, part stays on you. So for every service, check the responsibility model in the provider's documentation instead of guessing from the name.

SaaS: software as a service

SaaS is a ready-made application you just use: email, a task tracker, a CRM. You don't see servers, the OS, or code, only an account and settings. The provider maintains everything except your data, users, and settings.

How to choose

A simple rule: take as a service whatever gives you no competitive advantage, and keep whatever does. There's no point running your own mail server (take SaaS) or manually patching a database (take a managed database) unless that's your core business. You keep your application's unique logic under your own control.

The higher the model, the less operational work and the less control. The choice is always a balance between "less hassle" and "more control and independence". In a real system, models mix: the application on virtual machines (IaaS), the database in a managed service (PaaS), backups in object storage, tasks in a SaaS tracker.

Common mistakes

• "It's PaaS, so data isn't my problem." The provider of a managed database usually makes backups and keeps the service running. But those backups live in the same account as the database: delete the account or the database by mistake, and they can disappear with it. How long to keep them, whether to test restoring, and whether you need a copy somewhere else is your call. The data is still yours.
• "It's SaaS, so security isn't mine." Users, passwords, two-factor authentication, and access permissions in SaaS are something you configure. A leaked admin password won't get revoked by the provider on its own.
• Guessing the model from the product name. The word "managed" in a name still doesn't say who patches the nodes or who configures the network. The answer is in that specific service's responsibility model.
• "IaaS is cheaper because resources are cheaper." A virtual machine might cost less than a managed service, but time spent on patches, monitoring, and backups costs money too.

What you'll need for the tasks

• The "who's responsible for which layer" table from the section "The responsibility ladder".
• The idea that data and access stay with you in every model.
• From the object storage lesson: a bucket, an object key, access over HTTP, a narrow access key.
• Docker commands from earlier tracks: docker exec, docker ps, docker logs.
• curl for HTTP requests: -T sends a file with PUT, -u user:password adds a login, -o file saves the response to a file.