Red Hat’s Quarkus Brings Natively Compiled Java to Kubernetes
In a time when everyone is talking about the latest languages out there, it can be easy to forget that Java is still king in the world of enterprise applications. Java has sat in the top percentages of most language rankings for years and has yet to show much any sign of moving, so of course, an effort to bring Java into the modern microservices software architecture is an exciting next step for many. This is exactly what Red Hat has done over the last year with its work on Quarkus, a “Kubernetes native Java framework” released earlier this year that compiles Java down to a native executable to reduce runtime memory requirements and boot time.
In a blog post introducing the new framework, Mark Little, Vice President of Engineering at Red Hat and JBoss Middleware chief technology officer, highlights the dominance of Java in the enterprise and the investment in it as primary reasons for offering a better way to containerize Java.
“It’s important to remember that Java remains the number 1 programming language for enterprise developers working on the backend and many organisations have invested a lot of time and money into their Java-based developer organisations and software because it has dominated the software landscape for so many years,” wrote Little. “Being able to continue to leverage those things as they transition to the cloud is therefore incredibly important for this huge community. But concerns about Java (performance, runtime memory footprint, boot time etc.) have caused some to re-evaluate their investment with Java and consider some of the newer languages, despite the fact many of those languages don’t yet have the rich ecosystem of tools, utilities etc. which have been built up over the years by the Java community.”
In an interview with The New Stack, Little agreed that calling Quarkus a “framework” may be a bit of a misnomer, but went on to explain how the tool brings Java to Kubernetes.
“It is more than a framework. The term has been used incorrectly. It’s a lot more than just a shim or a thin layer on top of other things,” said Little. “There’s this new effort called Graal and Substrate that allows you to compile Java down to a native executable, much like you’d get from C, C++ or Go. Java is build once, run anywhere with JVM. If you compile to native, you throw that out the window. Typically the containers Kubernetes are managing are Linux based. It’s not so much of a disadvantage to compile to Linux. It’ll work on most every Kubernetes out there. You get much smaller images, which has a dramatic effect on startup time. For environments like serverless, where you might do real time reactive, being able to spin up a Java program in a few milliseconds based on an event shifts the goal posts. In the past you had to think about doing this in seconds.”
Quarkus not only reduces size and boot time, meaning you can essentially cram more Java applications into a single container, but also acts “as the glue between everything” such as all the services provided by Kubernetes. While Little said he wanted to emphasize that native compilation wasn’t a requirement, he also noted that Quarkus makes it much easier to do than before, allowing developers to enjoy these other benefits.
“If you want to go down this immutable approach, you have to make some changes. One of the things we did with Quarkus was try come up with a tool or core component that enables developers to embrace immutability without having to worry about the low-level details that Graal and Substrate impose on you,” said Little. “If you try without Quarkus, you can but it’s very hard to do it right.”
Mario Fusco, a Drools core developer at Red Hat, offers a blog post on how they turned a 13-year-old Java project into a first-class serverless component. In it, he writes that their main goal was to “make the core of the rule engine lighter, isolated, easily portable across different platforms, and well-suited to run in a container,” which they turned to GraalVM for, before eventually landing on Quarkus to complete the task.
The use case exemplifies the scenario offered by Little as a primary reason for building Quarkus in the first place.
“We’ve been contacted by a number of customers who were getting pressure to move away from Java to Golang or Javascript, because of the potentially rapid cadence of releases associated with them over Java,” said Little. “This has made them step back and think that maybe boot time and memory footprint isn’t an issue with Java. They can leverage the 15 years of Java experience they already have instead of moving to a new language.”
