A 1.5MB Java Container App? Yes you can! by Shaun Smith
Vložit
- čas přidán 11. 10. 2022
- Containers are increasing the way Java applications are packaged and deployed. There are lots of qualities desirable in a containerized application like fast startup and low memory and CPU requirements, but size and security are also important considerations. Moving big container images around a network will increase the time it takes to start up a new K8s pod or launch a container, and "just enough operating system" container images with reduced attack surface area are also preferable. So what’s the smallest possible Java container image? In this session we’ll demonstrate how to build containerized Java applications small as a mere 1.5MB! Using GraalVM Native Image ahead-of-time compilation and static linking with musl libc we can shrink down and strip out all the unnecessary bits that bloat a typical Java apps and deploy them in lightweight and security focused container images like Alpine and distroless-even scratch!
SHAUN SMITH
Shaun leads product management of GraalVM at Oracle Labs where he focuses on Java Cloud Native technologies and frameworks. He’s participated in a number of open source projects including the Fn Project, various Eclipse Foundation projects, and GraalVM. He is an experienced speaker who has presented at JavaOne/CodeOne, Devoxx, QCon, JAX, EclipseCon, and many other developer conferences and user groups around the world.
------------------------------------------------------------
INTRO
* visuals & editing by @Mercator
* music : Avocado by Ephixa - Věda a technologie
1.5MB container 🙀 pretty amazing, but also
Amazing and very expiring,
thank you!
Very informative. Thank you for the amazing talk.
This was super interesting. Thank you very much for the talk.
IT'S ALWAYS THE UNDERRATED VID THAT'S LEGIT! THANK YOU!
Great video! Thanks!
Thank you so much ❤
can this means embedded can now run containerized apps?
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.
First comment ¯\_(ツ)_/¯
¯\_(ツ)_/¯
Where is it on github ?
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.