Why Quarkus should not be considered as another Spring clone

Quarkus was introduced to the world in 2019 as an alternative to Spring Boot framework. It was tailored for contenerized environments and provides low memory usage and fast startup times.

What is Quarkus?

Quarkus is an Open Source project that was created to enable Java developers to create cloud-native applications. Traditional Java stacks (for example, Spring) evolved from large monolithic applications in which complex dependency management and ease of configuration were achieved at the expense of large memory requirements and long startup times. Quarkus is different. Its main purpose is to allow applications to quickly scale up and down their microservices and optimize container density through memory utilization.

Since there are already plenty of articles focusing on how quick Quarkus really is, let’s try to look at it from a different angle. Switching from the beloved Spring can be a stressful and unappealing adventure for developers. Understanding how Quarkus is built and the reasoning behind certain architectural choices can help you decide which framework is best for your upcoming projects.

Is Spring suited for microservices?

Spring and its concepts are very mature. Spring derives from shared environments like application servers, where each application has its own set of system requirements. It has traditionally focused on three-tier monolithic architecture, with gradual, measured evolution and a strong emphasis on backward compatibility. It also relies heavily on dynamic runtime logic with Java reflection. Spring based applications tend to have high RAM utilization and a slower startup time due to the large amount of work needed at their startup.

Quarkus, being a microservices oriented framework, implements MicroProfile specifications. It is a set of specifications developed by the community to optimize Enterprise Java for a microservices architecture. It was founded in 2016 by IBM and has been constantly evolving up until today. Quarkus is kept continually current with MicroProfile releases.

The joy of the development process

Live coding seems to be the most outstanding feature at the beginnig of one’s journey with Quarkus. Every change to your code is immediately visible in your API. Is this magic? Not really, but it sure feels like it. After receiving a request to an endpoint, Quarkus will hold the request and check to see if there have been any changes to the application source files. If anything has changed, the application will be transparently compiled and redeployed. The HTTP request will only then be continued. All but the largest applications are completed in the blink of an eye.

There is one downside to the dev mode that I have observed over the time and you may encounter it if your service is not stateless. In that case, every request will take you back to a fresh start with every change to your source code. Fortunately, in such cases, you can disable the developer mode and use the good old run from jar.

Live coding is not the only facilitation that the dev mode provides. One of them is a useful user interface attached automatically to the application you are building. This UI allows the developer to see and change the state of the application. What exactly might be changed depends on the extensions that are present in the project, but some of them are: changing configuration, running database migration scripts, clearing caches, or running scheduled operations.

Other useful features of dev mode are: detailed error pages, which simplify the error diagnostic process; dev services, which give you access to an instant database, message queue, keycloak and many other services right out of the box; mock mailer, which prevents you from sending unwanted emails during development and testing. The list goes on and on. Simply put, the Quarkus team is doing its best to help the developer focus on the task and to speed up the feedback loop.

Reactive approach

Another reason for going with Quarkus might be the way it handles both reactive and imperative architectures within the application. Thanks to Quarkus’ tight integration with Eclipse Vert.x you are free to choose between blocking and non-blocking libraries and APIs. Most of the time, developers are able to combine blocking and reactive APIs in the same classes. Quarkus makes sure that the blocking APIs block when necessary while the reactive APIs continue to be non-blocking.

Meanwhile, using Spring, the decision of application architecture needs to be made before writing a single line of code. Such a choice determines the total number of libraries that are available during the development of an application. Quarkus, having been born in a reactive era, was able to address the issue and leaves the freedom of handling specific interactions until the very last second.

Kubernetes native

More and more applications are designed with the assumption that Kubernetes is going to be their underlying deployment platform. In order to achieve the best performance at the lowest possible cost, there are a number of requirements that need to be taken into consideration: low memory consumption, fast startup, minimalization of system threads, usage of Kubernetes ConfigMaps, health endpoints exposure and others.

Quarkus was designed from the ground up with those principles at its core, with an emphasis on memory efficiency and quick startup times. Processing is completed as much as possible at construction time. Classes that are only utilized at application startup are called at build time rather than loaded into the runtime JVM, which reduces the size of the program operating on the JVM and, ultimately, its memory footprint.

Because this architecture anticipated native compilation from the start, Quarkus may be described as “Kubernetes native.” Comparable native capabilities in Spring are still regarded as experimental, beta, or perhaps not available in some cases. More Quarkus apps can be deployed within a given set of resources than other Java or Spring applications when combined with a runtime platform like Kubernetes.

Summary

If you’re facing a problem that might be resolved with microservice architecture, your application is going to be deployed on Kubernetes, you want to use the full potential of a reactive approach or you simply want to play around with something “new and sexy,” I strongly advise giving Quarkus a chance. The satisfaction of trying something new and discovering that it is already thoughtful should be sufficient. Besides, as stated at the beginning – Quarkus is not a Spring clone. Like a hammer and a screwdriver, both are tools we all should have and use whenever applicable.

References

• https://quarkus.io
• https://www.manning.com/books/kubernetes-native-microservices