Ennovative Solutions uses Quarkus with AWS Lambda to deliver a better customer experience with their new product PURQR

For the development of PURQR, Ennovative Solutions decided to follow a Function-as-a-Service approach by using AWS Lambda as the serverless computing platform. When Dennis Baerten, Software Engineer with Ennovative Solutions, started his journey using AWS Lambda, he described it as “I ran into the long startup times using regular Java in AWS Lambda”. They soon realized that using plain Java on this serverless computing platform was not going to deliver the performance and experience that they were after. This is when they started to look at other options.

A colleague of Dennis’ told him to look at Micronaut, which is another framework that supports GraalVM. He tried out Micronaut but encountered difficulties getting it to work with the type of application he was building. Furthermore, there was no Micronaut plugin to build his native image in AWS. “Quarkus had more features and extensions than Micronaut that could be compiled to native (compatible with GraalVM)”, Dennis asserted. When he got started with Quarkus, one of the first things Dennis did was to enroll himself to the Quarkus Zulip channel. Dennis engaged and connected with the Quarkus community and obtained quick replies to his questions and even found some bugs in Quarkus. He was even able to apply the fixes himself via GitHub Pull Requests, which were eventually merged into the Quarkus project. Dennis expressed “I valued and was very pleased with the support from the Quarkus community, which is very active”. In addition, the fact that Red Hat was behind Quarkus was also important to Dennis. He was familiar with Hibernate and other open source technologies that are sponsored by Red Hat. He knew Red Hat was a big player in the IT world so knowing this gave Dennis the confidence in the technology. Knowing that Red Hat was a sponsor of Quarkus, reassured him about his decision to use it to implement his application.

Ennovative Solutions had tried Micronaut during the proof of concept phase. However, after learning about Quarkus and its benefits over Micronaut, they migrated everything to Quarkus. In their opinion, some of these benefits included:

PURQR consists of 7 Quarkus microservices that are currently running in production. They have been in production since October 2019.

Most of the microservices are HTTP-based and sit behind an Amazon API Gateway and at the backend they are all AWS Lambda functions. These microservices are:

Here’s a high-level pictorial of the PURQR system that uses Quarkus with AWS Lamdba:

As depicted in the logical architecture diagram above, the Quarkus-based microservices all run as AWS Lambda functions. It is worth mentioning that all these microservices run in test and production in Quarkus native mode, which leverages GraalVM native image. For local development and debugging purposes, they run these microservices in Quarkus JVM mode using AWS Serverless Application Model (SAM) on their local machines.

Lastly, “moving to Quarkus was easy. Getting everything to work in native mode took a couple of days. And it took about two months to develop the complete application”, added Dennis.

Ennovative Solutions found Quarkus to be a very valuable and rich Java stack with a wide range of capabilities to implement any type of business application. Among the many benefits that Quarkus provided to them, running Java applications in AWS Lambda functions without the downside of cold starts was one of them. Quarkus fast startup time was key here because they wanted to reduce the cold start timing of AWS Lambda functions to a bare minimum when running in both test and production environments. For example, “using Spring with AWS Lambda would have been prohibitive because the startup time of Spring in AWS Lambda is too big from my research”, Dennis mentioned ( 1 , 2 , 3 ). Also, from past experience, he had seen that “using plain Java with AWS Lambda, it was taking 6 to 7 seconds for a cold startup whereas with Quarkus it takes about 200 milliseconds”, Dennis added. However, in order to be more thorough in his research, he took one of the simplest functions (no dependency injection, logging) he had and ran it in AWS Lambda in plain Java and Quarkus native mode, the latter being a combination of Quarkus + GraalVM native image. The measurements, as reported by the AWS Lambda platform, are as follows:

In the table above, you can see a 62% reduction in cold start from plain Java to Quarkus native and a 91% reduction in execution time from plain Java to Quarkus native mode! For memory consumption, there was a 29% reduction in going from plain Java to Quarkus native.

By using Quarkus with AWS Lambda, Ennovative Solutions have been able to lower the cloud resource consumption costs, which include the use of AWS Lambda, SQS, DynamoDB, Route53, among others. Presently, PURQR has a handful of customers so their monthly costs are minimal. However, Dennis mentions that as their number of customers grows so will their cloud resource consumption costs. “As these costs increase, this is when the benefit of using Quarkus will be experienced due to its more efficient use of cloud resources and fast startup time compared to plain Java and Spring Boot”, Dennis stated.

As a Spring developer, Dennis found Quarkus very easy to learn. He mentioned “it took me about 3 days to get familiar with the Quarkus stack”. In fact, he highlighted that the fast learning curve attracted him to Quarkus as well. He was also particularly impressed by the Quarkus documentation, which "is very good", he added. Dennis thinks the Quarkus guides are very thorough and provide good detailed information. This is another reason why he selected Quarkus.

Quarkus can run in JVM mode and native mode. If you are interested in running your application in Quarkus native mode, Dennis recommends to first check if Quarkus offers extensions for your required functional requirements. For example, if you’d like to access an in-memory-data-grid (IMDG) like Kafka, he suggests you first search the Quarkus extensions to see if there’s any extension related to this need. Quarkus extensions can compile to native so it’s better to check if Quarkus offers your required functionality before you start implementing your application with a library for which Quarkus does not provide an extension. If you don’t find a Quarkus extension for the third-party library you want to use, then Dennis recommends to check the Quarkus project issues to see if there’s already a pending request to “quark” the third-party library. Also, you’d want to check with the third-party library authors/project to see if they already have a Quarkus extension or are working on one. You don’t want to find out that you can’t compile your application to a native executable after you have spent hours developing it! You want to avoid this if your goal is to compile to native. In short, the lesson learned here is “check first if there are Quarkus extensions available for what you need”, Dennis suggests.

They were not able to use live coding with Quarkus because this capability does not currently support AWS Serverless Application Model (SAM) for the AWS Lambda functions running on their local machines.

Lastly, although learning Quarkus was fast, learning the internals of Quarkus native mode was more challenging and took longer to understand.

Ennovative Solutions plans to continue using Quarkus for future development of PURQR as well as other solutions. They are extremely impressed by this new technology and the involvement and active participation of its community. About the Quarkus project, Dennis’s parting thoughts are “Great job! Keep up the good work and continue accepting work from the community.”

For more information on Quarkus: