The reason for 1 container, 1 process depends upon architecting your application in such a way that it works with it. Ideally, each application thread is statel

The reason for 1 container, 1 process depends upon architecting your application in such a way that it works with it. Ideally, each application thread is stateless and independent of all others, most or all of them don't require graceful shutdown, and you can encapsulate state elsewhere in persistent volumes. If you're just using a single-node container runtime engine, it's not a huge benefit, but it does make fearless restarts a lot simpler when all you have to do is stop and start the container. Think of Erlang style crash-only programming where crashing is the only way to stop a process. When you get into multi-node orchestrators, though, then the benefit becomes much more apparent, especially at a scale where nodes are guaranteed to fail every now and again. Rescheduling to another node is then, again, as simple as launch a new container from the same image on a different node. That happens a lot faster if each container only needs to start one process. It also enables you to practice chaos engineering, which is the practice of intentionally crashing your own containers every few hours. This is a good practice for security, because if an attacker ever gains a foothold in one of your containers, they'll quickly lose it, but also to just force your infrastructure people and application architects to design in such a way that you're guaranteed to be treating servers like cattle instead of pets, because you're constantly killing them and have no choice if you want your application to still work. This ensures what you're deploying is robust and repeatable and doesn't secretly depend on some specific server state an admin achieved at 1 in the morning some random Sunday hopped up on Red Bull that he'll never remember and never be able to recreate.