Containers

As I’ve noted in earlier posts, containers predate Kubernetes. Docker brought them into the mainstream by making image build and runtime management almost trivial. For a development team the first obvious win was reproducibility – build an image once and run it on a developer laptop, a CI runner, or a production node without changing a line of code. The “works on my machine” problem simply went away. But once you start running dozens or hundreds of containers, the question becomes: how do you schedule them, monitor them, network them and recover from failures? That is the problem Kubernetes solves.

TL;DR

Dev containers turn a complex setup guide into code and give every person the same working environment. They help when your project is not simple, when people use different operating systems, or when you fight works on my machine bugs. They can slow things down and add extra upkeep if the project is already easy to run. Use them only when they remove real pain.