Part IA Easter Term
Cloud, Containers, and Observability
On-Premises vs Cloud
| On-Premises | Cloud | |
|---|---|---|
| Cost model | CapEx (Capital Expenditure): you buy servers, storage, networking hardware upfront. Depreciation over years. | OpEx (Operational Expenditure): pay-as-you-go. You rent compute by the second, storage by the GB-month. |
| Scaling | Manual: order hardware, wait weeks for delivery, rack it, provision it. You must size for peak load, leaving idle capacity most of the time. | Elastic: auto-scaling from 1 to 10,000 servers in minutes, scaling back down when demand drops. |
| Control | Complete: you own the physical machine, the hypervisor, the network topology. | Variable: depends on the service model (see below). |
Cloud Service Models: IaaS, PaaS, SaaS
| Model | You get | You manage | Example | Trade-off |
|---|---|---|---|---|
| IaaS (Infrastructure as a Service) | Raw virtual machines, block storage, virtual networks | OS, runtime, middleware, application, data — you patch the OS yourself | AWS EC2, Google Compute Engine, Azure VMs | Maximum control; high management overhead |
| PaaS (Platform as a Service) | A managed runtime — upload your code, the provider handles OS, scaling, load balancing | Only application code and data | Heroku, AWS Elastic Beanstalk, Google App Engine | Fast time-to-market; vendor lock-in risk, less control over the runtime environment |
| SaaS (Software as a Service) | A fully functional application accessible over the web | Nothing — you are the end user | Gmail, Slack, Salesforce | Zero maintenance; zero control over features, data residency, or security posture |
Shared Responsibility Model
The cloud provider is responsible for security OF the cloud: physical data centres, hardware, network infrastructure, and the hypervisor. The customer is responsible for security IN the cloud: their application code, data, OS-level patches (in IaaS), firewall rules, and access controls.
Analogy: the landlord supplies a lock on the front door; you must remember to turn the key.
Containers vs Virtual Machines
The problem containers solve: “it works on my machine” (which has Python 3.11, a specific version of libssl, and a library compiled with a particular compiler flag).
| Virtual Machines | Containers (Docker) | |
|---|---|---|
| What runs | Each VM runs a full Guest OS (kernel, init system, libraries) on top of a Hypervisor, which virtualises hardware. | Each container shares the Host OS kernel via the Docker Engine. The container image packages only the application and its dependencies (libraries, config files). |
| Boot time | Minutes (the guest OS must boot) | Milliseconds (just start a process with an isolated namespace) |
| Resource overhead | Heavy: each VM consumes RAM and disk for its own OS. A typical server runs 10s of VMs. | Light: ~1/10th the resource use of a VM. A typical server runs 100s of containers. |
| Isolation | Strong: a kernel exploit in one VM cannot reach another VM without also breaking the hypervisor. | Weaker: containers are process-level isolation (namespaces, cgroups). A kernel exploit can compromise all containers on the host. |
Kubernetes (K8s)
Docker runs a single container. Kubernetes manages fleets of containers across many machines. Originally built by Google from their internal Borg system.
Core capabilities:
- Self-healing: a container crashes → K8s restarts it automatically.
- Auto-scaling: traffic spikes → K8s adds more container replicas; traffic drops → K8s removes them.
- Load balancing: distributes incoming requests across all healthy containers.
Architecture:
- A Control Plane (API server, Scheduler, etcd database) manages the cluster.
- Worker Nodes are the physical or virtual machines that actually run workloads.
- Pods are the smallest deployable unit — one or more tightly-coupled containers sharing a network namespace.
- A Cluster is a single logical computer made of many physical worker nodes.
Observability
“You cannot manage what you cannot measure.”
| Pillar | Description | Example |
|---|---|---|
| Metrics | Quantitative, aggregatable numbers: counters (total requests), gauges (current memory usage), histograms (request latency distribution). | CPU at 78%, 5xx errors = 42/minute |
| Logs | Qualitative, timestamped, textual records of discrete events. | 2025-06-01 14:03:22 ERROR PaymentGateway: Connection refused to stripe.com:443 |
| Traces | A single request’s journey through a distributed system: enters via the load balancer → hits the API gateway → calls the user service → queries the database → returns a response. Every hop is recorded with timing. | ”Request a1b2c3 spent 12 ms in the API gateway, 300 ms in the user service (of which 280 ms was a DB query), total 320 ms” |
| Dashboards | Real-time visualisation of the above: Grafana, Datadog. Aggregated, queryable views of system health. | A dashboard showing 95th-percentile latency over the past 24 hours, broken down by endpoint |
Monitoring vs Observability:
- Monitoring tells you that something is wrong. It addresses known unknowns — you set up an alert for “CPU > 90%,” and when it fires, you know there is a load problem. But you do not know why.
- Observability tells you why something is wrong. It addresses unknown unknowns — you can ask arbitrary new questions of the system’s telemetry data after an incident, even for failure modes you did not predict in advance. “Which specific user request caused the memory leak?” requires observability (traces + logs), not just monitoring (CPU gauge).
Expected Learning
- Contrast on-premises and cloud deployment models in terms of cost, scaling, and control.
- Distinguish IaaS, PaaS, and SaaS with examples of each, and explain the shared responsibility model.
- Compare containers and VMs: what they share, what they isolate, and their relative resource overhead.
- Describe what Kubernetes does (self-healing, auto-scaling, load balancing) and name the key architectural components (Control Plane, Worker Node, Pod, Cluster).
- Define the three pillars of observability (metrics, logs, traces) and distinguish monitoring from observability.
Past Paper Questions
Example Sheet 2, Question 4 tests deployment strategies (Blue-Green, Canary) which are implemented in cloud environments. Cloud service models and containerisation are foundational knowledge for any deployment or scaling discussion in a scenario-based Tripos question.