What It Actually Means
Docker is the name most people encounter. The problem it addresses is the oldest complaint in software: it worked on the developer’s machine and not on the server, because the two had different versions of something nobody thought to check.
What It Genuinely Solves
Environments stop drifting. Development, staging and production run the same image rather than three similar setups maintained separately. A whole category of confusing bugs disappears.
Setup becomes reproducible. A new developer starts working in minutes rather than spending a day installing the right versions of things. On a project with any turnover this is worth a great deal.
Deployment gets predictable. The thing tested is the thing shipped, rather than a set of instructions performed again on a different machine.
The recipe is written down. The configuration is a file in version control rather than knowledge in somebody’s head about how the server was set up. That alone removes a common single point of failure.
What It Costs
A skill requirement. Containers introduce concepts that have to be understood: images, volumes, networking between containers. A team that half-understands them produces something harder to debug than what it replaced.
More moving parts. For a simple site on a single server, containers can add complexity without solving a problem you had.
Orchestration is a further step. Running containers across multiple machines usually means Kubernetes, which is powerful and a substantial undertaking. It is emphatically not required to use containers, and it is frequently assumed to be.
Is It Right For You
Worth it when several people work on the same system, when environment differences have caused real problems, when the application has several parts that must run together, or when the setup is complicated enough that documenting it properly matters.
Probably not worth it for a straightforward site on managed hosting, maintained by one person, where nothing has ever gone wrong for environmental reasons.
The honest test is whether you have felt the problem. Containers solve a specific pain, and businesses that have not experienced it are buying complexity in advance.
What To Ask
- What problem does this solve for us? There should be a concrete answer, ideally one you recognise.
- Do we need orchestration, or just containers? Usually just containers, and conflating them is expensive.
- Who understands this? If one person does, that is a dependency worth naming.
- How does data persist? Containers are disposable by design; anything that must survive needs deliberate handling, and getting this wrong loses data.
- Where do the images live, and are they scanned? Base images carry dependencies and their vulnerabilities.
The Realistic Position
Containers have become the ordinary way to package server software, and for anything of moderate complexity they are a sensible default rather than an advanced choice.
Where it goes wrong is adopting the whole ecosystem at once, on a system that did not need it, because the surrounding tooling is presented as a package. Containers on a single server, deployed simply, deliver most of the benefit at a fraction of the cost.
More terms are in the glossary.
