Accidental complexity, essential complexity, and Kubernetes

Re:Accidental complexity, essential complexity, and Kubernetes by threeseed on Monday September 05, 2022 @05:31PM (#32729741)

With Maven, Gradle etc you can output a Docker container from a single package command.

And I don't understand this idea of using code bundles as the deployment artefact.

They don't specify how the code should be run e.g. Java version, set of SSL certificates in your keystore etc.

Do you really want Kubernetes to have hundreds of options for each language ? Or is it better to just leave that up to the user.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by anonymous_sorry on Monday September 05, 2022 @05:49PM (#32729901)

I think the suggestion is to use native Linux binaries with static linking of any libraries and resources in the executable.

Java programs would need to be compiled as a standard ELF. I think GraalVM can do this.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by threeseed on Monday September 05, 2022 @05:56PM (#32729967)

Only some Java/Scala programs can be compiled as a single binary.

It's been a concept that has been around for years but not progressing to the point where it comes close to negating the need for the JVM in a Production environment.

In the meantime containers works today and is significantly more powerful and flexible.

[ Parent | on HN ]

Re:Accidental complexity, essential complexity, and Kubernetes by krageon on Tuesday September 06, 2022 @09:53AM (#32737138)

The fallback scenario just embeds the interpreter inside of the binary. That still nets you a single binary, unless I'm missing something?

[ Parent | on HN ]