Hello Quarkus: Supersonic Subatomic Java
Hello World. In this article let’s understand the basics of a new addition to Java family. Quarkus, a Cloud Native, (Linux) container first framework for writing Java applications is grabbing a lot of attention these days. The idea behind building such product is more than interesting for future enterprise Java applications.
Java was introduced to software realm around 25 years ago, and it still remains one of the most preferred programming languages for building enterprise applications. However for many, java is not a suitable fit for building cloud native applications, but with the introduction of Quarkus, that issue is also somewhat resolved. Quarkus provides java developers with the traditional look and feel of a java application with added benefits of Hot Deployment, IDE plugins, unified configuration and many more.
Why Java Suffers in Cloud Native World?
Most of the organizations are diverting from a traditional monolithic architecture to a microservice based architecture. While having many pros of following this trend there are certain drawbacks as well. The microservices are bundled into fat jars and then these are run into containers which require additional memory to operate and that can be troublesome. To solve this issue many organizations are focusing towards Serverless and FaaS because they allow developers to focus on writing functions rather then focusing on infrastructure. The added advantage here is that after certain time, the cloud provider will destroy completely the container and start it again on the next call, so you only pay for the usage. Here, allow me to explain the concept of cold start where the first call to the function might take more time because container needs time to boot up. Also, what we as software developers don’t want is multiple threads, long running processes that takes a hell lot of time and are hard to debug. Considering this, we can come to a conclusion that the traditional approach we were following was not the most appropriate one. Well, no need of reinventing the wheel here, as our good friends at Red Hat already had thought of this problem way before and now they are offering us a solution named Quarkus.
The main objective behind Quarkus is to reduce the start-up time of applications and their memory footprint and also provide what is called as developer joy. To fulfill these objectives Quarkus offers the phenomena of Hot Reload and Native Compilation.
Hot Reload:
All the spring boot developers can relate to pain here that to reflect changes we have made into our application, we have to launch compilation and restart it from scratch. But with quarkus we have the concept of hot reload wherein changes made to Java files or to configuration files will automatically be compiled once the browser is refreshed.
Native Compilation:
The boot time and memory footprint of traditional java application is reduced by 99% and 86% respectively using native compilation provided by GraalVM. It is a polyglot VM which allows to run applications written in JVM-based languages like Java, Scala or Kotlin and other languages like JavaScript, Python, Ruby, R. The advantage of using GraalVM is that it allows us to compile our programs ahead-of-time(AOT) into a standalone executable, called a native image. Once we compile a JVM application into a native executable, it can run without a JVM.
Let’s understand the memory management using an example, let’s say you have a microservice architecture comprising of five microservices. For running a typical bundled jar file you need to setup JDK in each of the microservice. Rough estimated disk space required for JDK is 250MB, so for setting up JDK in 5microservices, you need 1250MB disk space.
Okay, time to do some comparisons. Let’s compare Spring boot and Quarkus on memory footprints and startup time.
Memory Footprint:
In computing, the memory footprint of a software application indicates its runtime memory requirements, while the program executes(source- Wikipedia). So for a single core machine there is a drastic difference between Quarkus with Native binary, Quarkus with JVM and Traditional Cloud Native stack.
Startup Time:
The startup time is measured as the time difference between the program start and when the program is ready to take requests(source- RedHat). Based on numbers, a native binary created via GraalVM is 99.62% faster then traditional cloud native stack(Crazy, isn’t it).
Java has been there from almost last 25 years dominating the industry, but we are in an era dominated by AI, cloud, open source where development of cloud native applications is highly necessary to deliver high levels of efficiency. Java along with quarkus can give a tough competition to other languages which are compiled natively. I highly recommend it and hope that you would give it a try.
