The open-source Quarkus project, led by Red Hat, is an attempt to bring the Java stack to the cloud and Kubernetes-based deployments. The project has steadily progressed since its start in March, leading up to the upcoming Quarkus 1.0 stable release. The first release candidate for Quarkus 1.0 came out on Nov. 6, with developers expecting a final release within the next two weeks.
"With Quarkus, Java developers are able to continue to work in Java, the language they are proficient in, even when they are working with new, cloud-native technologies," John Clingan, senior principal product manager of middleware at Red Hat, told IT Pro Today. "With memory utilization measured in 10s of MB and startup time measured in 10s of milliseconds, Quarkus enables organizations to continue with their significant Java investments for both microservices and serverless."
Many organizations have been considering alternative runtimes to Java, like Node.js and Go, due to high memory utilization of Java applications, according to Clingan. In addition, Java’s startup times are generally too slow to be an effective solution for serverless environments. As such, Clingan said that even if an organization decided to stick with Java for microservices, it would be forced to switch to an alternative runtime for serverless, or functions-as-a-service (FaaS), deployment.
Quarkus is an open-source project that is licensed under version 2.0 of the Apache License. The project currently has 177 contributors, both from inside Red Hat and outside Red Hat.
By moving as much of its dynamic behavior as possible to ahead-of-time (AOT) compilation the Quarkus application stack is optimized for container, Kubernetes and serverless, Clingan said.
"Quarkus is, in many ways, a framework that helps other frameworks do AOT for runtime efficiency, like Eclipse MicroProfile, Eclipse Vert.x, Spring and Kafka client APIs," he said. "However, it also does a whole lot more, like combining reactive and imperative programming and delivering an improved developer experience via live coding."
One of the integrated components of Quarkus is the Vert.x project, which is a popular toolkit for building reactive applications. Quarkus integrates Vert.x to implement different reactive features, such as asynchronous message passing and non-blocking HTTP clients.
"In this way, Quarkus uses Vert.x as its reactive engine, so while many of the reactive features from Quarkus don’t show Vert.x, it's used underneath," Clingan said. "What is unique about Quarkus is that it unifies the HTTP stack, so Vert.x asynchronous APIs can be used alongside traditional JAX-RS [Java API for RESTful Web Services] APIs in the same app in a highly optimized, efficient and consistent manner."
Running Java Apps with Quarkus
There are multiple ways that Java applications can be deployed into a cloud-native environment with Quarkus. Clingan explained that Quarkus apps can be deployed on the Java Virtual Machine (JVM) just like any other Java app would. In JVM mode, it would be a JVM per container pod. When running on the JVM, users will see significant memory and startup time savings when compared to traditional cloud-native Java stacks, he said.
"Quarkus apps can also be compiled to a native binary using GraalVM’s SubstrateVM, in which case a JVM is not required," Clingan said. "The memory benefits and optimizations that apply to the JVM mode also apply here, with the additional benefit of native compilation."
JVM deployments are recommended when single JVM speed and throughput is required or it is a long-lived application. Native images are recommended when memory density or startup time like in serverless environments is important. Either way, Clingan emphasized that either mode of Quarkus deployment is more efficient than a traditional stack.
Looking forward, Quarkus could well become a core element of bringing Java applications into cloud-native environments in a supported way.
"At this time, Quarkus is still a community project, though we do intend to commercially support it," he said.