Quarkus deconstructed: building modernized Java for the future

Quarkus is driving Java-based applications and services into the future. More specifically, the Quarkus framework is helping to drive Java-coded assets into a future that is positively populated with the computing advantages that come from the use of serverless, cloud and Kubernetes environments.

If you had to deliver a 2-floor ‘elevator sell’ for Quarkus, you’d say that it’s a Kubernetes-native Java stack. If you had more breathing space and time for a 5-floor elevator sell, you could say that it’s a Kubernetes-native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from best-of-breed Java libraries and standards to drive modern Java applications to the container-centric cloud.

SEE ALSO: Modernizing application development with serverless and Quarkus

Now a part of Red Hat Runtimes (a set of products, tools and components for developing and maintaining cloud-native applications) and enjoying its first stable development release from July 2020, Quarkus is patently open source and functionally rudimentary in its construction and implementation, in that it offers a small memory footprint and reduced boot time.

As a full-stack technology, Quarkus works at both the server-side level and client user application level. It is a Kubernetes-native Java framework made for Java virtual machines (JVMs), so it provides a means of programming virtualised application components in Java that will use the advantages of the open source Kubernetes container orchestration system.

In terms of core functionality, Quarkus natively compiles and optimises Java code specifically for containers. This is why it is an effective platform for the abstracted computing world of serverless, cloud and Kubernetes environments.

But at another level, Quarkus also optimises non-compiled Java stacks, meaning that developers will still get performance improvements, even when using it with OpenJDK i.e. not compiled, which – essentially – is of course the dominant way that Java has been written for many years.

Easy configuration for developer enjoyment

If not quite plug-and-play, Quarkus is ready-to-go. It is designed to work with little to no configuration. Built with an eye towards ‘enjoyability’ for developers, Quarkus also includes functionality to perform live coding so that developers can immediately check the effect of code changes and quickly troubleshoot them.

Developers can choose the Java frameworks they want for their applications, which can be run in JVM mode or compiled and run in native mode. With Java now having some quarter century of history, Quarkus is a means of crossing the chasm to cloud-native environments, many of which will include Kubernetes for container orchestration.

Let’s also remember that Quarkus is crafted from well-known Java libraries and standards, which is a positive boost for developer adoption on several levels. Seasoned Java developers will have been used to working with these libraries, standards and wider programming methodologies for over two decades now, so it is important for them to feel ‘at ease’ with Quarkus, experience a minimal learning curve and get the most out of the technology itself.

Java has been so popular for so long that many familiar and widely used frameworks and utilities have been created over the years. Being able to ensure that these are also available to Quarkus developers is very important so we don’t reinvent the wheel but also so that developers already familiar with them can bring that knowledge to building Quarkus applications.

Reactive vs. imperative programming models

Quarkus co-founder Jason Greene is a distinguished engineer and manager at Red Hat. Greene has said that the goal of Quarkus is to make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures.

This reactive vs. imperative balance is important, because reactive programming has a lot of potential benefits in terms of scalability over traditional imperative programming. While imperative programming will remain an important fundamental in programming for the foreseeable future, the ability to work with asynchronous non-sequential data events has strong applicability for modern cloud software application development.

A good example here would be NodeJS and the use of serverless, which AWS has popularised with its Lambda implementation. It is a question of the business logic for the reactive model being there, in place, ready for use. But that business logic may not even be held in-memory; instead, the instance of that business logic can be brought into a live production environment when needed.

With the increasing use of application microservices moving to a much more reactive model approach, the Quarkus team wanted to have both capabilities available to developers. But, equally, the team also wanted Quarkus to appeal to developers building in imperative environments as well, where the model is appropriate to the use case.

In many ways, the imperative model is a layer that sits on top of any given reactive model; a structural relationship that we can see in the Internet itself, which has always been very reactive in its nature.

Quarkus is found in the Red Hat OpenShift 4.6 open source container application platform and Red Hat has made Quarkus available to all users who are OpenShift customers. We know that 20% of Java developers who are using cloud are looking at using Quarkus, so with Quarkus being Kube-native it makes a lot of sense to be able to use the technology from the outset.

Red Hat has also updated its Migration Toolkit for Applications in line with the arrival of Quarkus. The Migration Toolkit itself has been around for several years and it helps migrate lots of different applications on different platforms (WebLogic from Oracle to Red Hat EAP for example). Even though these applications will have been built in standards-based environments, there will always be certain changes needed to migrate those applications forwards and upwards.

SEE ALSO: Quarkus – an IO thread and a worker thread walk into a bar: a microbenchmark story

What Red Hat has done in recent times is point the Migration Toolkit towards Quarkus. This now means that if a developer points their applications at the Toolkit, it can help make recommendations to suggest which things could be minimally changed without engaging in a complete process of code refactoring.

So overall, the journey to Quarkus should be painless, familiar, operationally flexible and highly-functional in terms of day-to-day use. At Red Hat, we’re encouraging and mentoring developers on their path to use Quarkus in their preferred way in environments that span from the data centre, outward to the network edge across all devices and the Internet on Things, and across the entire breadth of the public cloud.