When we first started containerizing back end components a couple of years ago I spent a lot of time thinking about containers this way: how many pieces of my a

When we first started containerizing back end components a couple of years ago I spent a lot of time thinking about containers this way: how many pieces of my app should go into each container? After doing it for awhile and paying attention to evolving best practices I realized that I was looking at it wrong. Containers are not a large-granularity box into which servers are packed. They're sandboxes for processes. Individual containers have very little overhead. They are not analogous to VMs, instances, or anything at that level of abstraction. They are absolutely more analogous to chroot. So for example, in the beginning I might have created a "logging service" with logstash, redis, and kibana running in a single container. Now I would have one container for each of those processes, assembled into a pod or cluster. This becomes nearly a mandatory design pattern when you start using orchestration systems like kubernetes, because they work best and most flexibly when the lifecycle of a given container matches the lifecycle of the single process it hosts. If the process dies the container transitions out of the running state and is restarted. This gets a lot more complex and harder to reason about if the "readiness" state of the container relies on multiple processes running in its sandbox.