Overview

When a server cannot handle growing traffic, two strategies exist:

Vertical scaling (scale-up) : Replace the server with a more powerful one — more CPU, RAM, faster disk. Simple, but bounded: there is a physical limit to how large a single machine can be, and upgrades require downtime.

Horizontal scaling (scale-out) : Add more servers and distribute the load across them. Theoretically unbounded, but introduces a critical problem: consistency across environments.

flowchart LR
    subgraph vs [Vertical Scaling]
        s1["Server\n4 CPU / 8 GB"]:::small -->|upgrade| s2["Server\n32 CPU / 128 GB"]:::big
    end
    subgraph hs [Horizontal Scaling]
        lb[Load Balancer] --> n1[Server 1]
        lb --> n2[Server 2]
        lb --> n3[Server 3]
    end
    classDef small fill:#ddd
    classDef big fill:#6c6,color:#fff

With one server, you can install Java, configure the database driver and tune environment variables by hand. With ten servers behind a load balancer, every one of them must be identical — the same OS, the same Java version, the same libraries, the same configuration — or a request will behave differently depending on which server it lands on.

An application that works on a developer's laptop may fail in production because of different OS versions, library versions, or environment variables — the infamous "it works on my machine" problem.

Containerisation solves this by packaging the application together with all its dependencies into a portable, self-contained unit — a container image — that runs identically everywhere: on your laptop, on the CI server and on every production node.

Roadmap

1. This overview — why containers, containers versus VMs, what a container really is, and the image lifecycle.
2. Docker — Dockerfiles, multi-stage builds, layer caching, commands, networks and volumes.
3. Docker Compose — describing and running a whole stack (gateway, services, database) in one file.
4. Quiz — check your understanding.

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

Containers vs. Virtual Machines

Both containers and virtual machines (VMs) provide isolation, but at different levels of the stack:

flowchart TB
    subgraph vm [Virtual Machines]
        direction TB
        hw_vm[Physical Hardware]:::infra
        hvm[Hypervisor]:::infra
        os1[Guest OS 1]:::customer
        os2[Guest OS 2]:::customer
        app1[App A]:::customer
        app2[App B]:::customer
        hw_vm --> hvm --> os1 & os2
        os1 --> app1
        os2 --> app2
    end
    subgraph ct [Containers]
        direction TB
        hw_ct[Physical Hardware]:::infra
        os_ct[Host OS + Kernel]:::infra
        engine[Container Engine]:::infra
        c1[Container A]:::customer
        c2[Container B]:::customer
        hw_ct --> os_ct --> engine --> c1 & c2
    end
    classDef infra fill:#a8e6cf,stroke:#333
    classDef customer fill:#ffd3b6,stroke:#333

Provider / shared layer    Application layer

The key insight: containers share the host kernel, so they start in seconds and consume far less memory. VMs carry their own kernel — giving stronger isolation at the cost of higher overhead².

In practice the two are combined, not opposed: a cloud provider rents you a VM (isolation between customers), and you run several containers on it (density and portability for your services).

What a container really is

A container is not a lightweight VM: it is an ordinary Linux process that the kernel shows a restricted view of the machine. Three kernel features make that possible:

You can verify the "just a process" claim yourself:

docker run --rm alpine ps                               # inside: ps is PID 1, nothing else is visible
docker run -d --name pg -e POSTGRES_PASSWORD=secret postgres:17
docker top pg                                           # from the host: the postgres processes, with host PIDs

The container lifecycle

flowchart LR
    src[Source Code\n+ Dockerfile] -->|docker build| img[Image\n:tag]
    img -->|docker push| reg[(Registry\nDocker Hub / ECR)]
    reg -->|docker pull| deploy[Any Host]
    deploy -->|docker run| c1[Container 1]
    deploy -->|docker run| c2[Container 2]
    deploy -->|docker run| c3[Container 3]

A Dockerfile describes how to build the image. An image is the immutable artifact — it gets versioned, stored in a registry, and pulled onto any machine. A container is a running instance of an image — isolated, ephemeral, and disposable¹.

Topics covered

Containerisation in the cloud

Docker and Compose run containers on one host. Running them across many hosts — restarting crashed containers, spreading replicas, rolling out new versions — is the job of an orchestrator such as Kubernetes³ (Hands-on 5). Cloud providers offer managed container services that add automatic scheduling, scaling, load balancing, and deep integration with other cloud services on top of the container model:

Connections

• Hands-on 1 — Containerization — the account service and PostgreSQL in Docker Compose.
• Hands-on 4 — a CI pipeline that builds and publishes images.
• Hands-on 5 and the MiniKube exercise — running the same images on Kubernetes.
• Cloud Service Models and Cloud Deployment — where containers fit among IaaS, PaaS and managed container services.

Key takeaways

• Horizontal scaling needs identical environments; a container image packages the app with all its dependencies and ends "it works on my machine".
• A container is an isolated Linux process (namespaces + cgroups + layered filesystem), not a small VM: it shares the host kernel, starts in seconds and isolates less than a VM.
• Dockerfile → image → registry → container: the image is the immutable, versioned artifact; containers are disposable.
• Keep state out of containers (volumes) and ship explicit image versions, not latest.
• Docker and Compose run containers on one host; orchestrators and managed cloud services run them across many.