Why did Payair Technologies switch to Quarkus?

As creators of the framework are describing it, Quarkus is:

On the Quarkus website you can find information that it has been designed around "container first" philosophy, meaning that it is optimized for fast boot times and low memory usage. As a result, we should gain near instant scale-up and high-density memory utilization in container orchestration platforms.

The way this has been achieved can be summarized as follows:

Below you can see a comparison of memory usage and boot time of sample applications:

source: https://quarkus.io

What is interesting about this framework is that it is not revolutionary. Since some of Payair’s developers had mainly Spring experience, we were concerned that it would be difficult for them to “switch sides”. It turned out that our fear of the unknown was completely unfounded. Quarkus leverages some good old Jakarta EE standards that all Java developers are familiar with. We did not have to learn a bunch of new APIs that are advertised as "the best way to create REST endpoint" or "reinvented database access". Instead, Quarkus uses Context Dependency Injection for beans, JAX-RS for RESTful web services, JPA for database access and many others.

On top of that, Quarkus extends available Jakarta EE functionalities responding to modern world developers' demands. These are called Quarkus extensions and, to name a few, they contain support for reactive programming (but using the declarative approach), event messaging, etc.

Apart from a wide variety of available extensions, there is also a way to create your own, based on the library of your choice. Keep in mind though, that if you want to preserve those drastic optimizations that Quarkus offers, you will have to apply them manually to your extension as well.

I would like to stop here for a second and give a big shout-out to the Eclipse MicroProfile initiative. It specifies a collection of APIs and technologies to form a baseline for quick and effective enterprise Java microservices creation. The goal of MicroProfile is to define a specification for building microservices and deliver portable applications across multiple runtime implementations.

Optimizing enterprise Java for a microservice architecture is a challenging task and, in my opinion, MicroProfile handles it pretty well. As a long term Spring developer I realized that Spring is slowly becoming the very thing it swore to destroy. The initial premises of Spring (which basically can be summed up as a lightweight alternative to Jakarta EE) are way past the expiry date now. Spring is the undisputed heavyweight champion that can handle everything you imagine but is not your best option for fast and light services. And that applies to Spring Boot as well.

It is worth mentioning how the development process of Quarkus application looks. First of all, you are not forced to use native images from day one. Normal JVM builds are still available. Resulting JARs are not as fast as native images, but still faster than your normal enterprise applications.

This leads us to the most important thing: dev mode. The special Maven plugin allows you to quickly reload classes while you are editing them, leaving an impression of hot deployment. Changing the functionality and testing it right away without further ado is a real joy. No more distracting builds and endless context switching. Pure development mode, hence the name of the plugin.

There is one more benefit of a quick startup time. Writing RESTful applications requires significant amount of integration tests on the API level. With Quarkus on board, running them gives a unit-test-smoothness feeling and if you are even a slight fan of TDD, you will appreciate the difference.

One of my personal concerns when switching from Spring to something based on Jakarta EE was lack of Spring Data JPA. I really like the mix of simplicity and functionality this module provides. But it turned out that Quarkus has my back on this one as well. There is an extension called Hibernate ORM with Panache. It is a layer on top of Hibernate ORM which focuses on simplifying ORM to the maximum without compromising the actual power that ORM gives. Panache has managed to find a sweet spot of making it trivial to work with simple entities without giving up possibilities for handling complicated use case scenarios. Bravo to Panache and adios to Spring Data!

We are yet to implement the first release of Payair’s Quarkus application into our production environment. Based on our experiences from lower level environments, we just cannot wait for it! CI/CD is no more complex than with any other framework. We only needed vigilance while setting up native build scripts. The differences between JVM and GraalVM runtimes are negligible. Moreover, our initial performance tests are looking very promising.

On the other hand Payair has many demanding customers who happen to be financial institutions. Throughout the years we have learned that they expect global reach, high performance and high availability from our products. Our solutions must be thoroughly tested, reliable and bulletproof. We are in an industry that is very risk averse and although we are aware that others are already using Quarkus in production (https://quarkus.io/blog/tag/user-story), we need to verify this for ourselves since the framework is still considered a new player on the market.

The next step is to push our Quarkus implementation to the limits to see how it behaves under a real and heavy load. For now we believe that everything will work even better than we could have anticipated. We will let you know how it went.

For more information about Payair Technologies please visit our website: https://www.payair.com

For more information on Quarkus: