Overview

Your team has built the store: a gateway, the account, auth, product and order services, a Postgres database, a Redis cache and Kafka. It runs fine on a laptop with Docker Compose. Now it has to run somewhere real. You could buy servers, rent virtual machines, push the code to a platform that runs it for you, or skip some components entirely and pay for a product that already does the job. Each option draws a different line between what your team operates and what someone else operates.

Cloud service models define how much of the stack the cloud provider manages versus how much the customer manages. The more the provider manages, the less control the customer has — and the faster they can move.

The three foundational models defined by NIST¹ are IaaS, PaaS, and SaaS. Beyond them, several specialised models have emerged — FaaS, CaaS, DBaaS, and others — each carving out a narrower slice of the stack.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

What makes it "cloud"?

Renting a server in a datacentre by signing a three-year contract is not cloud computing, even if the server is far away. NIST SP 800-145¹ defines cloud computing by five essential characteristics. A service must have all of them:

NIST also defines deployment models, which say who shares the infrastructure — not how much of it you manage:

• Public cloud — shared by any paying customer (AWS, Google Cloud, Azure).
• Private cloud — the same self-service model run for a single organisation (e.g., OpenStack in the company's own datacentre).
• Hybrid cloud — a combination, e.g., customer data stays on-premises while the web tier runs in a public cloud.
• Community cloud — shared by organisations with common requirements (e.g., government agencies).

CapEx vs OpEx. Buying servers is capital expenditure (CapEx): a large payment up front for an asset you own and depreciate over years, sized for the peak you expect. The cloud turns infrastructure into operational expenditure (OpEx): you pay monthly for what you use. OpEx removes the up-front bet, but it is not automatically cheaper — a workload that runs at full load 24/7 for years can cost more in the cloud than on owned hardware.

The shared responsibility stack

Every cloud service model can be mapped to the same six-layer stack:

The dividing line between what the provider manages (green) and what the customer manages (orange) shifts as you move up the model hierarchy:

graph TD
  subgraph On-Premises
    direction TB
    A1[Hardware] --> A2[Virtualisation]
    A2 --> A3[OS]
    A3 --> A4[Middleware]
    A4 --> A5[Application]
    A5 --> A6[Data]
    style A1 fill:#ff9999,stroke:#333
    style A2 fill:#ff9999,stroke:#333
    style A3 fill:#ff9999,stroke:#333
    style A4 fill:#ff9999,stroke:#333
    style A5 fill:#ff9999,stroke:#333
    style A6 fill:#ff9999,stroke:#333
  end
  subgraph IaaS
    direction TB
    B1[Hardware] --> B2[Virtualisation]
    B2 --> B3[OS]
    B3 --> B4[Middleware]
    B4 --> B5[Application]
    B5 --> B6[Data]
    style B1 fill:#a8e6cf,stroke:#333
    style B2 fill:#a8e6cf,stroke:#333
    style B3 fill:#ffd3b6,stroke:#333
    style B4 fill:#ffd3b6,stroke:#333
    style B5 fill:#ffd3b6,stroke:#333
    style B6 fill:#ffd3b6,stroke:#333
  end
  subgraph PaaS
    direction TB
    C1[Hardware] --> C2[Virtualisation]
    C2 --> C3[OS]
    C3 --> C4[Middleware]
    C4 --> C5[Application]
    C5 --> C6[Data]
    style C1 fill:#a8e6cf,stroke:#333
    style C2 fill:#a8e6cf,stroke:#333
    style C3 fill:#a8e6cf,stroke:#333
    style C4 fill:#a8e6cf,stroke:#333
    style C5 fill:#ffd3b6,stroke:#333
    style C6 fill:#ffd3b6,stroke:#333
  end
  subgraph SaaS
    direction TB
    D1[Hardware] --> D2[Virtualisation]
    D2 --> D3[OS]
    D3 --> D4[Middleware]
    D4 --> D5[Application]
    D5 --> D6[Data]
    style D1 fill:#a8e6cf,stroke:#333
    style D2 fill:#a8e6cf,stroke:#333
    style D3 fill:#a8e6cf,stroke:#333
    style D4 fill:#a8e6cf,stroke:#333
    style D5 fill:#a8e6cf,stroke:#333
    style D6 fill:#a8e6cf,stroke:#333
  end

Provider manages    Customer manages    Customer manages (on-premises: everything)

The same split applies to security. AWS summarises it as security of the cloud (the provider: physical datacentres, hypervisor, managed-service software) versus security in the cloud (the customer: data, identity and access management, network rules, encryption settings, the OS in IaaS)². Microsoft draws the same table for Azure³. Note that even in SaaS the data square is about operating the storage: deciding who may read the data is always the customer's job.

IaaS — Infrastructure as a Service

You rent raw infrastructure. The provider supplies virtualised compute, storage, and networking. You install the OS, runtime, middleware, and everything above.

Examples: AWS EC2, Google Compute Engine, Azure Virtual Machines, DigitalOcean Droplets.

When to choose IaaS:

• You need full OS-level control (custom kernel, specific OS version)
• Lift-and-shift of existing on-premises workloads — moving an application to cloud VMs as is, without redesigning it
• High-performance computing with specialised hardware (GPU instances)
• Strict compliance that requires controlling the entire stack

PaaS — Platform as a Service

You deploy code; the provider runs it. The provider manages the OS, runtime, middleware, scaling, and networking. You write the application and configure it via environment variables.

Examples: Heroku, AWS Elastic Beanstalk, Google App Engine, Azure App Service, Railway, Render.

Architectural implication: PaaS favours the 12-factor app⁴ pattern — stateless processes, config via environment variables, logs to stdout. The platform may restart or move your process at any time and its local filesystem is ephemeral (wiped on every restart), so persistent state must live in external managed services (database, object storage).

When to choose PaaS:

• Building a new application without infrastructure expertise on the team
• Rapid prototyping and MVPs
• API backends and microservices that don't need OS control
• Teams that want to ship features, not manage servers

SaaS — Software as a Service

You use the software; the provider runs everything. The customer manages only users, permissions, and the data they put in. There is no infrastructure or application to operate.

Examples: Google Workspace, Salesforce, Slack, Notion, GitHub, Datadog, PagerDuty.

Multi-tenancy: A single application instance serves all customers (tenants), with data isolated by tenant ID. This enables economies of scale — and is why SaaS has the lowest time-to-value.

When to choose SaaS:

• Off-the-shelf software already meets the need (CRM, HR, email, monitoring)
• The team should not be building or operating the tool itself
• Speed of adoption matters more than customisation depth

Beyond the Big Three

The foundational models have spawned specialised variants targeting a narrower part of the stack:

FaaS — Function as a Service (Serverless)

The extreme end of PaaS. You deploy individual functions rather than applications. The provider manages everything — including scaling to zero when idle — billing only for the milliseconds the function runs.

A cold start is the delay of the first request that reaches a function with no warm instance: the platform must allocate a sandbox, load the code and initialise the runtime. For a Spring Boot application this can take seconds. Providers offer mitigations — for example, Lambda provisioned concurrency keeps instances warm — but you pay for them even when idle, which erodes the main FaaS advantage.

Best for: event-driven workloads, webhooks, scheduled jobs, sporadic or bursty tasks. Not suited for long-running or consistently low-latency applications.

CaaS — Container as a Service

Between IaaS and PaaS. You provide Docker images; the provider manages the container runtime, orchestration, networking, and scaling. You retain full control of the runtime inside the container.

Best for: microservices teams already using Docker who want managed orchestration without operating Kubernetes themselves.

Managed Kubernetes (Amazon EKS, Google GKE, Azure AKS) is also usually classified as CaaS: the provider runs the Kubernetes control plane (API server, scheduler, etcd), and you deploy containers through the standard Kubernetes API maintained by the CNCF⁶. How much of the worker nodes you manage depends on the mode — classic node groups leave node sizing and upgrades to you, while modes like GKE Autopilot and EKS Auto Mode hand node management to the provider as well.

DBaaS — Database as a Service

A managed database where the provider handles provisioning, backups, replication, patching, and failover. You connect with a standard client and run queries.

Other specialised models

Example: the store, component by component

Real systems mix service models: each component goes where its trade-off is best. This is one reasonable way to run the store on AWS — the same shape as the course project, which runs the services on EKS:

flowchart LR
  client([Client]) --> gw["gateway<br/>CaaS: EKS"]
  gw --> acc["account<br/>CaaS: EKS"]
  gw --> ord["order<br/>CaaS: EKS"]
  acc --> db[("Postgres<br/>DBaaS: RDS")]
  ord --> db
  ord --> cache[("Redis<br/>DBaaS: ElastiCache")]
  ord --> kafka["Kafka<br/>managed: Amazon MSK"]
  kafka --> fn["notification<br/>FaaS: Lambda"]
  fn --> mail["e-mail<br/>CPaaS: AWS SES"]

Notice that moving a component up (from IaaS to a managed model) never removes the data and access column: you still decide who can connect to RDS, which security group reaches the gateway, and what is logged.

Full comparison

Decision framework

flowchart TD
  start([What do you need?]) --> q1{"Need full OS control<br/>or lift-and-shift?"}
  q1 -->|Yes| iaas["IaaS<br/>EC2, GCE, Azure VM"]
  q1 -->|No| q2{Deploying containers?}
  q2 -->|Yes| q3{"Want to manage<br/>Kubernetes yourself?"}
  q3 -->|Yes| k8s["CaaS on Kubernetes<br/>EKS, GKE, AKS"]
  q3 -->|No| caas["CaaS managed<br/>Cloud Run, ECS Fargate"]
  q2 -->|No| q4{"Event-driven /<br/>sporadic workload?"}
  q4 -->|Yes| faas["FaaS<br/>Lambda, Cloud Functions"]
  q4 -->|No| q5{"Building a<br/>custom application?"}
  q5 -->|Yes| paas["PaaS<br/>Heroku, App Engine"]
  q5 -->|No| saas["SaaS<br/>Use an existing product"]

Run the framework per component, not once per system: in the example above, the services land on CaaS, the order notification on FaaS, and monitoring on SaaS.

Trade-offs and pitfalls

Key takeaways

• A service is "cloud" when it has the five NIST characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service — and it turns CapEx into OpEx.
• A service model defines who manages which layer of the six-layer stack; IaaS, PaaS and SaaS move the line up, step by step.
• CaaS (images), FaaS (functions, scale to zero, cold starts) and DBaaS (managed databases) carve out narrower slices of the stack.
• More managed means faster and less operations, but less control and portability.
• Real systems mix models: choose per component — the store's services on CaaS, Postgres on DBaaS, monitoring on SaaS.
• Your data, identities, access rules and configuration are always your responsibility.

Connections

• Containerization — the Docker image that CaaS platforms run.
• Microservices — why the store is split into independently deployable services.
• Cloud Deployment Roadmap — the next class: concrete platforms (Railway, Fly.io, Lightsail, ECS, EKS) and their costs.
• Hands-on 5 — Orchestration — Kubernetes locally with Minikube, the API that EKS manages for you.
• Project: AWS, EKS and Costs & PaaS.

IaaS vs PaaS vs SaaS — practical overview of the three foundational models.