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