Containerisation in plain English: what it is, why it matters, and when to start

"It works on my machine." Every developer has said it. Containerisation exists to make that sentence irrelevant. If it works in a container on your laptop, it works the same way in production — and that consistency is enormously valuable.

What is a container, exactly?

A container is a lightweight, isolated package that includes your application code, its runtime, libraries, and configuration — everything needed to run the software. Unlike a virtual machine, a container does not include a full operating system. It shares the host OS kernel, which makes it dramatically more efficient.

Think of it like a shipping container on a cargo ship. The ship (the server) doesn't care what's inside each container. The container is standardised, stackable, and portable. You can move it from one ship to another without unpacking and repacking everything.

The most common tool for building and running containers is Docker. When you write a Dockerfile, you describe exactly how to build your application's container image. Anyone with that image can run your application in an identical environment — your colleague in Dschang, your server in Paris, your CI pipeline in GitHub Actions.

The problem containers solve: environment drift

Without containers, every environment where your application runs — your laptop, a colleague's laptop, the staging server, the production server — tends to drift over time. Different versions of Node.js, Python, or Java. Different operating system libraries. Different environment variables set differently.

This drift is the root cause of "works on my machine." It wastes hours of debugging time and causes production incidents that are nearly impossible to reproduce locally. The traditional fix was to write exhaustive environment setup documentation and hope everyone follows it. That doesn't scale.

Containers fix this by making the environment part of the application. The Dockerfile is executable documentation — it describes the environment precisely and reproducibly. Any machine with Docker installed runs your application in exactly the described environment, every time.

Containers vs virtual machines: what's the practical difference?

Virtual machines (VMs) have been the standard isolation unit for decades. A VM runs a full operating system on top of virtualised hardware. It provides strong isolation but is slow to start (minutes), heavy on RAM (gigabytes per VM), and expensive to run at scale.

Containers share the host OS kernel. They start in seconds (or milliseconds for some workloads), use tens of megabytes of memory rather than gigabytes, and can run dozens on hardware that struggles to run a handful of VMs. The trade-off is slightly weaker isolation — containers share the kernel, so a kernel vulnerability affects all containers on the host.

For most application workloads, containers are the right choice. VMs are still valuable for workloads that require full OS isolation or when running untrusted code at scale.