What a quote is telling you when it says Docker

It's packaging, and packaging isn't hosting

A container is an application bundled with everything it needs to run. Not just your code: the language version it expects, the libraries it depends on, the settings, and the command that starts it, sealed into one thing machines can copy.

The seal is the point. That same bundle runs on a developer's laptop, on the machine that tests it, and on the server the public reaches. Nothing gets set up differently at each stop, because nothing gets set up at each stop.

So Docker sits oddly in a quote, usually filed under hosting. You still rent a machine to run the thing on. What changes is what gets handed to it: a sealed bundle instead of a pile of files and instructions somebody follows by hand.

Three words do most of the work. A Dockerfile is the recipe. An image is what building that recipe produces. A container is one running copy of an image.

The problem it was built to solve

Before containers, putting an application on a server meant recreating a developer's setup by hand. Install the language, the right version, the libraries, the configuration. Then do it again on the next server, and again when somebody new joined.

Every step was a chance for two machines to end up slightly different, and slightly different was enough. Code that ran on a laptop failed on the server over a library version nobody had written down. "Works on my machine" became a joke because it happened constantly.

Docker turned that setup into a file. One that gets built, checked in beside the code and reproduced exactly on demand. Nearly everything else containers are good at follows from that.

Docker was released in 2013, and containers are now an ordinary part of how applications get shipped. That matters practically rather than fashionably: whoever inherits your project next will recognise what they've been handed.

What it's genuinely good at

Repeatability, which sounds dull and is the whole value. The image that passed testing is the image that goes live, so "what's different about production" stops having an answer. Rolling back gets cheap too, because the previous image still exists and going back means running it again.

It also shortens the first day for anyone new. A developer clones the project and starts it, and the database comes up alongside it without being installed on their machine. That turns a setup checklist into a single command.

Where it stops

Containers make deployment repeatable. They don't make software good, fast or safe. A slow database query is just as slow inside a container, and packaging a badly built application means you can now deploy it reliably.

The one that catches people is that containers are disposable on purpose. A running container gets thrown away and replaced on every deploy, and whatever was written inside goes with it. Your database, your uploaded files, anything you mean to keep, all of it lives outside the container.

Then there's the layer itself, which somebody has to understand. When a page stops working, the fault could now be the code, the image, the settings passed into the container, or the network between two containers that can't see each other. That's a real skill, and it isn't the skill of writing the application.

Plenty of applications ship perfectly well without any of this. A small site on a platform that builds and runs your code for you already gets most of the repeatability, and the layer stays somebody else's problem. Containers earn their place when you want that guarantee under your own control.

Kubernetes is a separate decision, and a far bigger one

Containers on one machine are simple enough. You start them by hand, or with a short file describing a few of them running together, and plenty of businesses never need more.

Running them across many machines is different work. Something has to decide what runs where, restart whatever dies, release a new version without dropping requests, and move load when a machine disappears. Kubernetes does all of that and it's the standard tool for it, with its own vocabulary, failure modes and upgrade cycle.

It isn't the natural next step after Docker, it's a different commitment. It earns its place when traffic genuinely outgrows one machine, or when downtime during a release costs more than a cluster does. Below that, you've taken on an operations job for a problem you don't have yet. Containers make a cluster possible later anyway, so starting small doesn't close the door.

Who has to be around afterwards

None of this is technical, and it rarely appears in a proposal.

Somebody has to own the file that builds the image. It starts from a base image other people maintain, and that base gets security updates. Nothing rebuilds yours on its own, so staying current means a scheduled rebuild rather than a reaction to something going wrong.

Somebody also has to be reachable when a deploy fails at an awkward hour. On one machine that's a developer who knows the application. On a cluster it's somebody who knows the cluster.

If the honest answer to who does this in year two is that nobody has thought about it, settle that before settling the platform.