There is a balance to be struck between reusable layers in container image vs a single small blob which is not reusable. If you are trying to optimize for total storage space and network io for 100s of Java app container images then buildpacks built containers would be more efficient. Put another way, for your company's internal apps, which can all use a homogeneous stack, buildpacks based approach is better suited.
Container images are layered. If a particular layer is present in multiple images, it is stored on disk just once. When you are pulling a container image from remote registry, the registry first sends the list of layers in that image along with their hash. Based on the hash, you know which layers you already have and only download the layers you don't have. In a company, you typically have many variants of the same app (different versions with slight difference) and different apps with similar stack. In both bases there is a huge opportunity for layer reuse. The OS and JVM layer can be same across all apps. The Library layer would be different across apps but it does not change very often across different versions of the same app. So that leaves just classes layer which changes across app versions. The classes layer is very small anyway. So when pulling a new version of an image you are only spending storage and network I/O for the classes layer which is very small - few KBs to single digit MBs On the other hand, with Graal VM, JVM + lib + user code is all condensed into blob of several 10s of MBs. This blob is going to have a different hash for slightest of change. Hence, the blob layer cannot be reused. If you have CI/CD, every commit is going to cost several 10s of MB of storage in the container registry. For this reason, optimizing for size of individual container image is short sighted.
A few kb hello world in a language that compiles to a certain arquiteture is not hard. A few mb in java that runs in java virtual machine which runs in a container is pretty amazing. When you see that a small contained s.o. usually is 80 mb, you can see why this is an achievement.
@@RonaldoTalison Nah its still a hello world app no matter how you sees it. It will be bloated once they add deps into it. You can sugar coated it as much as you want but no sane dev will use it as a comparison in real world apps measurement its just useless.
The problem is that you have a big java ecosystem, and now you have a special need to create a small container (function as a service or something like that). If you have Java developers, working with java, and using with nice java libraries doing real stuff then you will not create a C program to access this java library. But this is only needed for some special cases. Most of the time you start java once, give it many cores, big memory and it runs, faster and faster. BTW: I would choose "go" over "C" when in need of something simple and with small footprint. No need to use a language that is just a syntax sugar for assembler (I mean C).
Gazillion of lines of code has been written for big businesses. They won't invest money because another language is better. There is always something better. So Java evolves with time.
1.5MB container 🙀 pretty amazing, but also
Very informative. Thank you for the amazing talk.
This was super interesting. Thank you very much for the talk.
Amazing and very expiring,
thank you!
IT'S ALWAYS THE UNDERRATED VID THAT'S LEGIT! THANK YOU!
Great video! Thanks!
can this means embedded can now run containerized apps?
Thank you so much ❤
Nice intro!
There is a balance to be struck between reusable layers in container image vs a single small blob which is not reusable. If you are trying to optimize for total storage space and network io for 100s of Java app container images then buildpacks built containers would be more efficient. Put another way, for your company's internal apps, which can all use a homogeneous stack, buildpacks based approach is better suited.
Container images are layered. If a particular layer is present in multiple images, it is stored on disk just once. When you are pulling a container image from remote registry, the registry first sends the list of layers in that image along with their hash. Based on the hash, you know which layers you already have and only download the layers you don't have.
In a company, you typically have many variants of the same app (different versions with slight difference) and different apps with similar stack. In both bases there is a huge opportunity for layer reuse. The OS and JVM layer can be same across all apps. The Library layer would be different across apps but it does not change very often across different versions of the same app. So that leaves just classes layer which changes across app versions. The classes layer is very small anyway. So when pulling a new version of an image you are only spending storage and network I/O for the classes layer which is very small - few KBs to single digit MBs
On the other hand, with Graal VM, JVM + lib + user code is all condensed into blob of several 10s of MBs. This blob is going to have a different hash for slightest of change. Hence, the blob layer cannot be reused. If you have CI/CD, every commit is going to cost several 10s of MB of storage in the container registry.
For this reason, optimizing for size of individual container image is short sighted.
👌 👏
Years ago hello world app size no more than a few KB 😁
Yet they feels like they reach holy grail of coding here 😁
A few kb hello world in a language that compiles to a certain arquiteture is not hard. A few mb in java that runs in java virtual machine which runs in a container is pretty amazing. When you see that a small contained s.o. usually is 80 mb, you can see why this is an achievement.
@@RonaldoTalison Nah its still a hello world app no matter how you sees it.
It will be bloated once they add deps into it. You can sugar coated it as much as you want but no sane dev will use it as a comparison in real world apps measurement its just useless.
What is the problem with C, I’m not a C developer but all these optimizations can be done just with GCC capabilities …
The problem is that you have a big java ecosystem, and now you have a special need to create a small container (function as a service or something like that). If you have Java developers, working with java, and using with nice java libraries doing real stuff then you will not create a C program to access this java library. But this is only needed for some special cases. Most of the time you start java once, give it many cores, big memory and it runs, faster and faster.
BTW: I would choose "go" over "C" when in need of something simple and with small footprint. No need to use a language that is just a syntax sugar for assembler (I mean C).
The problem with C is that it's a much worse language than Java for high-level applications
Gazillion of lines of code has been written for big businesses. They won't invest money because another language is better. There is always something better. So Java evolves with time.
C was too OP. They had to invent bloat to then debloat over time making you think things were getting faster.
Where is it on github ?
First comment ¯\_(ツ)_/¯
¯\_(ツ)_/¯
nice speech but i havent got graalvm working on any of my machine.... pretty useless ....
Use docker. That's the easiest way to get these running.