Once you have a hammer… One advantage of software containers is to have this unique interface that is the same whatever is inside the container. Like shipping containers.
If it's one single golang binary, or a weird python container running only on specific version of Debian compiled during a blue moon, or some 8GB java enterprise bloatware, it's the same.
"or a weird python container running only on specific version of Debian compiled during a blue moon"
This.
I guess I've been fortunate that I'm able to reject software like this from my stack. I know that everyone isn't so lucky.
I mostly do nodejs, and have zero need for containers when a simple npm install gets all deps.
Or if I need performance, a single go binary.
I tried doing the container thing just to understand how it all works and what the hype is about.
It seemed needlessly complex and hard to develop/debug.
For more complex situations where you need a bunch of interacting programs and services, I prefer stuff like Ansible and VMs, or just manually setting up a base image.
I guess it's a "get off my lawn" kind of thing. It seems like containers are used a lot by folks who don't want to learn ops, like how to install and configure postgres, redis, etc...
I think that's a mistake, and just pushes the problem onto others who have to support the software in production.
If it's one single golang binary, or a weird python container running only on specific version of Debian compiled during a blue moon, or some 8GB java enterprise bloatware, it's the same.