GraalVM-Native Images & Microframeworks.
In this article, we will be talking about GraalVM, native images & micro-frameworks, why we need them, what are the potential use cases, and how they can help us embark on our application modernization journey.
As we look back into the IT (Information Technology) architecture evolution cycle, we started our journey with mainframes, gradually started moving towards monolith, followed by microservices adoption to overcome the limitations of respective architecture around non-functional requirements and eventually leading to loosely coupled architecture.
With the recent evolution of serverless platforms, there is a great need to analyze our existing microservices-based workloads for serverless architecture adoption. This is where GraalVM and native images shine in with fast boot-up time and low memory footprints.
Challenges with Legacy Architecture
As we know, a monolith application is a tightly coupled system with the relevant modules packaged together as a single deployable executable. These systems start to grow over time to meet business needs. At some point, as we start adding new features, a monolithic application begins to suffer from various problems like scalability under massive load scenarios, latency, fault tolerance, handling asynchronicity, etc.
To meet these challenges, we started replacing monoliths with microservices, making the system loosely coupled, but it added a great deal of complexity for the gains.
And as we move from micro-services to serverless, the code blocks become smaller and simpler, reducing cost while the total complexity grows.
The below diagram depicts this scenario…
3factor Architecture & Serverless Functions
3factor app is an architecture pattern to create modern apps with serverless architecture in mind.
This pattern enables us to build apps that are robust and scalable by using ‘Function as a service, along with the power of the Cloud. And ‘Function as a service is where the GraalVM shines with impressive performance metrics.
The below diagram depicts this scenario…
GraalVM Overview
Let's do a high-level overview of GraalVM…
GraalVM is a high-performance JDK (Java Development Kit) distribution designed to accelerate the execution of applications written in Java and other JVM (Java Virtual Machine) languages along with support for JavaScript, Ruby, Python, and several other popular languages. — graalvm.org
Key features of GraalVM:
HotSpot VM vs GraalVM
As GraalVM is a high-performance JDK (Java Development Kit) distribution, let us do a quick comparison with Hotspot VM and GraalVM.
GraalVM compiler is built on JVMCI, and provides a better JIT (Just In Time) compiler implementation, with further optimizations. It also provides an AOT (Ahead Of Time) option, where we can create a standalone, machine code directly.
Looking at the below diagram, we can see the Compiler interface has been replaced with the JVM Compiler interface and the C2 compiler is being replaced by the GraalVM compiler. Both are written in Java and provide better optimization over existing Hotspot VM.
JIT vs AOT
Let’s understand JIT (Just In Time) and AOT (Ahead Of Time) compilation methods and the concept of native images.
If you are familiar with the Java ecosystem, you can relate to JIT (Just In Time) with the traditional java compilation process. Java code is being compiled to bytecode first and later processed for JVM (Java Virtual Machine) interpreter for machine code conversion. C1 and C2 further optimize the code based on the profiling algorithm.
AOT (Ahead Of Time) is a process of compiling these workloads to native images. We gain faster boot-up time and low memory footprint with AOT but lose the portability aspect.
By running the existing workloads with JIT on GraalVM, you can expect better performance. And, to the benefits of GraalVM (faster boot-up time and low memory footprints), use native images with AOT compilations that are more suited for serverless use-cases.
For Serverless — it makes more sense to go towards AOT, while for long-running container-based/VM-based deployments, JIT might make more sense.
The below diagram depicts the comparison…
GraalVM Architecture
GraalVM adds an advanced just-in-time (JIT) optimizing compiler, which is written in Java, to the HotSpot Java Virtual Machine.
In addition to running Java and JVM-based languages, GraalVM’s language implementation framework (Truffle) makes it possible to run JavaScript, Ruby, Python, and several other popular languages on the JVM. With GraalVM Truffle, Java and other supported languages can directly interoperate with each other and pass data back and forth in the same memory space. — graalvm.org
GraalVM Performance Graph
Memory footprints are ~5x lower and startup time is ~50x faster with various microframeworks using GraalVM native images than Hotspot VM mode.
Helidon, Micronaut, and Quarkus are microframeworks, we will talk about them in the next section.
Pros & Cons of GraalVM
Pros:
- Faster Startup
- Lower Memory Footprint
- Native-Image
- High Performance
- Language Interoperability & Polyglot Tooling
Cons:
- No JVMTI, Java Agents, JMX, or JFR support
- Efficient only for smaller heap
- Generated native code is not fully efficient
- No thread dump and heap dump support
- No Dynamic class Loading / Unloading
Microframeworks for GraalVM
A microframework is a term used to refer to minimalistic web application frameworks. It is contrasted with full-stack frameworks. - wikipedia.org
Helidon, Micronaut, Quarkus, Javalin, and Spring Native are the best-known microframeworks for the GraalVM ecosystem.
With the AOT feature of GraalVM, we can create native images with these microframeworks and achieve performance gains.
All these frameworks have container support and can be deployed on serverless platforms like ‘Knative’ or ‘AWS Lambda’.
Microservices Frameworks Comparison
This is the last section that talks about the comparison between microservice frameworks.
Before we jump to that let's quickly talk about MicroProfile.
MicroProfile is a community-driven specification designed to provide a baseline platform definition that optimizes the Enterprise Java for microservices architecture and delivers application portability across multiple MicroProfile runtimes, including Open Liberty. — microprofile.io
A full-stack framework like spring boot provides a lot of flexibility with external dependencies and integration aspects but are heavy as compared to other.
MicroProfile-based frameworks provide particularly good optimization over the full stack, are less heavy, and adhere to MicroProfile specifications. This framework optimizes the Enterprise Java for microservices architecture.
And microframeworks are lightweight with faster boot-up time, lower memory footprint, and a great fit for serverless architecture use-case (Function as a Service).
Conclusion
With the evolution of IT (Information Technology) Architecture, code blocks are becoming leaner and simpler, and adoption of loosely coupled systems is catching up, but overall complexity is growing. To meet growing complexity needs and reduce overall cost, there are great opportunities to adopt event-driven architecture and find the potential use-cases for serverless architecture.
With GraalVM and native images, we can further optimize our serverless workloads and reap the benefits of faster boot time and low memory footprints, eventually leading to effective cost optimization.
And it the high time to re-evaluate our semi-modernized workloads, find the potential uses-case and start adopting MicroProfile base frameworks and Microframeworks using GraalVM.
Do let me know what you think about the GraalVM…
Thanks for reading!
