How Quarkus Improved Logicdrop's Developer Experience and Process - Quarkus

Blog How Quarkus Improved Logicdrop's Developer Experience and Process
Logicdrop provides a business automation and data intelligence platform that enables enterprises to design their own solutions and run them in the cloud. We process millions of transactions a month across a global client-base and add significant value to mission-critical processes.
The developer experience plays an important a role in the adoption of any technology. Being able to go from ideation to delivery, quickly and confidently, helps foster innovation and contributes to delivering a world-class product.
We make the complex simple for our clients so, how can we do the same for our own development process?
While everyone else focuses on how to change the world, we will focus on how to change ourselves from within first.
…​this starts with our adoption of Quarkus.
Development of our platform started over 3 years ago. Quarkus was barely a rumbling, Kogito wasn’t even a thing yet, and I managed to slip in the middle name "Jenkins" for my son because it was still a popular build system.
It’s 2020 now, we are still using Spring Boot but fully embracing Kubernetes and other technologies like Knative, Kamel, and Ignite, just to mention a few.
With these great advancements in our platform, and the features they brought about, came great complexity and this is where the journey starts…​
As our platform evolved and the complexity increased, our developer process was becoming more of a chore and dependencies between technology teams, front-end, back-end, and operations, started to become a bottleneck.
Well, we did what any self-respecting computer scientist would do and looked at the data. What was causing this shift and stopping us from being more agile?
After some analysis, we quickly uncovered three major pain-points:
It’s too hard to setup the environment
The learning curve was too steep
Our CI/CD process was automated but not enough
Enter 2021. Our goal is not just to get back to status quo, it’s to introduce major improvements to our process and make the jump head-first into becoming cloud-native!
Like the website says, it really is pure developer joy.
Before jumping into Quarkus we evaluated many stacks, Spring Boot, Micronaut, even Guice was a consideration at one point. We also looked at more drastic changes like switching over to Python or .NET Core.
At the end of the day, Quarkus won us over because it is the Java, we all know and love, but on steriods when needed, and was:
Quickly picked-up by developers
The easiest to become productive with
A rich and cohesive ecosystem
Able to handle reactive or imperative naturally
Kubernetes and Knative friendly
Based on standards we were already familiar with
The deeper we explored Quarkus, the more we began to appeciate other aspects:
Guides that were simple enough to get started but applicable to real-world tasks
A super responsive and helpful community, especially the core developers
At this point we decided to take the plunge but, rather than retrofit our existing platform, we would start from a clean slate. At the same time, we would push the envelope further and completely overhaul our CI/CD process, clusters, and most importantly, our developer culture.
The lead architect responsible for prototyping says:
In less than a month I’ve already implemented and deployed at least three new significant prototypes using Quarkus. I can’t believe two of them have been rejected already.
Since we approached this as a ground up rewrite of our existing Spring Boot platform there were many changes that needed to happen. The codebase was new but patterns were the same and using Quarkus we were able to implement them easier, faster, and better.
VSCode was able to become our defacto editor
AutoConfigurations and wasted dependencies went away (big win)
DI became predictable not magical (big win)
Using standards made development, and learning, the codebase easier
Mongo and Panache did just what we needed nothing more
Kubernetes configurations could be kept closer to the service
Mutiny made writing reactive services way easier for everyone
No more reflection to scan "beans" to help configuration or DI