Spring is currently the reference framework for building and implementing microservices. It runs on the JVM and offers us many integration and development possibilities. On the other hand, we have Quarkus, which combines a set of open-source technologies adapted to GraalVM and HotSpot to develop Java applications that offer us low memory consumption and very good startup time. In this new entry Quarkus Vs Spring Boot – The battle is about to begin, we will see and analyze the startup times and memory consumption between Quarkus and Spring Boot.

Although Java remains one of the predominant languages, its performance problems have always been evident. This has been partly due to the abstraction layers that exist between code and the machine, with a JVM that acts as a real machine. This is the cost to pay for having a cross-platform language.

Starting the fight

Next, we will compare two different applications, one in Quarkus and another in Spring Boot.

We will launch both applications several times, creating and destroying containers and checking that they are running and functioning correctly, and compare the startup time and memory consumption.

Quarkus – Opponent 1

As we mentioned in a previous post, Quarkus is a native Java framework for Kubernetes, whose main objective is to run under Kubernetes and in a serverless environment. Unlike other Java frameworks, Quarkus runs under GraalVM and HotSpot.

Next, we will start with the example we made in the first steps with Quarkus, to have an application ready in a container. You can download it from GitHub here. The previous link explains each and every one of the necessary steps to start the Quarkus project.

Spring Boot – Opponent 2

Spring Boot is the current de facto framework for microservice development and works under the JVM.

To continue, we need to build and start a Docker image of our Spring Boot application that will return a simple Hello World when a controller is called, so that it is the same as the Quarkus project we have. You can find an example here.

In this case, we do not explain in the repository how to containerize and start a Docker image of the project, so let’s do it:

Create Dockerfile:

FROM openjdk:11.0-jre
ADD target/spring-boot-0.0.1-SNAPSHOT.jar app.jar
ENV JAVA_OPTS=""
ENTRYPOINT exec java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9999 -jar /app.jar

Build the image:

docker build -t spring-boot:0.0.1-SNAPSHOT .

Start the image:

docker run -p 8080:8080 spring-boot:0.0.1-SNAPSHOT

Fight!

Startup times

Startup times are always important, but when we are in cloud environments or serverless architectures, they become even more relevant. For example, when we want to scale a service due to high demand, startup time will be of vital importance.

In the graph, we can see how the native Quarkus application starts up in a much lower time than Spring Boot (the Quarqus time is imperceptible), even if we try it with an image generated with JVM, it is also considerably lower. With this, we see how the times using Quarkus in native mode are incredibly good, making it clear that Quarkus has been developed with that objective, to be a native Java framework for Kubernetes and containerized environments.

And the winner is Quarkus

Memory consumption

Just as we have compared startup times using Quarkus with JVM and GraalVM, we will now look at container memory consumption, always at startup time:

And the winner is Quarkus again….

CPU Consumption

In this case, we are going to look at the CPU consumption of the containers during startup.

In this case, between Quarkus JVM and Spring Boot, we have barely seen a difference in CPU usage. However, when we use the native Quarkus image, the consumption is considerably lower than the rest, and the percentage of CPU consumption drops drastically.

And the winner is Quarkus native

Conclusion

As we have seen, Quarkus has won in all scenarios. However, we cannot say that Quarkus should be the reference framework for this reason alone. Before making a decision, more tests would need to be done in real environments and with real workloads, such as how it would perform in various pods, etc.

Moreover, in cloud environments, one of the underlying problems is the issue of cold start, and it would be necessary to see how it behaves in these scenarios, for example, in a serverless world:

• The function has been implemented, but it has not yet been activated.
• The function has been inactive long enough for the function provider to remove the resources that were used during the last call.
• We are going to scale the function to increase capacity by creating a new instance.

In general, we can say that we have seen better resource usage metrics, both in startup times, memory, and CPU usage, especially when creating a native image because it compiles the code in the CPU instruction, rather than the JVM bytecode.