> At this point, its the same atomic unit I originally started with. Now, I have multiple executions to perform that I have to build out. This is the very definition of wasteful added complexity. The high level process is effectively identical but you have to do more things to make it work.

You have a handful of lines of dependencies to document, for example using systemd unit files. You need to do the basics once, and then reuse. What you end up with are simpler containers (no separate process monitor per container etc.) at the cost of a couple of lines of extra configuration that also happens to document a dependency. I don't see that as a net increase in complexity.

> My explicit documentation also exists in the form of a Dockerfile and my configuration files. Its a self documenting process.

It documents the dependencies of the whole container as a unit. It does not without a lot of extra effort enforce capturing the interdependencies between multiple components in the same container. This is why I like to keep the containers as small as possible.

As long as you're talking about a couple of components with few interdependencies, that's not a big deal.

But once you start piling on additional components, the complexity explodes. I once worked on a project where we were considering running round-the-clock network capture for a few days to reverse engineer the interdependencies between various components because nobody were quite sure exactly what they were any more.. That's the kind of scenarios that drives me to want to encapsulate everything as tightly as possible even if I don't need it right now - complexity has an ugly tendency to creep up on us.

> How is my container not limited exactly? Because nginx and php-fpm can access the same files? o.O I don't think this is really an argument of any kind beyond the theoretical.

As long as nginx and php-fpm are the only things installed, things remain fairly simple (see below, it seems we've had a misunderstanding). Based on that specific example, I agree it's a value judgement and not a big deal either way.

> > Versioning of e.g. system packages can evolve separately for each component, without needing separate (heavier) full vms.

> You've never seen this go wrong before in production I take it when Person X updates a component that breaks Person Y's application I take it? I have and it is not pretty. This is added complexity to manage.

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...)

> If you are storing state in an application container, it isn't a role-based container. I'm going to assume this is because I said something that was unclear.

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:

> Please explain to me how you concluded I stored state in this container

I saw your nginx+php-fpm as just one example since you earlier had written "In other words, its a really simple way to deploy X identical instances of an entire service/application." To me it's not "an entire service/application" unless you also include all the auxiliary processes, including database server and anything else the application depends on.

I was making a general point about putting an application stack in a single container, not specifically addressing your nginx+php-fpm example. Since I clearly misunderstood, we disagree much less than I thought. I'd still opt for separating php-fpm and nginx into separate containers too, but as I said above, that's a value judgement.