Forem: Pierre Guimon

Migrating a Spring Boot application to Quarkus

Pierre Guimon — Mon, 28 Nov 2022 13:36:58 +0000

Introduction

Java applications running in traditional Java Enterprise Edition environments are not well suited for cloud environments.

The application server start-up time are quite high, usually above one minute, and the memory footprint required is high. Often, they require complex cluster configuration.

This is not compatible with scale-up and scale-down concepts introduced in the cloud.

A myriad of java frameworks are available on the market.

Quarkus is a Red-Hat java framework that does not require an application server, and whose goal is to support Kubernetes and Java Native Compilation using GraalVM.

Quarkus allows to reuse many existing java libraries, offering specific extensions for native compilation.

Applications built with Quarkus can start in few seconds and if native compiled, they have a very limited memory and disk footprint.

If you have no idea what is Quarkus, I encourage you to read my Quarkus fundamentals post (15mins read) on the subject.

With Quarkus it is not possible to replace 100% of the features provided by Java Enterprise Edition application servers: EJB, JSP and other similar technologies will not be available to applications written for Quarkus.

Migrating to Quarkus from a Spring boot application is not an immediate task, especially if targeting native compilation: many adaptations could be required.

Although there are great guides out there to explain you how to migrate a Spring boot application to Quarkus, those guides do not really emphasize on the approach for migrating a multi service code base from Spring to Quarkus.
Here are some examples:

In this article I will detail the approach for migrating a substantial Spring boot code base application (in other terms, a monolith 😆) to Quarkus.

I will also highlight some pitfalls that we have ran into while migrating one of my company service code base to Quarkus.

Approach for migrating to Quarkus

I will explain in this section how we have been progressing on the migration of one of my company service to Quarkus.

First of all, whatever the approach is, I would recommend anyone to get to know Quarkus by following the post highlighted in the introduction.

Once done, you should also play with the Quarkus Get Started guide on the official website, so that you can get familiar with the packaging and build your first application with Quarkus in no more than an hour.

The hothead approach

The first approach, that I like to call the hothead approach consists in:

Adding the quarkus universe bom dependency to your service pom.xml file, following the guide: https://quarkus.io/guides/maven-tooling#build-tool-maven
Build the service with: mvn quarkus:dev command line and light a candle hoping that everything will work at first try!

The build will of course generate tons of errors, most of them being related to dependency injection issues.

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:2.2.3.Final:build (default) on project webapp: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR] [error]: Build step io.quarkus.arc.deployment.ArcProcessor#validate threw an exception: javax.enterprise.inject.spi.DeploymentException: Found 107 deployment problems:
[ERROR] [1] Unsatisfied dependency for type org.springframework.web.client.RestTemplate and qualifiers [@Default]
[ERROR] - java member: com.myapp.server_impl.ServerImpl#<init>()
[ERROR] - declared on CLASS bean [types=[com.myapp.server_impl.ServerImpl, java.lang.Object], qualifiers=[@Named(value = "serverImpl"), @Default, @Any], target=com.myapp.server_impl.ServerImpl]
[ERROR] [2] Unsatisfied dependency for type javax.ws.rs.ext.Provider and qualifiers [@Default]
[ERROR] - java member: com.myapp.server_impl.ServerImpl#<init>()
[ERROR] - declared on CLASS bean [types=[com.myapp.server_impl.ServerImpl, java.lang.Object], qualifiers=[@Named(value = "serverImpl"), @Default, @Any], target=com.myapp.server_impl.ServerImpl]
[ERROR] [3] Unsatisfied dependency for type java.util.concurrent.ExecutorService and qualifiers [@Default]
[ERROR] - java member: com.myapp.server_impl.ServerImpl#<init>()
[ERROR] - declared on CLASS bean [types=[com.myapp.server_impl.ServerImpl, java.lang.Object], qualifiers=[@Named(value = "serverImpl"), @Default, @Any], target=com.myapp.server_impl.ServerImpl]
...
...
hundreds of errors later
...
...
[ERROR] at io.quarkus.arc.processor.BeanDeployment.processErrors(BeanDeployment.java:1108)
[ERROR] at io.quarkus.arc.processor.BeanDeployment.init(BeanDeployment.java:265)
[ERROR] at io.quarkus.arc.processor.BeanProcessor.initialize(BeanProcessor.java:129)
[ERROR] at io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:418)

Did you really think it would have work like that 😇 ?!
Okay, let's take a step back and explain the basics.

The use-my-brain approach

Dependency injection

Quarkus is designed to work with the most widely used Java standards, frameworks and libraries, such as Eclipse MicroProfile, Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA) and many more.

Quarkus programming model is based on another standard: the Contexts and Dependency Injection for Java 2.0 specification.

If you are completely new to dependency injection, I encourage you to read Quarkus introduction to contexts and dependency injection.

The first thing to know about Quarkus bean discovery and injection is that it won't scan classes from external modules.

If you have a multi maven modules project, like we do for the service we have been migrating, you will find out that Quarkus won't find by default classes in other modules.

You have various ways to make Quarkus find your beans. They are listed here: https://quarkus.io/guides/cdi-reference#bean_discovery.

Here is an excerpt from the referenced link:

"The bean archive is synthesized from:

The application classes,
Dependencies that contain a beans.xml descriptor (content is ignored),
Dependencies that contain a Jandex index META-INF/jandex.idx,
Dependencies referenced by quarkus.index-dependency in application.properties configuration file,
And Quarkus integration code."

