Suomen Asiakastieto Oy chooses Quarkus for their microservices development

Suomen Asiakastieto Oy has many different departments: Risk Decision, SME & Consumer, Customer Data Management, Digital Processes. Real Estate and Collateral Information, which operates within Digital Processes, had deployed to their application server instance a new application, which happened to have issues while running in production affecting the stability of the application server and hence other applications running on it. This resulted in the need to reboot the application server every time this anomaly occurred leading to unexpected downtime and to a negative customer satisfaction.

Because of this, they decided to adopt microservice architectures to introduce better resilience and high-availability into their solutions so that if a microservice or an application went awry, it would not affect the entire system. So, when the time came to start developing their PSD2 project, they decided to start implementing microservices in Thorntail, which is an open source application assembler - similar to Spring Boot - that also implements MicroProfile, an community-driven open source specification for Java microservices. They decided on Thorntail because its functionality and capabilities were close to the application server capabilities they were familiar with. After being in production for a few months, they learned about Quarkus and its innovative approach that rethinks Java for containers, cloud and Kubernetes. Around the same time, they also learned about the end-of-life of Thorntail. Their continued desire to develop new microservices as well as to break their monolithic application servers into microservices made them evaluate Quarkus more in depth.

With respect to their monoliths, they have about twelve JBoss EAP instances, each running dozens of their applications. As a first step to make the entire system more distributed, they decided to start moving some of these workloads to OpenShift by running many instances of JBoss EAP, each containing a single application. As a result, they experienced high memory consumption. At this point, they started looking into ways to reduce the footprint of these applications running on OpenShift.

With respect to their existing Thorntail microservices, which they needed to migrate to Quarkus, they noticed that spinning up a Thorntail container was taking about 1 minute to start up. When they migrated it to Quarkus, the service now starts in 0.4 seconds! With this improved startup time, they could scale up their services faster so that they could be readily available faster to process extra traffic leading to a better customer experience during peak times since customers would not have to wait on the browser to have their requests serviced, for example.

In fact, before going into production with Quarkus, Eero Arvonen, Solution Architect at IT Development Finland Asiakasieto Oy, made a comparative analysis between the Thorntail and Quarkus versions of a microservice. This first chart shows a comparison between the original version of one of their Thortail microservices, which used JAX-WS, next to different Quarkus versions of the same microservice.

This next chart shows the performance and startup time results for the same combinations of microservice versions as the previous graph.

According to Eero, “migrating from Thorntail to JVM-Quarkus was trivial and memory consumption went down by about 75% while CPU consumption was reduced by about 70%. This was accompanied by a 40% increase in throughput resulting in a faster response time. Migrating to Quarkus native, we found that the application ran at a better throughput even with 50MB of memory which is 95% less than with Thorntail. We also identified a space-time tradeoff between different native Quarkus setups: deploying it with 200MB of memory instead of 50MB will reduce its CPU requirements by two thirds. Thus, if we ever had to balance CPU vs memory within our OpenShift cluster, this would prove useful.”

They use and like the Quarkus development mode, also known as live coding, a lot. Before Quarkus, they used to use JRebel, for hot replacing but it was unreliable. According to Eero “Quarkus development mode has by far a better track record.” Now that they are writing new microservices, they have made it a best practice to use live coding. With Thorntail, there were manual steps to deploy changes to try them out whereas with Quarkus, the changes are automatically applied to the running process so that the developer can immediately test the application. This makes developers more productive in that they can verify and troubleshoot their code faster. Eero took it upon himself to deliver a small internal Quarkus workshop, which got developers very excited about this new and innovative technology, “people are looking forward to working with Quarkus”, mentioned Eero. Quarkus is getting developers excited and this has led to other developers across the organization to use Quarkus for their projects.

“Quarkus was very easy to pick up”, according to Eero. In his opinion, the Quarkus guides on https://quarkus.io/ are very good, thorough and comprehensive with great code examples. In addition, he found a very active community in Quarkus. When they ran into problems, they were able to search the internet for the error messages and easily found answers online. In addition, the Quarkus community and Quarkus engineers are very active even on external forums answering questions and helping folks inquiring for help.

As awesome as Quarkus is, this constantly evolving and innovative technology had some areas for improvement. For example, Eero mentioned that Java API for XML Web Services (JAX-WS) didn’t work on native mode. Also SSL, by default, is disabled but available for HTTP/S, which he needed to use and got it to work following the configuration instructions, which he found complex. In addition, he would like to see improvements in how reflection is currently configured, which was time-consuming to configure because he had to use a trial-and-error approach to get it to work. He’d like to see a way to make this reflection configuration process easier to carry out.

Because Quarkus takes the approach of a closed world for application development, there needs to be a bit of a mind shift when writing applications. As an example, for their existing applications, Asiakastieto used a configuration manager to read in configuration information (connection URLs, DB connections strings, etc.) at application startup. Since with Quarkus, in native mode, part of the application startup happens during build time, they had to reconfigure the configuration manager to read in the configuration information when the application was run. Although the change was easy to make, it highlights the importance of understanding how Quarkus applications need to be implemented under this new paradigm.

As mentioned earlier, the Asiakastieto Oy PSD2 project had been implemented in Thorntail microservices and when they learned about Quarkus, the decision was made to migrate their Thorntail microservices to Quarkus. As of this writing, out of the 7 Thorntail microservices in their PSD2 application, one has been migrated to Quarkus and is running in production.

Two more microservices have been migrated from Thorntail to Quarkus (native mode) and are currently being tested and will be deployed during their next incremental application update during February 2020.

When their microservices initiative started one and a half years ago, Asiakastieto Oy decided to use Thorntail as their main technology for Java microservices. With the news of the sunsetting of Thorntail and the introduction of Quarkus, they have established a new policy that every new project will be implemented in Quarkus in JVM mode as a minimum and when feasible use Quarkus in native mode. There are already two new projects that are being implemented in Quarkus at present with more coming in the future.

For more information on Quarkus: