Container Ready JVM - overview of the technologies and how to integrate them for serverless applications. Quarkus is a technology that uses JEE/Jakarta EE to deliver a runnable application. GraalVM using native takes the runnable application and compiles it natively to the host system. Using containers, like Docker, can show the benefits of the technologies when scaling.
Injustice - Developers Among Us (SciFiDevCon 2024)
Quarkus and GraalVM
1. Quarkus and GraalVM – Container Ready Java
Brian S Paskin, Senior Application Architect, R&D Services, IBM Cloud Innovations Lab
29 January 2020
WebSphere Liberty Lunch and Learn
3. Introduction
3
Quarkus is an open source project by Red Hat
A native Java stack for Kubernetes
Serverless implementation
Uses standard implementations from Java EE/Jakarta EE plus other extensions
– Does not implement all standards and implements partial standards
Small footprint
Uses less memory
Fast startup time, especially in Native mode
Unified configuration file
Hot code reloading for developers
4. Introduction
4
GraalVM is an open source project from Oracle
– Comes in two flavors, Community Edition and Enterprise Edition
Polyglot virtual machine that supports Java, JavaScript, Python, C/C++, plus others
Can be used to compile native images, binary file that runs on target machine
– native-image update is downloaded separately
– Runs on a “Substrate VM” that contains runtime components
Uses Ahead of Time (AoT) compilation for native images to start and run faster
– Moves runtime features to build time, like annotation scanning and proxy creation
Built using OpenJDK as its base
5. Why use these technologies
5
Made for containers
– Small native image size compared to application servers
– Start container images in a small amount of time compared to full application servers
– Uses less memory than straight Java application or those in application servers
Speed of startup
– Containers usually do not have changes
– Slower to compile native images, but much faster when starting
– Magnitude of times faster than using an application server
– No Bootstrap classes
– No dynamic proxies, or manually added proxies
– No reflection, or manual added reflection
Ease of use
– Java 8 and Java 11 are supported
– Live reloading for developers
– Unified configuration file
– Easy to create native image
6. Speed and Memory
6 Taken from Quarkus homepage https://quarkus.io on 30/01/2020
7. Some negatives
7
Startup speed does not equal processing speed
Does not currently implement all enterprise technologies
Not all parts of Java are supported in AoT.
Need to be aware the compatibilities between Quarkus and GraalVM
Importing other third-party libraries may not take advantage of benefits or may have issues
with native image compilation
May be harder to debug issues
8. Demo
8
Compile into a runnable jar
Execute runnable jar
Compile into native executable
Run executable
Create container and test
Create Liberty container with code
Run Liberty container
Compare differences
Download code and files
We are not talking about cheeses here, though my favorite pastry is a Quarktasche. A German pastry that is quark cheese in a baked pocket. I miss my youth in Germany. https://de.wikipedia.org/wiki/Quarktasche
Serverless implementation – an App Server/Transaction processor is not needed. SpringBoot is serverless.
Does not implement things like EJBs and does not allow reflection
Footprint is smaller compared to Springboot
Times based on most app servers, but may not be faster than OpenLiberty/Liberty
Enterprise Edition adds some features, plus has support.
Command “gu install native-image” to install GraalVM native image on local machine
Simple test with Ubuntu Linux and native image showed 100x faster with a native image compared with the same application started in WebSphere Liberty 19.0.0.9 with Java 11
Simple test with Ubuntu Linux and native image showed 100x faster with a native image compared with the same application started in WebSphere Liberty 19.0.0.9 with Java 11