In previous post I've described an example of kogito-based microservice on quarkus in native mode, containing one embedded pmml model with decision tree. While it can be successfully used for prototyping purposes, in the real life microservice might contain several prediction models. From the first view I've got an impression, that inclusion of several models should be a trivial extension of the prototype with one model. We were completely wrong in our assumption, that's the reason, why I've decided to write this post. Another reason, is absence of guides, in which 2 (or more models) are put inside DMN diagrams in kogito framework.

Very often we've heard that some frameworks fit together so good, that they are considered as "match made in heaven". In this article I would like to share our experience regarding integration of those frameworks.

This is a post about first steps and first pitfalls in modernization of old enterprise application using "supersonic subatomic java" quarkus as it is positioned by RedHat.

Initial setup

In the end of 2019 I was invited to work in a project in our company, where an old monolithic application should be split into micro-services. Basic reasoning behind this decision was, that framework which is used in application is near to it's end-of-life. The application should be rewritten in any case. If it should be rewritten in any case, why not to split it into micro-services?

Since last 10 years, I was working mostly with java and we had in the project specialists with java knowledge, we have decided to give java-based frameworks a try for back-end functionality.
OK, let's use spring-cloud for that purpose, was our first thought. But then, we have had a look onto quarkus, which has been released in the end of 2019. We have decided to give it a try, keeping in mind building of native applications using GraalVM.

Native applications from our perspective could give us following benefits:

• shorten start time of container
• reduce resource consumption of container and application

We were aware about possible drawbacks of this solution:

• no experience in our team with quarkus framework
• significantly less amount of available feedback from community, since this is very young framework