Sedona rewrites insurance premium actuarial engine using Quarkus

Edouard Lamotte, Lead Software Architect and Java team manager at Sedona, has over fifteen years of Java, Java EE and Spring Boot experience. To keep up-to-date with innovations and leading technologies, he and many of his colleagues regularly attend developer conferences like Devoxx, Red Hat Summit, etc. to learn, understand and listen to what big software vendors, communities, and organizations are talking about innovative software technologies and tools.

A couple of years ago, they learned about Eclipse MicroProfile, which they liked and thought it was a very good idea to adopt instead of Spring because MicroProfile was a community-driven Java specification for microservices. They had tried the MicroProfile implementation by Thorntail and had gained experience implementing microservices using this technology. Another reason they considered MicroProfile was because they wanted to standardize on a single technology stack and avoid having their developers mix technology stacks: one using Spring Boot, another one using Micronaut, for example. So, these were the most salient reasons why they decided to use MicroProfile.

The same way they had come across MicroProfile, about a year later they learned about Quarkus, which impressed them a lot because it implemented a wide variety of extensions and frameworks including MicroProfile. In due diligence, they researched Quarkus on the internet for comparisons of Quarkus and other technologies. They also tried different starter projects from GitHub for all these technologies: Micronaut, Thorntail, SparkJava, Quarkus. After a thorough evaluation, the reasons why they selected Quarkus were as follows:

Lastly, the application they needed to develop for their customer was not too big so they felt comfortable to try out a new technology like Quarkus. If things didn’t work out, they could roll back to a different technology.

The calculation engine can be seen as a microservice exposing REST endpoints. Sedona had been working on this architecture pattern for a few years. Microservices are usually run in containers, so the issues of deliverability with a small footprint (~75MB) and fast start up (<2s) are important considerations. Sedona used to work on Spring but this framework seemed too heavy, too resource consuming, and above all, it is not a Java standard.

Having studied and used different frameworks, such as Spark Java, Eclipse MicroProfile, Thorntail, and Micronaut, the one that piqued Sedona’s interest was Quarkus because of its container first approach and its native compatibility with a Kubernetes environment.

The client’s immediate constraints were to develop in Java, to deliver docker images, and to move to a Kubernetes environment in the near future. Quarkus was therefore the solution that met these constraints. Moreover, the integration to GraalVM seemed to Sedona to be a plus.

With this solution, they can now manage these processes centrally and all employees will use the same calculation engine for more accurate and consistent quoting.

The application was deployed to production on January 15, 2020, is running on virtual machines in a private cloud. At the time of this interview, they hadn’t seen any performance issues with the application. In the last couple of months, they have seen an increase in traffic that resulted in the scaleup of the application. Again, this happened smoothly without any issues.

An important benefit that the Quarkus application is delivering to their customer is that they will be able to handle higher traffic rates on the same hardware due to the application consuming less memory and having faster startup times. In other words, their customer will be able to get higher workload densities on their existing hardware.

The resources dedicated to this project were: one architect, one project manager, and three full stack developers (Angular, Java). They started development in mid July 2019 and went to production the second week of January 2020 for a total of six months.

The delivered Quarkus application is containerized using Docker and the management of the containers is done with Docker Compose. The configuration of the VMs is done with Ansible scripts.

For Edouard, who had Spring Boot, MicroProfile, and Java EE experience, it was very easy to pick up Quarkus; “I’m from the Spring, Java EE and MicroProfile world and Quarkus supported MicroProfile so the transition was easy”, Edouard asserted. In general, Sedona developers have strong experience with Java EE and Java technologies like Hibernate, RESTEasy, etc., and Quarkus provided extensions for all of these. This made it easy for them to ramp up on Quarkus fast. In addition, the “Quarkus documentation is very good to get started with Quarkus”, he added.

In terms of developer culture, Sedona encourages their developers to learn and be able to switch from one technology to another and this was the case with their .NET developers. One of them is Jocelyn P., who was also a member of the development of their Quarkus application. It took him about one month to start developing in Quarkus, and between 2 to 3 months, to get proficient and productive on his own. Here’s a quote from Jocelyn with respect to Quarkus:

Jocelyn P. (.NET developer): “At the beginning, it was a little bit hard to use Quarkus. But after a couple of months of use, I think it’s a good framework, easy to use and fast on the bootstrap and live reload. I particularly liked the data access overlay (Panache) which allows to perform any database reading operation without writing SQL including slightly more complex queries without altering performance even on large volumes of data. The REST client will be very appreciated with the next version of Quarkus. As Quarkus innovates, I will continue to learn and exploit its benefits and better understand all its possibilities”.

Sedona also has Spring developers. Here’s a testimonial from Mathias B.:

Mathias B. (Spring Developer): “With Quarkus, we stay on the standard to develop a complete restful backend that’s lightweight and starts up really fast. A few points that I appreciate about Quarkus are: - The documentation/guides are clean and straightforward. (we even have a quickstart on the site). - Panache entities that simplify DAO/Repositories management - Native version control integration for BDD (Flyway) (to manage database versions) - Native and simple CRON management via annotation (Scheduler extension)”.

Sedona found Quarkus' live coding capability very impressive. Edouard mentioned that “live coding is developer-friendly and very easy to use with different IDEs”. They found that they could integrate a Quarkus project easily with their favorite IDE. He added “you start your Quarkus application and you can modify your Java class and your changes are instantaneously and seamlessly reloaded”. As an example, for one of their REST-API-based applications, “it takes about 2-3 seconds to do a live reload with Quarkus, whereas with Spring Boot it was taking 30 seconds to reload”, he mentioned as he described their first experience with Quarkus vis-a-vis Spring Boot. They also found the Hibernate ORM with Panache extension very useful and helpful in speeding up development.

Another benefit that impressed Sedona was the very small time to first-response that Quarkus delivers. “Fast startup is really amazing”, Edouard stated. They think that for scaling up microservices and lowering application response times for web applications, fast startup times are very important.

At present, Edouard mentioned “we are using Quarkus in JVM mode on containers but in the future, we are already planning to use Quarkus in native mode on Kubernetes and serverless environments, where native mode will be ideal”.

In general, Sedona’s opinion of Quarkus is “clearly positive, Quarkus is the fastest framework in terms of bootstrapping and hot reload that we have used so far”.

They also develop in Kotlin, which is also supported by Quarkus.

Finally, the small learning curve experienced by their developers, the simplicity of management to configure different environments, such as development, test and production, the live coding, and the fast startup capabilities of Quarkus allowed Sedona’s developers to increase their productivity to deliver solutions faster to their customers.

It’s Edouard’s first time going to production with a technology at 0.19 version (not version 1.0 yet). This talks to the high quality and reliable software developed by the Quarkus engineers and community.

Sedona has decided to continue to use Quarkus for future projects and they believe “it’s a good bet for the future”.

Update: Sedona updated Quarkus to 1.4 at the end of April 2020. Sedona is presently starting two new Quarkus projects (in native mode), one for a microservices project and the other for a serverless project (using AWS Lambda).

For more information on Quarkus: