Apache Camel + Quarkus

Today we will see how to integrate Apache Camel with Quarkus. Apache Camel has different projects and until now we had always seen its Spring Boot version, but today we will see our CRUD project, previously developed, on Quarkus and has its own components.

To begin with, we will explain a little about Quarkus. It is a Java Framework designed to be deployed as a native Kubernetes application. So, it is specially designed for its deployment in the cloud through containers. It is also designed to be used by OpenJDK HotSpot and GraalVM.

At first glance, this is just another framework to be deployed on another JVM. But with our usual JVM and Spring we don’t need anything else, Why would we want to use it?. We have to emphasize that it is highly effective. It allows us to have a much better performance and memory consumption than with our usual JVM or Framework. In this post, we will see how to install it and, in the end, we will test its performance comparing it with a version of Apache Camel with Spring.

We can make it work in a JVM 8 or 11, but it is better if we install GraalVM. Once we have the JVM ready, we will start with the creation of our project.

Our project will inherit from camel-quarkus-bom:1.1.0, it will have the SQL libraries for the DB connection and the Rest and Netty libraries for the HTTP connection. One of the main disadvantages when making a project with Apache Camel and Quarkus, is that the components and documentation are not so tested or elaborated, as it can happen in comparison with those of Spring Boot.

The code will be similar to Apache Camel + Spring Boot project. We will have a class that will agglutinate the Routes that we develop. And we will have an application.properties file where we will indicate common aspects and the dataSource.

What we will not have is a class, like in Spring, that allows us to start the application and debug it easily in eclipse, this can be another disadvantage when developing. To start the application we can do it through maven commands:

mvn clean compile quarkus:dev

Once we have developed our application, we will see how it behaves. And to create an image of both applications, we will deploy them in a docker-compose with Portainer and test them with the utility Hey.

The Docker image is very similar to the one we used to create with Spring boot, but in this case, we will have a Kubernetes-native application with a runner suffix. To create this package, if you have GraalVM installed, use the following command:

mvn clean package -Pnative -Dquarkus.native.container-build=true \
-Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-native-image:20.2.0-java8 \
-Dquarkus.native.container-runtime=docker

And now we would proceed to create the image. Dockerfile Example

FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /work/
COPY target/*-runner /work/application
RUN chmod 775 /work
EXPOSE 8099
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

Now we proceed to start our docker-compose and execute the following Hey command.

hey -n 1000 -m GET -T "application/json" http://localhost:8099/book/1

Over Quarkus, Hey give us these results. Average: 0.0757 secs

And Portainer these others. 200 MB RAM and minimum CPU consumption.

If we run the same on an Apache Camel + Spring Boot application. Hey gives us these results: Average: 0.1712 secs , much more than Quarkus.

And Portainer these others: 400 MB of Memory and CPU consumption also low but much higher than Quarkus.

As you can see, a big difference. Enough to make us choose Quarkus over Spring Boot. Especially if it is a basic application that we will not need much documentation or help from the forums.

As always you can see all code, here.