What Is Containerisation?

Containerisation is a lightweight form of virtualisation that packages an application together with its dependencies, libraries, and configuration into a single, portable unit called a container. This lesson introduces the core concepts behind containers, compares them with traditional virtual machines, and explains the architecture that makes Docker the industry standard.

The Problem Containers Solve

Before containers, deploying software was plagued by the classic "it works on my machine" problem:

Environment drift between development, staging, and production
Dependency conflicts when multiple applications share the same host
Slow provisioning of new environments
Inconsistent behaviour across operating systems and distributions

Containers solve all of these by bundling everything an application needs into an isolated, reproducible package.

Virtual Machines vs Containers

Virtual machines and containers both provide isolation, but they achieve it in fundamentally different ways.

+--------------------------------------------+
|          Virtual Machine Stack              |
|--------------------------------------------|
|  App A  |  App B  |  App C                  |
|  Bins/Libs  |  Bins/Libs  |  Bins/Libs      |
|  Guest OS   |  Guest OS   |  Guest OS       |
|--------------------------------------------|
|           Hypervisor (Type 1 or 2)          |
|--------------------------------------------|
|             Host OS / Hardware              |
+--------------------------------------------+

+--------------------------------------------+
|           Container Stack                   |
|--------------------------------------------|
|  App A  |  App B  |  App C                  |
|  Bins/Libs  |  Bins/Libs  |  Bins/Libs      |
|--------------------------------------------|
|           Container Runtime (Docker)        |
|--------------------------------------------|
|             Host OS / Hardware              |
+--------------------------------------------+

Feature	Virtual Machine	Container
Isolation level	Full OS-level	Process-level (shared kernel)
Start-up time	Minutes	Seconds (or less)
Size	Gigabytes	Megabytes
Resource overhead	High (each VM runs full OS)	Low (shared kernel)
Portability	Moderate	Very high
Density per host	Low (tens)	High (hundreds to thousands)
Use case	Full OS isolation, legacy	Microservices, CI/CD, cloud

Key insight: Containers share the host kernel, which is why they are so much lighter and faster than VMs. However, this also means the isolation boundary is thinner than a hypervisor.

Benefits of Containerisation

Consistency — The same container image runs identically on a developer laptop, CI server, and production cluster.
Speed — Containers start in seconds, enabling rapid iteration and scaling.
Density — You can run far more containers on a single host than VMs.
Isolation — Each container has its own filesystem, networking, and process tree.
Portability — Build once, run anywhere that has a container runtime.
Immutability — Container images are read-only; changes create new images, making rollbacks trivial.

OCI Standards

The Open Container Initiative (OCI) defines industry standards for container technology:

Standard	Purpose
OCI Image Spec	Defines the format of container images
OCI Runtime Spec	Defines how to run a container from an image
OCI Distribution Spec	Defines how to push/pull images from registries

These standards ensure interoperability — an image built with Docker can run with Podman, containerd, or any OCI-compliant runtime.

Docker Architecture

Docker uses a client-server architecture with three main components:

+------------------+          +-------------------+
|   Docker CLI     |  REST    |   Docker Daemon   |
|   (docker)       | -------> |   (dockerd)       |
+------------------+   API    +-------------------+
                                     |
                           +---------+---------+
                           |                   |
                     +----------+        +----------+
                     | Images   |        |Containers|
                     +----------+        +----------+
                           |
                     +----------+
                     | Registry |
                     | (Hub)    |
                     +----------+

Docker Daemon (dockerd)

The daemon is a background service that manages images, containers, networks, and volumes. It listens for API requests from the Docker CLI or other clients.

Docker CLI (docker)

The command-line interface is the primary way users interact with Docker. Every docker command sends a REST API call to the daemon.

Docker Registry

A registry stores and distributes container images. Docker Hub is the default public registry, but you can also run private registries.

Key Concepts

Concept	Description
Image	A read-only template containing the application and its environment
Container	A running (or stopped) instance of an image
Dockerfile	A text file with instructions to build an image
Layer	Each instruction in a Dockerfile creates a layer; layers are cached
Tag	A human-readable label for an image version (e.g. `nginx:1.25`)

Container Lifecycle

A container goes through several states during its lifetime:

   docker create          docker start          docker stop
 +-----------+  ------>  +-----------+  ------>  +-----------+
 |  Created  |           |  Running  |           |  Stopped  |
 +-----------+  <------  +-----------+  <------  +-----------+
                docker restart         docker start
                                                     |
                                              docker rm
                                                     |
                                                     v
                                              +-----------+
                                              |  Removed  |
                                              +-----------+

State	Description
Created	Container exists but has not been started
Running	Container process is active
Paused	Container process is suspended (SIGSTOP)
Stopped	Container process has exited
Removed	Container and its writable layer are deleted

When to Use Containers

Containers are ideal for:

Microservice architectures — each service in its own container
CI/CD pipelines — consistent build and test environments
Local development — run databases, message queues, and services without installing them natively
Cloud-native deployment — Kubernetes, ECS, Cloud Run all run containers
Rapid prototyping — spin up environments in seconds

Containers may not be the best fit for:

Applications requiring direct hardware access (e.g. GPU-heavy workloads, though this is improving)
Stateful workloads that are difficult to manage with ephemeral containers (though volumes help)
Different kernel requirements — containers share the host kernel, so a Linux container cannot run on a Windows kernel without a VM layer

Summary

Containers are lightweight, portable, isolated environments that package an application with its dependencies.
Unlike VMs, containers share the host kernel, making them faster and more resource-efficient.
The OCI standards ensure container images and runtimes are interoperable across tools.
Docker follows a client-server architecture: the CLI talks to the daemon, which manages images and containers.
Containers go through a clear lifecycle: created, running, paused, stopped, removed.
Containerisation is the foundation for modern DevOps practices, microservices, and cloud-native deployment.