What a container actually is

"It works on my machine" was, for years, the most expensive sentence in software — the app ran fine for the developer and broke on the server, because the two machines had different versions of everything. Containers ended that excuse. They package an application with everything it needs to run, so it behaves the same on your laptop, in CI, and in production. Containers are the foundation of modern deployment, and this module builds a real one. This first lesson is what a container actually is, and why it changed everything.

The problem: environments differ

Software depends on its environment: a particular version of the language runtime, specific libraries, system packages, config, environment variables. When the developer's laptop has Node 20 and the server has Node 16, or a library is a different version, the app that ran perfectly locally fails in production — mysteriously, and often only under real conditions. Multiply that across a team and many services, and "works on my machine" becomes a constant, costly source of bugs and outages.

The old fixes were painful: long setup documents ("install exactly these versions"), or heavy virtual machines. Containers solve it cleanly by shipping the environment with the app.

What a container is

A container is a running instance of an image, and an image is a packaged, read-only bundle of your application plus its entire environment — the runtime, libraries, system packages, and files it needs. When you run the image, you get a container: an isolated process that has its own filesystem (from the image), its own network, and its own view of the system, but shares the host's kernel.

The key properties:

It is self-contained. The image includes the app and its dependencies, so it runs the same wherever the container engine runs — your laptop, CI, a cloud server. The environment travels with the app.
It is isolated. A container has its own filesystem and processes, separate from the host and from other containers, so two apps needing different library versions coexist without conflict.
It is lightweight and fast. A container is just isolated processes on the host, starting in milliseconds — very different from a virtual machine.

So "works on my machine" becomes "works in this image, everywhere", because the machine is the image, and the image is identical wherever it runs. That reproducibility is the whole point.

Containers versus virtual machines

You may have heard of virtual machines (VMs), which also isolate applications. The difference matters:

A VM virtualises an entire computer — it runs a full guest operating system (its own kernel) on top of the host. That is powerful but heavy: gigabytes in size, tens of seconds to boot, significant memory just for the OS.
A container shares the host's kernel and isolates only at the process level. It ships just the app and its dependencies — typically tens to a few hundred megabytes, starting in milliseconds.

So a container gives you most of the isolation of a VM at a tiny fraction of the weight. That lightness is why you can run many containers on one machine, start and stop them instantly, and build deployment systems (Kubernetes — the next module) around packing thousands of them across a fleet. VMs and containers both have their place, but for shipping applications, containers won because they are reproducible and cheap.

Why containers matter for DevOps

Containers are not just a convenience; they reshape how software is built and shipped:

The same artifact everywhere. You build an image once and run that exact image in test, staging and production — no "it was different on the server". The image is the unit of deployment.
Fast, consistent deployment. Deploying becomes "run this image", which is quick and identical every time, enabling the automated pipelines of the CI/CD module.
Density and scaling. Because containers are light, you pack many onto a machine and start more instantly when load rises — the foundation of orchestration and autoscaling (the Kubernetes module).
Isolation and cleanliness. Each service runs in its own container with its own dependencies; the host stays clean, and services do not interfere.

Almost everything else in this course — Kubernetes, CI/CD deploying images, cloud services running containers — assumes containers. This module gives you the real, hands-on foundation: over the next lessons you will run containers, write a Dockerfile for a small web service (the "greetings" app used throughout), keep the image small, and wire up a multi-container stack with Compose. By the end, "containerise an app" will be something you have actually done.

Check your work

The problem: apps depend on their environment (runtime/library versions, packages, config); when the dev machine and server differ, "works on my machine" breaks in production. Old fixes (setup docs, heavy VMs) were painful.

A container is a running instance of an image — a packaged, read-only bundle of the app plus its whole environment. Properties: self-contained (runs the same everywhere — the environment travels with the app), isolated (own filesystem/processes; different versions coexist), lightweight/fast (isolated processes, start in ms).

Container vs VM: a VM virtualises a whole computer with its own guest OS/kernel (heavy — GBs, seconds to boot); a container shares the host kernel and isolates at the process level (light — tens/hundreds of MB, ms to start). Containers won for shipping apps: reproducible and cheap.

Why it matters for DevOps: the same image runs in test/staging/prod (the deploy unit), fast/consistent deployment (enables pipelines), density/scaling (enables orchestration), and clean isolation. Kubernetes, CI/CD and cloud all assume containers.

Practice

Explain "works on my machine" and how containers eliminate it, in terms of images carrying the environment.
Define an image and a container, and the relationship between them.
List three properties of containers and why each matters for deployment.
Compare a container and a VM on kernel, size and startup time, and say why containers suit shipping apps.
Give three ways containers change how software is deployed in a DevOps setting.
Explain why the rest of this course (Kubernetes, CI/CD, cloud) assumes containers.

Official documentation

Docker — What is a container? — Containers explained, with the VM comparison.
Docker — Getting started overview — Images, containers and the Docker platform.
Red Hat — Containers vs VMs — The difference, in depth.

Next: Docker — images, containers and the daemon.