Spring is currently the reference framework in the construction and implementation of microservices. This runs in the JVM and offers us many integration and development possibilities. On the other hand, we have Quarkus, which unites a set of open source technologies adapted to GraalVM and HotSpot, to develop Java applications, which offer us low memory consumption and a very good startup time.
In this new post of refactoring Spring Boot Vs Quarkus – The battle is about to begin, we are going to see and analyze the boot times and memory consumption between Quarkus and Spring Boot. All doubts will be explained.
Although Java is still one of the predominant languages, its performance problems have always been evident. This has been partly due to the layers of abstraction that exist between the code and the machine, with a JVM acting as the real machine. This is the cost to pay for having a multiplatform language.
Next, we are going to compare two different applications, one in Quarkus and one in Spring Boot. We are going to launch both applications several times, creating and destroying the containers and see that they are running and working correctly and compare the startup time and memory consumptions.
Quarkus is a native Java framework for Kubernetes, whose main objective is to work under Kubernetes and in a serverless environment. Unlike other Java frameworks, Quarkus runs under GraalVM and HotSpot.
Spring Boot is the current de facto framework for microservice development and works under the JVM. To continue, we are going to need to build and boot a docker image of our Spring Boot application that will return a simple Hello World when a controller is called so that it will be the same as the Quarkus project we have.
Boot times are always important, but when we are in cloud environments or Serverless architectures they become more relevant. For example, when we want to scale a service due to heavy demand, startup time will be of paramount importance. In general, the application with native Quarkus starts up in much less time than Spring Boot (Quarqus time is negligible), even if we try doing it with an image generated with JVM, it is also much less. With this we see, how the times using Quarkus in native mode are incredibly good, with this, it is clear that Quarkus has been developed with the objective, to be a native Java framework for Kubernetes and containerized environments.
In this case between Quarkus JVM and Spring Boot, we have hardly seen any difference in CPU usage, but when we use the native Quarkus image the consumption is considerably lower than with the rest, the consumption in the percentage of CPU drops drastically.
As we have seen, Quarkus has won in all scenarios, but for that reason, we could not say that Quarkus should be the reference framework. Before the decision can be made, more tests would have to be done in environments and with real loads.