Hacker News new | past | comments | ask | show | jobs | submit login

Cloud technology is so bad. Just run your programs as normal processes. No bloated images and runtimes, no slow virtual bridging layers, no barriers preventing you to access the hardware or communicating with the user.

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.




I disagree. While there are bloated images and runtimes, at least they are separate.

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.


Dockerized delivery starts easy unless you realize you need a new container for every small thing you need to run, and you end up with a pile of containers a short while later.

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.


But the update problem is also present on direct installs. It's is less bad on Docker.

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.


Direct installs have auto update, though, so they may update A and B separately and will often update them along with bundled dependencies.

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.


Well you need to do that anyway if you are indeed building those applications.


I think what you really want to say is your last sentence:

> It's also all simple and straightforward

What you're really trying to say is that cloud technologies are complicated for you.


You must be really young if you do not understand that aversion to complexity is likely a single best trait a developer may have.


Spoken like someone who's never done Linux sysadmin at scale.


I've done hundreds of nodes, all managed to a very low level (I've been to the datacenter and optimized placement of servers within the cabinet to enable shorter cables to the patch panel) which is way beyond what most companies need.

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.


choosing serverplacement to optimize for cable length does not sound very efficient. usually you get the cables in the length you need and place servers to solve other requirements (heat, direct connections between devices, etc)

> 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


hundreds! my stars! so many!

> as shared instances just don't work well and aren't cost-effective.

goodness you are outing yourself here aren't you


If anything it's the opposite.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: