Containers don't remove the ops work, they relocate it
Docker earns its popularity honestly: it solves the real, common problem of a service behaving differently on a developer's laptop than it does in production. What it doesn't do is remove the operational work of running that service. Instead of patching a server, you're now managing image builds, registries, container networking and volumes, and a host that itself still needs monitoring, disk space and security updates. Treating Docker as a way to skip ops work is how container setups end up worse than what they replaced.
Where container setups actually break
The failure modes are different from bare-metal deployments, but they're just as predictable:
- Everything tagged 'latest', so there's no reliable way to know what version is actually running or roll back to a known-good one
- Volumes that were never backed up, because 'it's just a container, it's disposable' until the data inside the volume wasn't
- No resource limits set, so one container with a memory leak takes the whole host down with it
- Images built with no layer caching strategy, turning every deploy into a slow, full rebuild
- Secrets baked into image layers instead of passed in at runtime, so they end up sitting in a registry
- Disk quietly filling up with unused images, stopped containers and dangling volumes nobody's pruning
What a setup that holds up looks like
The fix for most of this is unglamorous: tag images with something meaningful (a git commit hash or semantic version, not 'latest'), set explicit memory and CPU limits on every container, back up named volumes the same way you'd back up a database, and treat image cleanup as routine maintenance rather than something that happens when the disk is already full. Health checks and restart policies, so a crashed container comes back on its own instead of silently staying down, are worth the five minutes they take to configure.
Compose is often enough
Full orchestration platforms get discussed a lot, but for a lot of businesses running a handful of services on one or two hosts, a well-maintained Docker Compose setup, version-controlled, documented, with the practices above, is genuinely enough. The complexity of a full orchestrator is worth it once you have a real scaling or multi-host problem to solve, not before.