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.
Java programs would need to be compiled as a standard ELF. I think GraalVM can do this.
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.
As for ports, EXPOSE in a Dockerfile is basically just documentation/metadata. In practice ports are exposed at runtime (if using docker) or by configuring services (if using Kubernetes), and these are unaffected by whether a port is exposed in the dockerfile.
IMHO this is how it should be -- if I'm running a containerized database or web server, I want to be able to specify the port that the rest of the world sees it as, I don't want the container creator to decide that.
> Instead, they are used because they are a standard way of using cgroups to tightly control what pieces of the system a process has access to
Well, sure, you get both. But the point is that needing a post-build step just to get that is accidental complexity. I'm by no means a Java fan, but the way JVM gives jars as a compile target and lets you run them with some measure of isolation is an example of how things could be.