The road to Quarkus GA: Completing the first supported Kubernetes-native Java stack

I’ve had many proud moments in my role here at Red Hat over the years. Examples include when we released the first version of WildFly, when we acquired the Camel team, when we worked with other vendors to create Eclipse MicroProfile, the great work the Strimzi team did to get into the Cloud Native Computing Foundation, our entire Red Hat Managed Integration effort, Kogito, and the list goes on. I feel like I add to this list of examples on an almost weekly basis.

Well, I can now update this list with the first product release of Quarkus, formally called the Red Hat build of Quarkus. (You can also find more support options on the Quarkus project site.) It should come as no surprise that Quarkus is on this list. I suppose what might surprise some people is that Quarkus is only just a product now. Given all of the activities since we officially launched the Quarkus project in 2019, you could be forgiven for thinking it was already a product.

Production users got us there

We’ve heard from a number of users who put it into production, including Vodafone Greece, Talkdesk, and Lufthansa Technik. There are some great quotes from these companies, too:

• Thorsten Pohl, Lufthansa Technik AVIATAR Product Owner Automation & Platform Architect: “We could run 3 times denser deployments without sacrificing availability and response times of service”.
• Roberto Cortez, Talkdesk Principal Architect: “When you adopt Quarkus, you will be productive from day one since you don’t really need to learn new technologies.”
• Christos Sotiriou, DXL technical lead at Vodafone Greece: “Quarkus seemed to provide the performance boost we needed while at the same time having a good backer (Red Hat) and relying on battle-tested technologies.”

The community got us there

Having even one great reference at this stage in the life of any open source project would be a great endorsement for the work of the project developers and their community, so to have this many for Quarkus is phenomenal. When you combine this with the amount of community interest, much of it reflected on social media platforms such as Twitter, then I think it’s fair to say that we tapped into something that no other open source project had.

Oh and let’s not forget about the awards Quarkus has won already, including The DEVIES.

Many of us, myself included, have spoken at length about what makes Quarkus different from anything else out there, so I’ll try not to repeat too much. Instead, I will jump immediately to the elephant in the room and say that what makes Quarkus special is not the fact that we compile Java. Yes, that can help to reduce execution footprint and maybe startup time, but it’s no silver bullet as we’ve found out ourselves over the years when trying compilation techniques such as GNU Compiler for Java (GCJ) and Avian. As has been described many times before and yet often gets missed, the team re-architected many of our popular projects so they worked well in Kubernetes environments—even with stock OpenJDK. That is the critical piece of the puzzle which, when coupled with compiled Java such as through GraalVM, puts Quarkus at the center of a true Kubernetes-native stack.

Through the hard work of the community, we’ve seen Quarkus used in serverless environments too, due to its ability to let applications start up and be ready to handle a request within milliseconds. Specifically, Quarkus now has support for Azure Functions and Amazon Lambda, with more integrations to come. Yes, there’s even Quarkus work around Knative. And it’s great to see other efforts, such as Camel K, coming soon in products, which will enable much of the huge Camel eco-system to be used in a serverless environment.

Quarkus GA in Red Hat Runtimes

I could go on and on about the great community involvement we’ve seen around Quarkus, the other projects and products leveraging Quarkus already such as Kogito, the benefits of now being able to run a higher density of Java applications in the cloud as well as leveraging existing Java skills, and many, many other things everyone is doing. However, this article is really meant to highlight the fact that Quarkus is now available as a supported product from Red Hat with all that this entails. Quarkus is also now part of Red Hat Runtimes, which for IBM customers is also available in IBM’s CloudPaks For Applications (CP4A). As I will discuss later, we have ensured that Quarkus works well on OpenJDK, but if you’re running on IBM’s zSeries then OpenJ9 is your JVM of choice and Quarkus works equally well there too.

The Quarkus team and community move at a blistering pace, so it’s often hard to keep up with the top new things out there. However, here are a few to consider in the Quarkus GA:

• From the start of Quarkus, we’ve always ensured that reactive programming is at the heart rather than trying to retrofit it, which rarely works well. Fortunately for us, we’ve also been involved in the leading Java framework for reactive programming, Eclipse Vert.x, for many years, and the two teams built Vert.x into Quarkus. However, recently, the two teams also collaborated on the SmallRye Mutiny project, which builds on the lessons learned from Vert.x and layers on top of it to simplify various concepts.
• Eclipse MicroProfile is a key effort for Red Hat as a whole, with us having been at the forefront of that effort since it was created. The latest and greatest version, 3.3, and associated specifications are part of this first Quarkus product.
• There are many Spring developers who are keen to embrace Quarkus and we’ve been working with many of them for a while, including Vodafone Greece, as mentioned earlier. In fact, we’ve put a lot of effort into trying to ensure that those developers can leverage their skills and applications with Quarkus, and in this release, we’ve added to that by including the ability for Quarkus applications to read configuration properties at runtime from the Spring Cloud Config Server.
• Red Hat has a rich history around messaging implementations, including HornetQ and ActiveMQ. One of the key standards we’ve been involved with since it started is OASIS AMQP, and there are a number of implementations of the standard out there, including one of our own. An important project within the AMQP community is Apache Qpid, and in the Quarkus product release, we’ve included support for the Qpid JMS adapter so your microservices can communicate using the standard.
• Anything to do with transactions, such as LRA from MicroProfile, and the Narayana project, which has been driving it.

So I hope that’s enough at the moment to illustrate how important the Quarkus product release has been. I want to conclude by once again congratulating the entire Quarkus product team and community. Whether you’ve been working on core Quarkus capabilities, submitting feature requests, or writing blogs about your experiences in using it, you’ve helped get the world’s first Kube-native Java stack from project to product. Take a well-earned bow!