If you want, an external module or a third-party library on which you do not have the hand (meaning that you can't modify it), to be scanned by Quarkus you should add the dependency in the application.properties configuration file.

If you have control on the module/project, you can directly add an empty beans.xml file in the META-INF folder.

That said, you might want to clean your dependencies before getting your hands dirty, the less code base you will need to migrate the better.

We will come back to that point later.

Spring

Let's focus now on Spring. In the service we have been migrating, developers have been using Spring intensively.

The service grew over the years and Spring dependencies have been added to the project. Spring dependency injection has been used here and there, instead of standard CDI specifications.

As an example, @Component Spring DI annotations might have been used instead of @Singleton CDI annotation.

Another example would be the use of @Bean Spring DI annotation instead of @Produces CDI annotation.

There are more examples, and you can find a conversion table (Spring DI annotation versus CDI) on the Quarkus website: https://quarkus.io/guides/spring-di#conversion-table.

So that the migration to Quarkus is not cumbersome, the Quarkus team came-up with a set of extensions that will help you migrating Spring projects to Quarkus: spring-di, spring-web, spring-data-jpa, spring-data, spring-security, spring-cache, spring-scheduled, spring-boot-properties, spring-cloud-config-client.

For instance, if you decide to use spring-di Quarkus extension, a spring DI processor will map Spring DI annotations to CDI annotations.

That said, it is recommended to migrate all your Spring beans to CDI specifications.

Migrating to Quarkus

Following the above explanation on dependency injection and Spring we came-up with the following workplan that can be implemented for any migration of Spring boot based service to Quarkus.

1. Dependencies analysis

First of all, we want to analyze the dependencies that are required to build and run the service to be migrated to Quarkus framework.

Why ? This step is fundamental to identify all the required external dependencies as well as internal dependencies.
How ? We have used Class Dependency Analyzer (CDA) tool to meet this goal. You can find out how to use it on this page.

You can use built-in IDE dependency analyzer as well, but I found CDA really convenient to use and you can also use it as a library in your project if you want to improve the tool possibilities.

2. Maven modules cleaning

Secondly, we want to clean all unwanted internal dependencies.

Why ? As said previously we are migrating a monolith and it is based on Maven software management tool.

The code base consists of multiple Maven modules that are used in different services.

Some code that is not used, by the service we want to migrate, is part of Maven modules that the service depends on.

By cleaning all unwanted internal dependencies through moves to new/others maven modules, we will eventually reduce the scope of code base to be migrated to Quarkus.

Following this principle, we have performed major cleaning in the code base to remove irrelevant and unwanted internal dependencies for our service.

I highly encourage you to perform such cleaning prior to this migration. This preliminary step will eventually allow you to save time in the later steps.

How ? The output of Class Dependency Analyzer tool allows you to check all the classes that your service depends on, and eventually remove/move all unwanted classes.

Concretely, this has been performed by moving some classes that were not needed by the service, to new maven modules or existing maven modules on which the service doesn't have a dependency on.

We have also refactored some pieces of code: by splitting some classes for instance, by creating new classes to specialized their usage to the service we have been migrating to Quarkus framework.

3. Mocking

The next step is to mock all the external dependencies that we have highlighted in step 1 to progress on the migration to Quarkus of OUR code base first.

Why ? By mocking all the external dependencies, we make sure to progress on our code base migration first and that we are not blocked by external dependencies.
How ? Simply by implementing interfaces with mocked behavior.

For instance, in the service that we have been migrating to Quarkus, we use an external dependency interface to have access to a context.

So that our application is building with Quarkus, we had to mock temporarily the context interface with a static mocked implementation.

We implemented the interface and made sure that the bean follows the CDI specifications.

4. Internal/external dependencies teams support

The previous steps should have highlighted you all the dependencies that are handled inside and outside of your organization.

Now you can ask support to the teams inside/outside your organization owning dependencies, to unlock your progression.

How ? Either you ask for the support of the teams inside/outside your organization or you contribute directly to the migration to Quarkus of your dependencies.

This is done in an iterative approach, meaning that you or an external team is making a dependency Quarkus ready, then they deliver it, you integrate it in your code base, you remove the mock associated to this external dependency and you go on and on until there is no more external dependency to be migrated to Quarkus.

5. Spring-DI Quarkus extension

So that the migration to Quarkus is not cumbersome, the Quarkus team came-up with a set of extensions that will help you migrating Spring projects to Quarkus.

Why ? To comply with CDI specifications, we would need to migrate all our non-CDI compliant beans to CDI compliant beans, meaning we would need to migrate all Spring beans to CDI beans. This might be a fastidious work.
How ? To avoid doing this non-neglectable task, we have been using the Quarkus spring-di extension that do the job for you for the nominal cases.

You can find a conversion table (Spring DI annotation versus CDI) here: https://quarkus.io/guides/spring-di#conversion-table.

Using this extension is done simply by adding the following dependency to your service pom.xml file:

<dependencies>
    <!-- Spring DI extension -->
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-spring-di</artifactId>
        <scope>runtime</scope>
    </dependency>
</dependencies>

6. Multi Maven modules handling

Let's be honest, no monolith has only one maven module.

This step is about making Quarkus scan beans in all required maven modules that the service you are migrating to Quarkus depends on.

Why ? As explained in the dependency injection section, Quarkus won't scan classes from external modules.

If you want, an external module or a third party library on which you do not have the hand (meaning that you can't modify it), to be scanned by Quarkus you should add the dependency in the application.properties configuration file.

If you have control on the module/project, you can directly add an empty beans.xml file in the META-INF folder.

This will ensure that Quarkus scans your beans.

How ? Simply create an empty beans.xml file in the META-INF folder of each maven module that you own, or create a dependency in the application.properties configuration file for modules that we do not own.

You can find more details in here: https://quarkus.io/guides/cdi-reference#bean_discovery.

7. Migrate your code base

This step focuses on migrating uncompliant base code to Quarkus framework compliancy.

Why ? So far, we mocked external dependencies to progress on the migration of our code base, we used spring-di Quarkus extension to ease our migration, but some pieces of code must be migrated to comply with Quarkus standards to build your service.

Indeed, some pieces of software cannot be handled by the extensions provided by the Quarkus team and must be migrated; and some other pieces of code are not following the CDI standard specifications and must be migrated as well.

This step really depends on your software.

We will review later on the recurrent errors we have been facing while migrating the service to Quarkus.

How ? Comply with CDI specifications and migrate some Spring dependencies that cannot be handled by Quarkus extensions.
Example.

In the service code base we have migrated we were using ThreadPoolTaskExecutor which is a java bean that allows for configuring a java standard ThreadPoolExecutor in bean style (through its corePoolSize, maxPoolSize, keepAliveSeconds, queueCapacity properties).

This class is also well suited for management and monitoring (e.g. through JMX), providing several useful attributes: corePoolSize, maxPoolSize, keepAliveSeconds (all supporting updates at runtime); poolSize, activeCount (for introspection only).

This class is part of the spring-context library.

Having a quick look at spring-di quarkus extension pom.xml you can find-out quite easily that spring-context dependency is excluded so that it is not accessible to us, as end-user.

Spring-context is excluded from the dependencies to filter spring-context classes and only keep the ones that are necessary in quarkus-spring-context-api dependency.

This means that we can't use at the same time, the spring-di quarkus extension (which is definitely a must have to migrate a monolith since we do not want to migrate all our beans to CDI standard specifications in the first place) and the Spring ThreadPoolTaskExecutor.

To mitigate this issue we have migrated our Spring ThreadPoolTaskExecutor to the ManagedExecutor class of org.microprofile library which is a standard supported by Quarkus.

This is an example that is particular to the code of this service, since not everyone uses Spring ThreadPoolTaskExecutor.

In the recurrent errors and tips section, we will go through more commons errors that you will for sure face while migrating to Quarkus framework.

8. Optimize software to embrace GraalVM idiomatics

This step is an optimization step that you should perform to embrace GraalVM idiomatics: boot faster, deliver smaller packages.

Why ? GraalVM idiomatics require to change the way frameworks work, not really at runtime but at startup time. Most of the dynamicity that a framework brings actually comes at the startup time and this is what is being shifted to the build time with Quarkus.

Quarkus could be also highlighted to be a framework to makes frameworks start at build time.

At startup time a framework (like Hibernate or Spring for instance) does usually the following:

Parse config files (e.g.: persistance.xml file)
Classpath and classes scanning for annotations (e.g.: @Entity, @Bean, etc...), getters or others metadata
Build metamodel objects from all those above information on which the framework will run at runtime. For instance Hibernate doesn't keep .xml files in memory but builds an internal model that is represented at runtime and it is this model that is used at runtime to save entities, etc...
Prepare reflection (will get the reference to method object and field to be able to perform invoke) and build proxies
Start and open IO, threads, etc... (e.g.: database connection, etc...)

Conceptually, when you look at those steps, there could be easily done at build time instead of at startup time.

Everything that is prior to the last step and even some parts of the start can be done at build time.

This is what is done by Quarkus, it takes a framework like Hibernate and makes it work so that the maximum of steps can be performed at build time.

On the following schema, you can see a typical Java framework at the top where most of the work is performed at runtime (configuration load, classpath scanning, model creation, starts the management), whereas at the bottom you can see a Quarkus framework where most of the work is performed at build time.

That said, you might want to endorse this approach and make sure that all possible actions that could be performed at build time are taken out from the runtime and deported to the build time.

Let's explain those concepts with a concrete example that we faced while migrating our service to Quarkus.

Once we were able to package our quarkus application exposing our service, we started it and launched a first message towards it.

The first query was taking a long time to be processed, whereas the second query was much more fast (x10 times faster 😮).

We had to investigate why the first query was so long to be processed.

Using the Async Profiler we were able to build flamegraphs for the first and second queries to picture the differences in path length of the two transactions execution.

In the first flamegraph we saw that we spend most of the transaction time in initializing a JAXB context responsible for marsharling/unmarshalling a context from the input query.

This operation could be transferred at build time instead of doing it at startup time, since all the information required are present at build time.

This is just one example but, I'm positive, that in your code base, you have some operations that could be transferred from runtime to build time too !

Recurrent errors and tips

In this section we will highlight some common errors that you might encounter while migrating a service to Quarkus framework, and tips to solve them.

Package-private

You will see from time to time the following info message while building your Quarkus application:

[INFO] [io.quarkus.arc.processor.BeanProcessor] Found unrecommended usage of private members (use package-private instead) in application beans:
    - @Inject field com.myapp.service.MyService#someBean

If a property is package-private, Quarkus can inject it directly without requiring any reflection to come into play.

That is why Quarkus recommends package-private members for injection as it tries to avoid reflection as much as possible (the reason for this being that less reflection means better performance which is something Quarkus strives to achieve).

Quarkus is using GraalVM to build a native executable. One of the limitations of GraalVM is the usage of reflection. Reflective operations are supported but all relevant members must be registered for reflection explicitly. Those registrations result in a bigger native executable.

And if Quarkus DI needs to access a private member it has to use reflection. That’s why Quarkus users are encouraged not to use private members in their beans. This involves injection fields, constructors and initializers, observer methods, producer methods and fields, disposers and interceptor methods.

Bean list injection

Bean injection list is working perfectly well with Spring:

@Inject List<PaymentProcessor> paymentProcessor;

but is not part of the CDI standard specifications.

In certain situations, injection is not the most convenient way to obtain a contextual reference. For example, it may not be used when:

the bean type or qualifiers vary dynamically at runtime, or
depending upon the deployment, there may be no bean which satisfies the type and qualifiers, or
we would like to iterate over all beans of a certain type.

In these situations, an instance of the javax.enterprise.inject.Instance interface may be injected:

@Inject Instance<PaymentProcessor> paymentProcessor;

For more details you can checkout the CDI specifications for the instance interface.

That is to say, that you will have to migrate your Spring list beans injection to a CDI specifications compliant solution.

Usually you will use a producer pattern to produce those beans.

Unused beans

This particular point echoes the Quarkus documentation: https://quarkus.io/guides/cdi-reference#remove_unused_beans

Some of our beans were being removed at build time because they were considered as unused by Quarkus.

For example, the following Spring bean:

@Component
public class PaymentMapper extends Mapper<Payment> {
...
}

which extends from:

public abstract class Mapper<T> {

  @Inject
  private MapperFactory mapperFactory;

  @PostConstruct
  private void register() {
    mapperFactory.register(type_of_the_class, this);
  }
}

was registered in:

@Named
public class MapperFactory {

  private static final Map<Class, Mapper> mappers = new HashMap<>();

  public void register(Class type, Mapper mapper) {
    mappers.put(type, mapper);
  }
}

The bean PaymentMapper was considered as unused because it was not referenced anywhere else in the code apart from its definition.

Unfortunately, the issue is that it was actually used via registering in a @PostConstruct method call in the MapperFactory.

The static mappers map ended up being always empty, because the Mapper beans were marked as unused.

For this case, we had to change the code so that the MapperFactory registers a list of beans implementing the same interface, which makes anyway way more sense.

Legal bean type

It is clearly written in the CDI specifications that: A parameterized type that contains a wildcard type parameter is not a legal bean type.

I have made a small reproducer on github to show you the failure of a CDI parameterized bean, that contains a wildcard type parameter, injection:

Since those beans are not considered as legal, they are not considered by Quarkus.

Provider no-arg constructor

In our code base we are using @Provider classes to decode inputs or to encode outputs.

These providers implement ReaderInterceptor/WriterInterceptor interfaces.

When quarkus-resteasy library comes into play it tells us at compilation time:

WARN  [io.qua.res.com.dep.ResteasyCommonProcessor] (build-9) Classes annotated with @Provider should have a single, no-argument constructor, otherwise dependency injection won't work properly. Offending class is com.myapp.interceptor.BaseReaderInterceptor

The rule is the following: Classes annotated with @Provider should have a single, no-argument constructor and classes must be public.

For instance, this piece of code is not compiling:

@Provider
class BaseReaderInterceptor implements ReaderInterceptor {

  private StatsCollector statsCollector;

  @Inject
  public BaseReaderInterceptor(StatsCollector statsCollector) {
    this.statsCollector = statsCollector;
  }
  ...
}

Whereas this one is compiling:

@Provider
public class BaseReaderInterceptor implements ReaderInterceptor {

  // Injection by constructor makes REST-EASY unable to initialize the ReaderInterceptor...!!!!
  // Hence we inject at member level
  @Inject
  private StatsCollector statsCollector;

  ...
}

References

Emmanuel Bernard talk on Quarkus DEVOXX video: Quarkus why, how and what
Oleg Selaje & Thomas Wuerthinger talk on GraalVM DEVOXX video: Everything you need to know about GraalVM
For FR speakers: Emmanuel Bernard & Clément Escoffier talk on using Quarkus with GraalVM DEVOXX video: Quarkus: Comment faire une appli Java Cloud Native avec Graal VM

Kafka consumer rebalancing - impact on Kafka Streams consumers performances

Pierre Guimon — Tue, 25 Oct 2022 15:09:39 +0000

Introduction

Kafka consumer rebalancing is part of the lifecycle of any Kafka consumer group.

We will focus on defining what is Kafka consumer rebalancing first.

Then, we will see how it can impact the performances of Kafka Streams consumers on real applications and how we can mitigate it.

What is Kafka consumer rebalancing ?

Kafka consumers use the concept of consumer groups to allow a pool of processes to divide the work of consuming and processing records.

Each member of a consumer group, consumes from a unique set of Kafka topic's partitions.

Membership in a consumer group is maintained dynamically: if a process fails, the partitions assigned to it will be reassigned to other consumers in the same group. Similarly, if a new consumer joins the group, partitions will be moved from existing consumers to the new one. This is known as rebalancing the group.

Group rebalance requires two actors:

On server side: each group is managed by only one Kafka broker that we call a group coordinator.
On client side: one of the consumers is designed as a consumer leader/group leader and will compute the assignation using the implementation of the interface:



org.apache.kafka.clients.consumer.ConsumerPartitionAssignor

defined through the consumers configuration:



partition.assignment.strategy

You can find the existing partitions assignment strategies in Kafka consumer config properties.

Prior to Kafka Streams 2.4 version, the default consumer assignors was RangeAssignor or RoundRobinAssignor.

When a new consumer instance is deployed, the other members of the same group are notified by the group coordinator to release their resources (commit offsets and release the assigned partitions) using the rebalance protocol, and recalculate the allocation of resources (topic's partitions) between all group members (old ones plus the new one in this case).
The mechanism is the same when the group coordinator detects the loss of one of the members (e.g. : an instance crash => no heart-beats received for session.timeout.ms, a leave group signal when a member exceeds the poll.intervall.ms when processing records...)

Below is an example of rebalance when a third consumer instance (customer 3) joins a consumer group.

The challenging step with this rebalancing is what is called the
Synchronization Barrier, at this step all resources (topic's partitions) must be released. This is done by each instance before sending the JoingGroup Request.

So until SyncResponse is received, no data will be processed by the consumers, and, as a result, processing of events from a topic happens with some delay. This is what we call a stop-the-world operation.

This is the most secure way to assign partitions. Some business cases could tolerate rebalancing like offline/asynchronous events processing, but you can imagine that it doesn't fly in some real-time event processing.

Now let's imagine that we are running a Kafka Streams application on a Kubernetes cluster. There are several use cases where rebalancing would occur:

Kubernetes node eviction: a node is being evicted from the Kubernetes cluster, any instances of our application running on this particular node would need to be restarted on another node of the cluster. This would induce JoinGroup requests from the newly deployed instances of the application, ultimately resulting in rebalancing.
Kubernetes pod eviction: an applicative pod is being evicted from a node of the Kubernetes cluster. Same as previously, this would result in rebalancing for the newly created applicative instance.
Application rolling upgrade: Similar to what might happen unexpectedly with a failure, an intentional application rolling upgrade could be triggered for a software update for instance.
Application scaling up/down: In case the Kafka Streams application requires to scale up or down, rebalance would occur to accommodate with the new consumers or removed consumers.

Are they any alternative ways to rebalance to not suffer from the stop-the-world effect ?

Incremental cooperative rebalancing

Amongst others, these reasons, motivated the need for a more robust rebalancing protocol.
With Kafka 2.4 version, the incremental cooperative rebalancing protocol was introduced, and the main aim is to not stop-the-world when rebalancing.
It uses the StickyAssignor mechanism: it allows to conserve as much as possible the same partitions processed by each consumer instance when rebalancing.
This protocol allows to release just the topic's partitions that will be processed by another consumer instance and not the others using two rebalance phases (or two consecutive rebalances):

The aim of the first rebalance is to revoke the partitions that will transit from an instance to another. The consumer leader computes the new assignment and sends to each one, only it's current partitions minus those to revoke.
On the second rebalance, consumers will send a second JoinGroup request to assign the revoked partitions (which are unassigned partitions).

Below is an example of incremental cooperative rebalancing when a third consumer instance (customer 3) joins a consumer group.

More details around the motivations for implementing the incremental cooperative rebalancing are available on this Kafka confluence page. You can find the implementation details on this other Kafka confluence page.

Impact of rebalancing on performances

Now that we have described what is the Kafka consumer rebalancing, let's see how it impacts performances on a Kafka Streams based platform.

Test protocol

Let's consider the following simple example:

We have a first microservice with 3 applicative instances, that is deployed on a Kubernetes cluster. This service consumes events from a single topic #1 using Kafka Streams 3.1 version. This topic contains 48 partitions and there are 3600 events per second published on it.
On each of the 3 instances we use the Kafka Streams configuration property:



num.stream.threads = 16

Hence, on a single app instance we process events from 16 partitions with 16 Kafka Streams threads.
This microservice is only enriching the records it processes with additional information. Hence the number of events stays the same in the second topic.
The processing of a single event takes around 1 milliseconds and the stream is stateless.

We plug a second microservice with 4 applicative instances. Each of them consuming from a single topic #2 of 64 partitions using Kafka Streams 3.1 version. We use the same Kafka Streams configuration property, and, as a result, each instance processes events from 16 partitions using 16 Kafka Streams threads. It receives as well 3600 events per second from the processing of the first microservice.
The processing of a single event takes around 3.5 milliseconds and the stream is stateless.

We are using Kafka Streams 3.1 version and by default the incremental cooperative rebalancing is used.

We will be performing a rolling update of the first microservice, simulating a software update, to see the impact on the platform while injecting 3600 events per second on topic #1 for 30 minutes.

Monitoring

The microservices are monitored via Prometheus solution and they are exposing Kafka Streams metrics amongst other metrics.
Here are the metrics used to monitor the impact of the Kafka consumer rebalancing mechanism:

kafka_stream_processor_node_record_e2e_latency_avg: The average end-to-end latency of a record, measured by comparing the record timestamp when it was first created with the system time when it has been fully processed by the node. The Kafka rebalancing should impact this metric as some partitions being rebalanced won't get consumed anymore during rebalancing, and, as a result, the average end-to-end latency of a record should increase.
kafka_consumer_coordinator_rebalance_latency_avg: The average time taken for a group to complete a successful rebalance, which may be composed of several failed re-trials until it succeeded.
kafka_consumer_fetch_manager_records_lag_avg: The average records lag. Lag is the number of records available on the broker but not yet consumed. An increasing value over time is the best indication that the consumer group is not keeping up with the producers. The Kafka rebalancing should impact this metric as some partitions being rebalanced won't get consumed anymore during rebalancing, and, as a result, the lag should increase.
kafka_consumer_fetch_manager_records_lag_max: The max records lag.

Performance test

Since the Kafka consumer incremental cooperative rebalancing is activated by default for our version of Kafka Streams, we wanted to force the Kafka consumer eager rebalancing mechanism to see the advertised positive impact of the incremental cooperative rebalancing.
The Kafka consumer eager rebalancing is the former rebalancing protocol that was in place before the Kafka consumer incremental cooperative rebalancing was introduced and set as default.

To do so we simply need to add the following Kafka Streams configuration property to the deployment configuration of our first microservice:



upgrade_from: 2.3

This ensures that the Kafka cooperative rebalancing is not activated anymore since it didn't exist in this version of Kafka.

In the following graphs we compare the impact of Kafka incremental cooperative rebalancing to the Kafka eager rebalancing.

Kafka Streams requests/sec processed per pod instance on the microservice #1 (1200 requests per pod x 3 = 3600 events/sec):

Kafka Streams average/max end-to-end latency time of a record seen on the microservice #2:

The average/max end-to-end latency time of a record is the same when we compare the eager rebalancing to the cooperative rebalancing and is high, ~40sec. To give you more context, the average end-to-end latency seen on microservice #2 when no rebalancing is occurring is around 50 milliseconds!

Kafka Streams total max lag per topic (in yellow the topic #1 corresponding to the topic from which the microservice #1 is consuming):

We do see more lag (~100k elements) with the eager rebalancing compared to the cooperative rebalancing (~40k elements). Without rebalancing, not a single lag has been witnessed.

Kafka group rebalance average time on the microservice #1:

The rebalance average time is the same (~40sec) when we compare the eager rebalancing to the cooperative rebalancing.

Using the Kafka eager rebalancing, with the stop-the-world effect, while rebalancing is in progress we can see that the max lag goes higher than with the cooperative rebalancing, which is expected since in incremental cooperative mode, some consumers are still able to consume.

Overall the lag is scattered over time when using the cooperative rebalancing, and the average end-to-end latency time of a record is high in both cases.

What we can retain from this test is that the cooperative rebalancing allows for some consumers to sill consume during a rebalancing but overall the average end-to-end latency time of a record is pretty high in both cases.

We have seen that some consumers get rebalanced several times with the cooperative rebalancing during the rolling update. It puts pressure on some partitions which are not anymore consumed for an important time and this induces high average end-to-end latency time of a record on those partitions, whereas on some other partitions which didn't get rebalanced that often, the average end-to-end latency time of a record is rather low.

When the consumers, which consume from partitions with high number of tanked messages restart after the rebalance, they have to dequeue a lot more items than for the other partitions, hence the message consumption on those consumers is increasing for a short period of time until the lag is consumed.

In the end, the incremental cooperative rebalancing reduces the overall max lag consumption on the topic #1 but the average end-to-end latency time of a record is not improved and high in both cases.
You can easily imagine that the Kafka rebalancing can have an important impact if at each deployment rollout we increase the average end-to-end latency time of a record from 50ms to 40sec! In real-time use cases with strong end-to-end latency time of a record requirements, this doesn't fly.

Mitigating the impact of Kafka consumer rebalancing

Let's see how we can decrease the impact of Kafka rebalancing through various tips and how they have impacted our platform.

Keep up-to-date with Kafka Streams latest versions

With the first versions of Apache Kafka client (2.4) using the CooperativeStickyAssignor (incremental cooperative rebalancing), there was no huge difference observed in terms of performances, but this was for preparing to a multitude of changes that have been delivered in next versions (2.6) and that will be delivered in the future. That is why it's essential to upgrade frequently to the latest release.

Decrease Consumer Session Expiration

There is a Kafka Streams configuration property named:



session.timeout.ms

It corresponds to the timeout used to detect client failures when using Kafka's group management facility.

The client sends periodic heartbeats to indicate its liveness to the broker.

If no heartbeats are received by the broker before the expiration of this session timeout, then the broker will remove this client from the group and initiate a rebalance.

Note that the value must be in the allowable range as configured in the broker configuration by group.min.session.timeout.ms and group.max.session.timeout.ms.

In Kafka Streams 3.1 version that we are using the default value is 45sec.

If an application instance gets unavailable, rebalance will happen only after the default 45sec, and eventually induce a lag in events consumption.

In conjunction with this property there is another Kafka Streams configuration property named that requires an update:



heartbeat.interval.ms

It corresponds to the expected time between heartbeats to the consumer coordinator when using Kafka's group management facilities.

Heartbeats are used to ensure that the consumer's session stays active and to facilitate rebalancing when new consumers join or leave the group.

The value must be set lower than session.timeout.ms, but typically should be set no higher than 1/3 of that value.

It can be adjusted even lower to control the expected time for normal rebalances.

The default value of the heartbeat is 3sec in Kafka Streams 3.1 version that we are using.

We need to be careful with these settings, as it increases the probability of rebalancing occurrence on a daily basis, and consumers might hang in long rebalances, depending on network quality and stability.

For our testing we have set the following values:



session.timeout.ms=6000
heartbeat.interval.ms=1500

Sending leave group request

By default, Kafka Streams doesn't send consumer leave group request on application graceful shutdown, and, as a result, messages from some partitions (that were assigned to terminating applicative instance) will not be processed until session by this consumer will expire (with duration session.timeout.ms), and only after expiration, new rebalance will be triggered.

By default in Kafka Streams 3.1, we have session.timeout.ms=45000, so it means during a single applicative instance restart, messages by some partitions will be processed at least within 45 seconds, and it's painful for real-time requirements.

You can find more details about a discussion on this property in this Kafka Jira ticket.

The default value is false in Kafka Streams configuration.

For our testing we have set the following values:



internal.leave.group.on.close=true

Tweak deployment rollout strategy

Our application is deployed on a Kubernetes cluster and as such we can easily control the number of applicative instances which are created during a rolling update.

One can use the following Kubernetes deployment properties to achieve this:



.spec.strategy.rollingUpdate.maxSurge (absolute/percentage, default: 25%)
.spec.strategy.rollingUpdate.maxUnavailable (absolute/percentage, default: 25%)

The more instances we rollout at the same time, the more partitions will need to get reassigned through Kafka rebalancing, eventually leading to high end-to-end latency time of a record, and a higher max lag per topic.

Decreasing the number of instances which are started at the same time can mitigate the impact of Kafka rebalancing.

For our testing we have set the following values:



.spec.strategy.rollingUpdate.maxSurge=1
.spec.strategy.rollingUpdate.maxUnavailable=0

In that case, a single applicative instance will be started at a given time. The deployment process will be longer for sure, but overall we expect to have more stable performances on the platform, which is what we are looking for real-time use cases.

Results

We have applied the above recommendations and we have ran the same test protocol than before except that we have launched 4 rolling updates of microservice #1 in 30mins to compute bunch of data. Here are the results:

Kafka Streams requests/sec processed per pod instance on the microservice #1 (1200 requests per pod x 3 = 3600 events/sec):

We do not see anymore the impact of Kafka rebalancing on the number of events processed by the microservice #1.

Kafka Streams average/max end-to-end latency time of a record seen on the microservice #2:

The average end-to-end latency time of a record is far less impacted than before by the Kafka rebalancing. We went down from 40sec to ~750ms in average during a Kafka rebalancing.

Kafka Streams total max lag per topic (topic #1 corresponding to the topic from which the microservice #1 is consuming):

We have far less lag than before the optimizations. We went down from ~40k elements with incremental cooperative rebalancing to ~150 elements.

Kafka group rebalance average time:

The rebalance average time went down from 40sec to ~1sec with the optimizations.

Here is a table summing-up the results of the optimizations on the platform:

	Without optimizations	With optimizations
microservice #1 - avg group rebalance time	40sec	1sec
topic #1 - max lag	40.000 events	150 events
microservice #2 - avg end-to-end latency time of a record	40sec	700ms

Kafka consumer rebalancing mechanism has a non-neglectable impact on the performances of real-time applications. It can be mitigated by setting some Kafka consumers properties but it is still present.

References

LinkedIn Engineering team talk on Kafka rebalancing video: Consumer Group Internals: Rebalancing, Rebalancing....
Juan Rao quick talk on Kafka consumer group video: Apache Kafka Consumers and Consumer Group Protocol
Gwen Shapira talk on Kafka rebalancing video: The Magical Rebalance Protocol of Apache Kafka

Quarkus fundamentals

Pierre Guimon — Tue, 04 Oct 2022 14:24:35 +0000

Introduction

The world of Java toolkits to build applications is already rich, and Quarkus is yet another toolkit.

Why should you be interested in it? We will see what makes Quarkus different from other Java toolkits.

We will first focus on defining what is Quarkus.

Then, we will see Quarkus internal architecture, what technical benefits it brings, and how it can be more performant than the average Java toolkit.

This article tries to give you an overview of Quarkus framework, as well as explaining its interactions with GraalVM.

It is inspired by some of Emmanuel Bernard talks on the subject who is a recognized Java champion and lead at Quarkus RedHat project.

What is Quarkus ?

Quarkus definition

Quarkus is, the contraction of the words quark and us. Quark, the elementary particle and fundamental constituent of matter, and us. If you go to the Quarkus website, at the top, you can read two sentences:

Supersonic Subatomic Java
A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards

Supersonic Subatomic Java

The idea behind supersonic is speed.

As we will see, Quarkus does all its best to boot your application as fast as possible and to respond to the first request.

Another interesting aspect of the speed is the way you develop. With Quarkus, a developer codes and tests its code. It's so fast in recompiling and starting that, as a developer, you save a lot of time just by changing your code and seeing it running.

Without wasting time, developing with Quarkus makes the developer's experience feel much faster.

The idea behind the word subatomic is the size.

The size of the memory used to run an application, but also the size of the executable once the application is packaged.

Quarkus is optimized to reduce the amount of memory used by a Java application. By using several tricks that we will discover next, Quarkus not just reduces the amount of memory of a Java heap, but the memory used by the entire process (RSS: Resident Set Size).

Since the beginning of the Java platform, we were able to package an entire application into a binary file. Thanks to GraalVM, Quarkus drastically reduces the size of the binary. All in all, Quarkus is low in resource consumptions.

And finally, Java.

Quarkus is polyglot, as it supports several JVM languages and, thanks to GraalVM, can also support all the languages such as C, C++, Ruby, or JavaScript. But Quarkus is Java first.

Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards

Kubernetes Native.

From the beginning, Quarkus has been designed around the container first philosophy.

By producing small binaries with fast startup, Quarkus is perfectly suited for orchestration platforms like Kubernetes.

Quarkus comes with Docker images and Kubernetes extensions to easily package and deploy applications.

By supporting Kubernetes natively, Quarkus has been a so‑called Knative and cloud native platform since its creation. Of course Quarkus can deploy your application in any environment, but it keeps Kubernetes in mind.

Java HotSpot and GraalVM.

HotSpot comes first in the definition because it's important for Quarkus to target the mostly used JVM.

But Quarkus brings also support for GraalVM. GraalVM support has been an important part of the design of Quarkus from the beginning.

When an application is compiled down to a native binary, it starts much faster and can run with a much smaller heap than a standard JVM.

Java libraries and standards.

Quarkus is a new toolkit, but its programming model isn't new.

In fact, it builds on top of proven standards such as Eclipse MicroProfile or frameworks such as Vert.x or JAX‑RS.

Instead of reinventing the wheel on common technical use cases, Quarkus prefers to integrate well‑known libraries.

In fact, it integrates with hundreds of libraries. But Quarkus is not limited to standards or known libraries. If you have an in‑house library running on top of a JVM then it will work on Quarkus.

Open source

It is important to mention that Quarkus is open source under an Apache 2 license, and all its code is on GitHub at github.com/quarkusio.

Anybody can join and participate to Quarkus development.

Quarkus is about supporting the best Java libraries and standards through its extension mechanism, but it is also an ecosystem of ever growing extensions.

This never‑ending ecosystem is called Quarkiverse. Quarkiverse is a GitHub organization providing repository hosting, including build, continuous integration, and deployment of Quarkus extensions, mostly contributed by the community.

Operational concern: Cloud / on-premise

Java is born in 1995 and at that time was mostly used to write graphical applications, such as applets. The language was based on the available hardware, using single core CPUs and multi‑threads.

Quickly, the language moved to the server side, and we started developing monolithic applications designed to run on huge machines 24x7 for months, even years, with lots of CPU and memory.

The JVM startup time was not an issue. The memory used by the JVM was huge, but we just let the just‑in‑time compiler optimize the execution over time and let the garbage collector manage the memory efficiently.

Today, we don't have huge machines, we have small ones that we can easily discard. We moved from single cores, multi‑threads to multi‑cores, and we tend to be careful on the number of threads as they consume a lot of resources.

Slow startup time and resource consumptions don't fit well in our new environment where we need to deploy hundreds of microservices into the cloud, move them around, and stop and start them quickly.

Instead of scaling an application by adding more CPU and memory, we now scale microservices dynamically by adding more instances.

Today, we need small binaries with small footprints and low resource consumptions.

So the industry went from running a monolith on a huge machine to scaling up and down smaller microservices or functions on several small servers, to orchestrating tiny functions moving around constantly, having to start in a few milliseconds to handle a request and stopping immediately.

Java wasn't suited for this new environment.

Today, being on the cloud or on‑premise, applications are usually deployed on a container platform. On top of these platforms, you can run so many JVMs.

JVMs consume resources, memory, startup time, so the density is low. That's why we've seen other technologies and languages emerging in the cloud, such as Node.js or native languages such as Go.

For the same amount of resources, the density of applications written in Go is much higher than in Java.

The goal of Quarkus is to get the same density, but using Java platform instead of moving to a new one or a new language. What this means is that Quarkus is optimized for low memory usage, small binaries, and fast startup time.

Quarkus allows to benefit for better operational model both in cloud and on-premise data center.

Where does it come from ?

Quarkus is driven by Red Hat. In 2006, Red Hat acquired JBoss, who was developing the JBoss application server, and this way entered the Java ecosystem.

Then, Red Hat started to work on Java's Standard Edition by committing to the OpenJDK, but also the Java Enterprise Edition or the MicroProfile.

Recently, Red Hat started to get involved in GraalVM and distribute its own addition called Mandrel. It also started hosting application with its own cloud platform called OpenShift.

Quarkus came from an open source company who was a Linux operating system, commits to the JDK and GraalVM and host application to the cloud, the same company that gives Quarkus production support.

The company JBoss was created in 1999 and started developing the JBoss Application Server, later known as JBoss EAP, for Enterprise Application Platform.

In 2014, JBoss Application Server was renamed WildFly. WildFly, for the free and open source software, and the name JBoss Application Server stayed for the supported product.

In 2015, Red Hat created this innovative approach to packaging and running Java Enterprise Application. It was called WildFly Swarm and then renamed to Thorntail. Thorntail didn't last long, and its end of life was announced in 2020.

But Thorntail brought a set of new ideas that were introduced in Quarkus in 2018. 2018 was the year of the first Quarkus public commit.

Quarkus 1.0 was then released in 2019, and since then has evolved at a rapid pace, nearly one release per month.

Quarkus entered version 2.1 in June 2021. Even if Quarkus was created in 2018, it comes from a company that has a long history of open source, Java runtimes, distributed environments, microservices, and cloud environment.

How does Quarkus work ?

GraalVM

Before talking about the internal architecture of Quarkus, we need to present GraalVM.

Quarkus targets the HotSpot VM of course, but it was also built with GraalVM in mind.

GraalVM is an extension of the Java Virtual Machine to support more languages and several execution modes. GraalVM is itself implemented in Java.

Running your application inside a JVM comes with startup and footprint costs. To improve that, GraalVM has a feature to create native images for existing Java applications.

This improves the performance of Java to match the performance of native languages for fast startup and low memory footprint.

This is the entire spectrum of GraalVM:

Graal compiler

At the heart of GraalVM comes the Graal compiler.

The Graal compiler is a high‑performance compiler written in Java. It accepts the JVM bytecode and produces both dynamic and static compilation for native code.

Here we are not talking about the Java compiler written in C which takes the Java code and compiles it into bytecode.

On the dynamic side, it uses the new JVM compiler interface to communicate with the good old job HotSpot VM.

Java HotSpot VM

The HotSpot has a just‑in‑time compiler known as JIT, which starts interpreting the code and then compiles it. The HotSpot supports all the known JVM languages, such as Java, Scala, or Groovy.

Substrate VM

On the other side, for the static compilation, the Graal compiler relies on Substrate VM. Substrate VM allows ahead‑of‑time compilation or AOT for applications written in various languages. This ahead‑of‑time compilation improves the startup time by loading precompiled classes.

With Substrate VM everything is compiled so JIT is not necessary, as well as metadata around code usage. Classes are compiled so there is no need to keep information for dynamic compilation and linkage.

There is a garbage collector which is simpler than the OpenJDK ones. RedHat and other entities are currently working on GC algorithm improvements for Substrate VM.

Truffle framework

On top of all that, you will find the Truffle framework that enables you to build interpreters and implementations for other languages, such as R, Ruby, JavaScript, or Python.

Sulong

Then comes Sulong for what we call LLVM‑based languages, such as C, C++, or Fortran.

When we talk about Quarkus on GraalVM we are talking about the following parts:

Let's focus on what interests Quarkus the most: ahead‑of‑time compilation.

When developing a typical Java application, you have your own business classes. You rely on external libraries and the JDK classes.

To get native images, you also need to include the necessary components of Substrate VM. Typically, these components are memory management or thread scheduling.

At the end, your application consists of thousands and thousands of classes. Before compiling natively, the image generation process employs static analysis to find any code reachable from the main Java method.

These reachable classes form what's called the closed world. Then, it's just a matter of eliminating all the classes and methods that are not used by your application. This is called dead code elimination.

Then, thanks to ahead‑of‑time compilation, the remaining Java code is compiled into a standalone executable called a native executable or native binary for the platform you are running into (MAC, Linux, etc...).

Thanks to dead code elimination, the final executable is smaller. And thanks to ahead‑of‑time compilation, the resulting native binary contains the application in machine code ready for its immediate execution.

The end result is an application that is faster to start and uses a smaller amount of memory. This is why Quarkus is a great runtime for containers, as well as cloud native and serverless deployments.

Internal Quarkus architecture

Quarkus can run on both JVM, the HotSpot with its just‑in‑time compiler, and GraalVM VM with ahead‑of‑time compilation.

Quarkus does a lot of things from persistence to transaction to microservices, reactive messaging, and so on.

So you might think that its core is huge and implements hundreds of features. Well, this is not the case, Quarkus is made of a small core on which relies hundreds of extensions and from an end-user point of view we only see Quarkus as a maven or gradle dependency.

In fact, the power of Quarkus is its extension mechanism. Persistence, transaction, fault tolerance, security are all external extensions that can be added to your application only if needed.

And next to these extensions, you can add an infinite number of external third‑party or in‑house libraries.

The core of Quarkus and this extension mechanism is heavily based on Arc, a lightweight dependency injection framework.

The core of Quarkus also does the hard work of rewriting parts of the application at build time.

For that, it uses a set of tools such as Jandex, which is the Java annotation indexer and reflection library to optimize annotation processing.

Gizmo is a library used to produce Java bytecode. And thanks to the Graal SDK, Quarkus can use a single path, single class loader, and dead code elimination mechanism. Quarkus uses Jandex to index classes and Gizmo to produce bytecode, but at build time, not at runtime.

Build time vs runtime

Quarkus is the way for frameworks to embrace GraalVM idiomatics.

It requires to change the way frameworks work, not really at runtime but at startup time. Most of the dynamicity that a framework brings actually comes at the startup time and this is what is being shifted to the build time with Quarkus.

Quarkus could be also highlighted to be a framework to makes frameworks start at build time.

At startup time a framework (like Hibernate or Spring for instance) does usually the following:

Parse config files (e.g.: persistance.xml file for Hibernate)
Classpath and classes scanning for annotations (e.g.: Entity, Bean, etc...), getters or others metadata
Build metamodel objects from all those above information on which the framework will run at runtime. For instance Hibernate doesn't keep .xml files in memory but builds an internal model that is represented at runtime and it is this model that is used at runtime to save entities, etc...
Prepare reflection (will get the reference to method object and field to be able to perform invoke) and build proxies
Start and open IO, threads, etc... (e.g.: database connection, etc...)

Conceptually, when you look at those steps, there could be easily done at build time instead of at startup time.

Everything that is prior to the last step and even some parts of the start can be done at build time.

This is what is done by Quarkus, it takes a framework like Hibernate and makes it work so that the maximum of steps can be performed at build time.

This represents the Quarkus build process:

There are several advantages to this approach:

You do this work only once at compilation time and not at every startup.
The percentage of classes/lines of code that are specialized for the startup time in a framework can be very high. Since the work is done at build time, these classes, can be removed by the dead code elimination, or not loaded when running on HotSpot VM. Hence the startup time and the memory consumption are lower.
In the JVM, one thing that is particularly slow is to load classes and scan them. Because loading the bytecode means that we need to verify it, etc... without even having initializing the classes.
In Quarkus, Jandex tool performs a quick JARs indexing by only reading the files without analyzing the bytecode via metadata: what is the class, what are the subclasses, what is the methods list, what are the return values, are there any annotations, etc...
Every extension uses Jandex so that instead of having to load the classes we only read those metadata. This allows to gain time.
Another trick which is applied is the following: with Quarkus, since most of the operations are performed at build time, there are steps like bytecode improvement/re-writing of bytecode that can be done at build time and in one shot. Indeed, all the improvements on the bytecode are listed and for one given class, we apply them all-at-once instead of having to re-process the same class for multiple bytecode improvement like it's usually done.
With GraalVM, static initialization is performed at build time, this approach is also used by Quarkus. For instance, for Hibernate framework, everything that can be initialized before accessing the database, is put in a static block that will be executed by GraalVM at compilation time. All this work will be included in the binary. When the application is started, this step as already been performed and the heap is put in memory and we can continue with further steps of the initialization. Quarkus really embraces this ahead-of-time compilation approach of GraalVM. This is also a game changer for Hotspot VM, since it can benefit from those major optimizations.

Extensions

You can build any kind of application thanks to the Quarkus extension mechanism.

As we've seen previously, Quarkus uses an extension mechanism, but Quarkus makes the difference between extensions and external libraries.

First of all, extensions are developed and maintained by the Quarkus team. You can find them on the Quarkus GitHub repository. They integrate seamlessly into the Quarkus architecture as they can be processed at build time and be built in native mode with GraalVM.

External dependencies are any in‑house Java framework that you've developed and maintained or external Java libraries that you can find out there.

Therefore, they are not maintained by the Quarkus team GraalVM being very aggressive with dead code elimination, some of these external libraries might not work out of the box with native compilation.

You might need to recompile them with the right GraalVM configuration to make them work. That's why not every external library is an extension.

To sum up, Quarkus works with any external library in JVM mode so you are not restricted to Quarkus extensions. But you are not sure that an external library will work on native mode and will be optimized at build time.

Quarkus has hundreds of extensions, and every release brings new ones.

One way to keep up to date is to go to code.quarkus.io and check if the technology or framework that you are looking for has been integrated as a Quarkus extension.

If it's not the case, remember that you can always use it, but as an external library. And that might not compile with GraalVM or be optimized for Quarkus, but it will work.

Here is an overview of available popular extensions:

Web extensions

Quarkus supports the good old servlet, as well as RESTEasy to develop RESTful web services. This goes hand in hand with the JSON binding and JSON processing extensions.

It also has an OpenAPI extension for documenting REST endpoints, gRPC, or GraphQL.

Database

Remember that Quarkus comes from Red Hat, the company behind Hibernate and Narayana, the robust transaction manager.

So you will get Hibernate ORM for relational mapping, Hibernate Validator to validate data, and Hibernate Envers to have historical data.

Quarkus supports several relational database JDBC drivers, such as PostgreSQL, MariaDB, SQL Server, or H2, as well as MongoDB, Amazon S3. or Elasticsearch.

Messaging

In terms of messaging, Quarkus has a JMS extension, but also supports new messaging brokers, such as Kafka or Kafka Streams.

It also has an extension for AMQP, as well as MQTT, which is the standard messaging protocol for the Internet of Things.

Reactive

In terms of reactive architectures, Quarkus goes all the way from the database to exposing reactive REST endpoints.

This is because it uses Vert.x extensively and reactive programming to get reactive messaging, reactive REST endpoints with RESTEasy, and database access with Hibernate Reactive thanks to the support of reactive R2DBC drivers.

Cloud

Being a Kubernetes‑native stack, Quarkus comes with a few extensions to build Docker images, such as Docker itself or Jib.

As well as Kubernetes and Minikube extensions to easily orchestrate microservices on your development and production environment.

It has support for cloud providers, such as OpenShift, AWS, Azure, or Google Cloud, and comes with an extension called Funqy to develop functions on top of AWS Lambda and Azure Functions.

Monitoring

When you have several microservices or functions, you need to observe them. For that, Quarkus comes with a health check extension, as well as metrics and distributed tracing.

Security

In terms of security, you can use OpenID Connect or JSON Web Token very easily. Quarkus comes with a set of extensions to integrate Elytron, Keycloack, or Vault.

Where to begin ?

I encourage you to go on the Quarkus website on which you can find a link to the coding Quarkus website.

You will be able to get hands-on Quarkus via sample applications that are package for you, you just need to unzip them and import them in your favorite IDE.

You will experience the fast startup, live reload, low memory footprint that comes with Quarkus.

After having tried out some of the Quarkus sample applications, I encourage you to have a look at the Quarkus guides.

You will find all possible information around core Quarkus mechanism such as CDI, etc... as well as guides for the most common extensions such as RESTeasy, Hibernate, Apache Kafka, etc...

References

Emmanuel Bernard talk on Quarkus DEVOXX video: Quarkus why, how and what
Oleg Selaje & Thomas Wuerthinger talk on GraalVM DEVOXX video: Everything you need to know about GraalVM
For FR speakers: Emmanuel Bernard & Clément Escoffier talk on using Quarkus with GraalVM DEVOXX video: Quarkus: Comment faire une appli Java Cloud Native avec Graal VM