News for hackers. Stuff that matters.

A comment on Accidental complexity, essential complexity, and Kubernetes. Parent comment

Re:Accidental complexity, essential complexity, and Kubernetes by candiddevmike on Monday September 05, 2022 @05:47PM (#32729877)
Everything already is running on the same operating system with Kubernetes where it matters (kernel, runc/crun, etc). Containers are a band aid to wrap an app with additional files/libraries/whatever. In Go for instance, I can include all this stuff at compile time (even conditionally!).

I'd love to see Kubernetes be able to schedule executables directly without using containers by way of systemd nspawn or similar. You could have the "container feel" without the complexity of the tool chain required to build/deploy/run/validate containers.

[ Parent | on HN ]
Re:Accidental complexity, essential complexity, and Kubernetes by samus on Tuesday September 06, 2022 @02:08AM (#32733510)
The tool chain to build/deploy/run/validate is the whole point to containers. It's something that unifies the deployment model of applications, unless you want to commit to a single programming language ecosystem. And not every ecosystem has tools to create a monolithic deployment artifact.

Even if you have monolithic deployment artifacts: by the time you have solved all the use cases that the image distribution workflow cover, you have basically reverse-engineered it. If you have already done that, kudos to you, you indeed don't need that workflow. And you probably will find it very easy to containerise those artifacts should you ever need to.

[ Parent | on HN ]