The hardware has finite resources, and the best way to share them is to run things natively on the operating system.
It's also all simple and straightforward, everyone understands ssh and simple Linux sysadmin.
Unfortunately most applications are developed in a way that they believe they are the only one on the system. Ruby gets called, and they expect 2.7.
And there is another one which is using Ruby 3.2. And it's incompatible with 2.7.
Now what? Do you want to spend time
- maintaining 2 versions of ruby on a system
- keeping them separate
- ensuring they don't mix up
OR
Shove them in a container, run them in parallel and all they surface is a port.
I'll take the container.
Docker containers, in my experience, have not figured out auto updates yet. You may be running containers with critical system vulnerabilities and is not bothered to check.
So the basic premise of Dockerization 1.0, "I have exactly one thing which I will put in a single container with all of its dependencies, reproducibly built" is wrong.
Example: 2 containers which rely ffmpeg, and there's a vulnerability in ffmpeg.
But container A can't update cause ffmpeg's update breaks something else...
At least with Docker you can update container B, and maybe isolate A.
On a direct install ffmpeg is a shared component. So now both apps are locked to a vulnerable version.
Not to mention that shared components are often outdated for the sake of stability.
So App A is restricted to the same version as App B, even though App A would like version 9, and B is on 8.
In the Docker scenario, it's quite often that neither A nor B will be updated for a long time, since there's no mechanism to do so.
> It's also all simple and straightforward
What you're really trying to say is that cloud technologies are complicated for you.
In general it's better to have fewer and more powerful and reliable nodes that you own than to have many disposable small ones, as shared instances just don't work well and aren't cost-effective.
Cloud in general just makes everything more expensive while removing control. The costs on AWS if paying for three years upfront is the same as buying the hardware outright, except you have little say in what the hardware is and how the infrastructure is set up.
> as shared instances just don't work well and aren't cost-effective
of course ymmv from mine, but this statement being true or false depends on too many things to be of any value
> as shared instances just don't work well and aren't cost-effective.
goodness you are outing yourself here aren't you