What is Docker?

What Docker means

Docker is the most widely used platform for working with containers. A container is a lightweight, isolated package that holds an application and the exact set of dependencies it needs — the right language runtime, the right system libraries, the right configuration files — all frozen together. Because the container carries its own environment, it does not depend on whatever happens to be installed on the host machine. That is the whole point: the box you test is the box you ship.

Docker introduced the everyday vocabulary engineers now use. You write a Dockerfile describing how to assemble the environment, build it into an image (a read-only snapshot), and run that image as one or more containers. Images are stored in a registry so any machine can pull the exact same build.

Where it came from

Docker launched in 2013 and made an old idea suddenly accessible. The underlying Linux features — control groups and namespaces that isolate processes — had existed for years, but they were difficult to use directly. Docker wrapped them in a simple command-line tool and a portable image format, and adoption was explosive. Within a few years "containerize it" became the default answer to how software should be packaged and shipped.

That success created a need for standards, so the industry formed the Open Container Initiative to define a vendor-neutral image and runtime format. Today the container ecosystem is far larger than any single company, but Docker remains the name most engineers reach for when they mean "build and run a container."

How it works

Unlike a virtual machine, which boots a complete guest operating system, a container shares the host's kernel and isolates only the application's own processes, filesystem, and network view. That makes containers dramatically lighter: they start in milliseconds, and you can run dozens on a laptop that could only handle a couple of virtual machines.

Images are built in layers. Each instruction in a Dockerfile — install a dependency, copy in the source, set an environment variable — produces a cached layer. When you rebuild, Docker reuses the layers that did not change, so builds stay fast. The finished image is immutable, which is what gives containers their reliability: a given image tag always produces the same running environment, no matter where or when it launches.

When it matters

Docker matters as soon as your software needs to run somewhere other than the machine it was written on — which is essentially always. It eliminates the "works on my machine" class of bugs, makes onboarding a new developer a one-command affair, and turns deployment into the simple act of running a known image. It is also the building block for everything above it: continuous delivery pipelines build images, and orchestrators like Kubernetes schedule them. If you plan to scale horizontally, run a microservices architecture, or deploy to the cloud at all, containers are the foundation those choices rest on.

At QUANT LAB

We containerize the applications we build so that the environment is part of the deliverable, not an afterthought. A typical QUANT LAB project ships with a Dockerfile that pins the exact Node and dependency versions, plus a Compose file that spins up the app and a local Postgres database with one command. New developers — and our clients' in-house teams after handoff — get a running stack on the first try, every time.

Those same images are what our DevOps engineering pipelines build, test, and promote to production, and they are what makes our cloud infrastructure portable across hosts. Containerizing a legacy app that was deployed by hand is one of the highest-leverage things we do early in an engagement.