[jve]

Docker actually helps managing complexity, by putting bits and pieces, scattered on the floor and putting them into a single cardboard box.

- If you throw the box out, you know you did no harm to other boxes.

- If you change your floor, you know you didn't wipe out something useful.

- Aaand you can `git switch` to a well known state

Ofcourse it's not 100% like that, in reality you still have to have some kind of consistency on where you put your docker-compose file, Dockerfiles for all the boxes, where you mount your volumes (in some folder or scattered all over system), maybe dealing with host firewall, dealing with not-commiting secrets into git etc.

But overall, it's very positive - docker-compose is (almost) one-stop file you need to see all your references to volumes, Dockerfile, network configurations, environment files with secrets.

[markstos]

Containers help tame complexity, but the container itself could be run without the docker runtime, using systemd-nspawn, or run as a regular systemd service using podman.

It seems less complex to manage a bunch of systemd services than one pile of systemd services that are managed and logged one way and bunch of docker services that are managed and logged another way.

[solarkraft]

Deviation from standards is what I find to cause a lot (the most?) of problems. Complexity generally makes things more error-prone, but it tends to become less of a problem when in a well maintained system a lot of people use (someone, maybe yourself, has already had and solved a problem you're having).

If your standard is dealing with systemd units, it may make sense to make your containers conform to that (thereby deviating from the most common way of managing containers). Maybe it's what I'd do in a larger operation. For my personal use I find it the most pragmatic to just use Docker since it's reasonably well documented, has reasonably low friction in usage and is very easy to set up.

[markstos]

Agreed. When I'm picking "the right tool for the job", something I factor in what are the tools and languages my team knows. If my team knows JavaScript, I'm going to weigh that when I'm choosing the choice of coding languages for the next project.

[_ea1k]

Exactly, you get many of the benefits of separate boxes without some of the added complexity. Docker and containers in general can reduce complexity significantly in a lot of cases.

[dncornholio]

What you are saying is actual complexity. A box can be a machine instead of container and all your points will still stand but with less complexity.

[jve]

Perhaps, if we talk about deployent.

Howevre looking at the whole chain of process:

I can deploy service/app on my local machine, including dependencies, along with other independent services/apps.

So, I can reuse what I have for production. But ofcourse, local development stuff will have different env variables, some docker-compose etc.

But it is a joy, when you can:

1. git clone something

2. set some env variables

3. docker-compose up -d

And your app, along with database, elasticsearch, whatnot - is running

So for development purposes it really helps. For deployment purposes - if that box is dedicated to something, then yeah, many of the good use cases not necessary.

[solarkraft]

Having all of your services in the same box opens you up to a ton of possible unwanted cross-interaction, which is complexity.

(just not from the system perspective, but from the "reasoning about it" perspective)