> As long as you're talking about a couple of components with few interdependencies, that's not a big deal. To me that is what a role based container is. Admit

> As long as you're talking about a couple of components with few interdependencies, that's not a big deal. To me that is what a role based container is. Admittedly, sometimes I package an entire one-off service inside a container to make it easy to do dev work...but not in production. > I store the state in separate volumes, but the database server process still needs to run somewhere. But it does seem that we've been talking past each other. My impression was that you were advocating keeping the full stack in a container: Okay so we'll chock this one up to my shitty communication skills. :) > I've seen that many, many times. This is complexity that largely goes away when you enforce a fine grained split into containers that are built and tested as a full unit. It's exactly because I've managed systems with 100+ VM's where people have had conflicting needs for upgrades that I love being able to encapsulate each component separately, so the developers gets the freedom to make decisions about even core system packages without stepping on each others toes (as long as the developers working on a specific component can agree, anyway...) I think we'll have to chock it up to different experiences and meaning different things when we write stuff down. I see that problem happening when you do what you are doing and enable people to make those special snowflake VMs because of conflicting requirements. The technically integrate correctly until you get an edgecase bug that was fixed in one and not the other.