Containers and Docker come up constantly once software gets involved, and they sound far more intimidating than they are. A container is just a tidy, self-contained package that holds an application together with everything it needs to run, so it behaves the same wherever you put it. Docker is the tool that made packaging and running containers easy enough for everyone. The idea solves an old, maddening problem, that software which works on one computer mysteriously breaks on another, and it is why so many modern applications ship the way they do. This guide explains containers and Docker in plain terms and shows where they fit, and where they do not, for a UK business.
The problem containers solve
Software rarely runs alone. An application depends on a specific version of a programming language, a handful of libraries, certain settings and assumptions about the system around it. Move it to a different computer where any of that differs and it can break in baffling ways, the classic it works on my machine headache that has cost developers untold hours and businesses real delays.
Containers end that argument by packaging the application together with all of its dependencies into one standardised unit. Wherever that container runs, a laptop, a server, the cloud, it carries its own environment with it, so it behaves identically everywhere. You stop shipping just the software and start shipping the software plus the exact conditions it needs to run.
What a container actually is
A useful picture is the shipping container that transformed global trade. Before it, goods were loaded loose in countless shapes and sizes, slow and unpredictable to handle. The standard steel box meant anything could be packed once and then moved by ship, train or lorry without repacking. Software containers do the same for applications: a standard unit that any compatible system can run without special handling.
Technically, a container bundles the application, its libraries and its settings, but deliberately not a whole operating system. That is the crucial detail. Containers share the operating system of the machine they run on, which is what makes them so light and quick. A few plain terms cover the rest:
- •Image: the read-only blueprint of a container, the recipe it is built from
- •Container: a running instance of an image, the live application
- •Registry: a library where images are stored and shared, like an app store for containers
- •Docker: the most popular tool for building, sharing and running containers
Containers vs virtual machines
Containers are often confused with the virtual machines behind virtualisation, and the difference is genuinely useful to grasp. A virtual machine includes a complete operating system of its own, so it is heavier, slower to start and larger, but very strongly isolated. A container shares the host's operating system and packages only the application, so it is far smaller, starts in moments and packs many more onto the same hardware.
Neither replaces the other; they answer different questions. Reach for a virtual machine when you need full isolation or to run a different operating system entirely, and for traditional applications. Reach for containers when you want to run many lightweight, modern application components efficiently and move them around freely. In practice plenty of businesses run containers inside virtual machines, getting the strong isolation of one and the agility of the other.
Why businesses use them
The headline benefit is consistency: software that runs the same in development, in testing and in production removes a whole category of nasty surprises and slow releases. Beyond that, containers are efficient, because their lightness means more applications on the same hardware, and they are portable, because the same container moves between your servers and any cloud with little fuss.
That portability is also a hedge against lock-in, since a containerised application is far easier to shift between providers than one welded to a specific platform. For software-led teams the appeal is speed: package once, run anywhere, update quickly. The trade-off is that running containers reliably at scale needs orchestration and skills, so it pays off most where you are building or running a lot of software, not for a business that simply consumes finished SaaS tools.
Do you need to care about this?
If your business mostly buys finished software, containers are something your vendors use behind the scenes rather than something you manage yourself, and that is perfectly fine. If you build or heavily customise applications, or run your own modern software in-house, containers are likely already relevant and worth understanding properly.
Either way, the foundations are the same as the rest of modern infrastructure: containers run on servers, whether yours or a provider's, so the host still has to be specified and supported correctly. If you are heading down this road on your own hardware, pair this with our virtualisation explainer and talk to us through the server configuration service about sizing a host that runs containers well.