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.
The Challenge
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!
What Actually is Quarkus?
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:
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.
Lead Architect
Change is Inevitable
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
-
Security worked out-of-the-box and was well defined (big win)
-
REST clients helped isolate services cleaner and better
-
OpenAPI and Swagger worked without tweaking
-
Intimate knowledge of Maven was no longer required
-
Testing became easier and consistent
-
CI/CD orchestrates all services together rather than each one separately
-
Preview environments were introduced to deploy/test services in isolation
-
No more bloated dependencies
-
Livecoding just made everything better
And the list keeps going…
All the developers are finding Quarkus easier to pick up, even the Python and .NET developers, and embracing it:
Quarkus makes developing Java easier and more efficient than ever. No longer do I have to switch between multiple terminals to find the right one to rebuild my code, Quarkus makes it automatic.
Full-Stack Developer focused on rules and big-data
The deep integration with Kubernetes futher minimized complexity and brought our services closer to being cloud native. Our DevOps engineer, who used to be a developer, says it best:
Does this mean I can go back to writing code since I don’t have to deal with service configurations anymore because Quarkus does it for me?
DevOps Engineer
Front-end developers are comfortable enough with Quarkus to be able to read the code, at least, and can help with debugging or testing:
I finally have a full environment setup locally and I can understand what is going on. Now, I can find the bugs without having to wait at least.
Front-end Developer
Do I Need Native Images?
Native images were originally one of the features we were least concerned with but guess what? They worked great with almost no issues.
We now deploy containers that are ~50MB, down from 200MB. That goes a long way for cluster density but also saves a ton of money on cluster nodes.
Additional the native images startup in less than 1 second, down from 10+ seconds in some cases.
So, if you can build and use native images, why not if you can? It can pose some interesting challenges when incorperating into your CI/CD process and testing but nothing that has been a big issue.
Measuring Success
Six months later and almost everything has been rebuilt from the ground-up.
Introducing Logicdrop Fusion, our new cloud-native platform powered by Quarkus.
Over 60% of our codebase has been migrated and it is less than half the size of the original equivalent codebase. We deploy numerous times an hour/day into preview and staging environments and the average turn-around is half the time it used to take us.
What are the big wins we accomplished by moving to Quarkus?
-
Onboarding and ramp-up takes days instead of weeks
-
The codebase is smaller, tighter, and easier to work with
-
Increased productivity and quality
-
Java is fun again
And all of our developers have enough working knowledge to build, test, and deploy services in hours not days or weeks.
The result of an easier learning curve as one developer explains:
It’s nice to just inject dependencies as I would expect and start coding without having to deal with a bunch of boiler-plate configuration. I can focus on what I have to do now rather than how to get there first.
Java Developer
If you think about it, we had to learn Quarkus and redo everything from scratch. Now, after just a short period of time, we are deploying production-ready code. That is pretty darn cool, and it shows how easy it was to adopt Quarkus.
To Quarkus…and beyond
We are fully vested in Quarkus at this point. It is the heart of our new platform, and the only regret is not making the jump sooner.
Our roadmap for the rest of the year:
-
Continue expanding our Quarkus foundation
-
Evangelize Quarkus across teams and clients
-
Harden the platform
-
Integration with Kogito
And it goes without saying, introduce features as fast as we can because Quarkus has enabled us to do that better!
A typical day now:
FYI, I just deployed 10 services in case you are wondering.
Slack Message
I just deployed all 10 of them again.
30 minutes later…
