> I can grantee 99% of projects using docker or any sort of containerization are wasting 99% of compute resources.

Genuine question: where would this overhead come from?

I've used Docker (I know, Podman is supposedly better in some regards) for a while now on Windows for local development (Hyper-V back end) and on my servers (*nix boxes) and I haven't seen that many issues, even with something like Docker Swarm or Hashicorp Nomad for orchestration.

I have, however, heard and/or experienced bad things in regards to:

- disk I/O performance on Windows locally (WSL2 back end was slow for me, vice versa for others)
- disk I/O performance on Mac
- anything to do with Windows containers
- the resource usage of Kubernetes (K3s, K0s, microk8s can help work around this, but not wholly; this might be the piece of software with the highest overhead in many stacks out there, if people go ahead and use it)

Or are you referring to something else?

Because frankly, a while back in my homelab I tried running a separate VM per project (not even per app) and at around 10 of those my disk I/O was so crippled the whole system was unusable - that might have been because the VMs were running full Debian instances and I had HDDs instead of SSDs (hey, I'm poor), as opposed to running somewhat cut down containers based on Debian or whatever (<40 PIDs).

In contrast, containers have generally been pretty decent, especially because I can indicate CPU/RAM limits more easily than I otherwise could with systemd slices, which is helpful when something like MySQL decides that it would like to eat all of your RAM, or you need multiple MySQL instances on the same node for testing or different apps or whatever.

My experience so far is that containers largely hold true to the promise of allowing an increased density without doing something a bit more shady like running one large MySQL instance with multiple users/DBs (the same would apply to PostgreSQL or any other "common" piece of multi-tenant software), which in practice makes debugging and updating everything a painful mess.

I will concede that it's also a matter of ways of thinking about software, centralized vs decentralized (not even distributed systems per se) and all that.

> Just waiting for those low skilled people to reply how wonderful docker is and to say "if its not working you are not doing it right"

Bringing up the "No true Scotsman" argument ahead of the time is probably a good idea, but also makes this sound like something that's supposed to dismiss anyone who might have had different experiences from yours, which doesn't feel in good faith.

I can see why running certain containers (e.g. anything built on Oracle Linux or other heavyweight base images for whatever reason) might coincide with large images and sluggish performance, or containers that have full init systems inside of them etc. The disk I/O issues on dev boxes should also need to be taken into account, of course.

But in general, they seem "good enough" and I find it hard to believe the 99% figure. Maybe that's a broad statement/joke, not sure.

Disclaimer: I've run software directly in the past, have used systemd (which I actually find passable, contrary to the seemingly popular belief), sysvinit, OpenRC, as well as have deployed it with Ansible. The learning curves of all those aside, I feel like software can run well with either approach, but I haven't run into that many issues with containers either. They do feel like a simplified init system that gives you lots of stuff out of the box and reduce thinking about your services as apps on a phone (standardized packages, common ways to configure etc.). Except for Kubernetes: most people out there don't need it, though I can understand why enterprises would go for it and have used it with varying success in the past.

I'm also curious about how the people here feel about Vagrant and Packer, if you've any opinions on those.