Java has a prominent place in our technology stack at IN2. With a few exceptions, almost all of our projects, as well as products and services, have been developed using technologies stepping on top of the JVM. This is, to a large extent, thanks to the JVM’s long-term support, backwards portability, and the enormous amount of available open-source libraries and frameworks in the JVM ecosystem. Java has been with us for the past two decades of the company’s existence; it is safe to say that we are highly betting on using it in the years to come.

Of course, the JVM ecosystem is enormous and there are choices for pretty much every use case. Especially, in the web application domain, which we are most widely present in. This bears the question of why we have chosen RedHat’s Quarkus as our framework of choice for the future. And, as we have been asked many times in the past, why not the way more popular Spring Framework?

To answer it, I will need to take a stroll down memory lane as far back as 2010, the year I first had the chance to work with IN2. The company’s projects from before that era had been a mix of J2EE’s Servlet technology and a lot of custom code on our side. The year 2010 was the first time we looked at the possibility of using an application framework that would help us standardize our codebase, and get rid of the custom code we had written in the past. Of course, Spring presented itself as the default, no-brainer choice.

It is important to note here that Spring back in the day was a lot more cumbersome than its much leaner counterpart, Spring Boot, is today. They have obviously learned many lessons along the way, because setting up a Spring application back in 2010 was quite a challenge. Once you’d set things up properly, your application would be extremely robust and scalable, but for a small team like ours, we needed a faster way to just try things out, see them fail or succeed quickly, and move on.

… for a small team like ours, we needed a faster way to just try things out, see them fail or succeed quickly, and move on.

After all, this was the time when Ruby on Rails made all the developer news headlines, and we were extremely jealous about it. It would be great if a framework existed that would combine the robust nature of Java with the rapid development productivity of Ruby on Rails.

And, believe it or not, we found one! Quarkus? No, it was way too early for it. But somewhere around 2013, we discovered Play Framework, and it changed our developer velocity from the ground-up.

Play was everything we’d ever needed in a Java web framework. We still got to build everything using our favorite programming language, use every library we knew and loved from the JVM ecosystem, but our productivity skyrocketed overnight. What made Play so different from Spring is the convention-over-configuration approach it borrowed from Ruby on Rails (among many other things). Setting up a usable Play application took a single command, rather than hours of days of choosing the right combination of Spring packages. Once set up, this application would have everything one needs to keep building their next product with it - from a robust HTTP controller though to easy-to-use persistence and easily extendable templates.

Play had a few other tricks in its sleeve, like, an automatically generated CRUD Admin Dashboard section that would allow us to manage data in our database right from the start, as well as a DEV mode that allowed us to make changes to the application, and see them live without having to restart. At the time, this was unheard of in the Java world - pretty much everyone had to endure hundreds of application restarts per day, then wait several minutes each time, causing their effective amount of productive time per day to drop drastically.

Unfortunately, our expectations for the future of the Play Framework were short-lived. As time passed by, the core Play team decided to pursue a complete rewrite to Scala for the second iteration of the framework. The original Play would remain supported for many years to come, but its initial momentum remained basically frozen in time. Despite the fact that Scala projects are, after all, JVM-compatible, Play 2.0 had a different vision for how Web applications should be built, and it was reflected in its different APIs and constructs. After a short attempt to migrate one of our apps to Play 2.0, we quickly abandoned the idea altogether. Meanwhile, the JVM and the entire programming ecosystem had moved along. It was time for us to do the same.

From Play to Quarkus

The direction of the Play team left us with no choice, but to look for an alternative. On the one hand, Java projects tend to have a long shelf half-life, thus much of our core work is still plain Play Framework applications. We believe we can support them without major issues for a few more years - newer Java versions are backwards-compatible, plus, the Play team and the open-source contributors occasionally release new maintenance updates, thus, our existing projects are still safe and sound.

On the other hand, though, things have changed significantly over the last few years. For once, when I joined IN2 for the first time, the terms containers, cloud and cloud-native were only a vague idea. People would still think of software applications as these giant monolithic systems that required a massive machine to run on. Those still have the advantage of being easier to maintain and deploy, albeit, with the caveat that scaling them up and down requires running multiple instances of the entire application.r 

Containerization and container orchestration changed the rules of the game. All of a sudden, it became possible to split a monolithic system into separate, smaller services that could be developed, deployed, scaled, and maintained independently of one another. The new reality presented a few challenges to the JVM - produce applications that are able to start fast and have a small memory footprint, so that they can be able to run virtually anywhere.

It was at that point when we were faced with the dilemma - for our future projects, should we replace Play with the obvious choice of Spring Boot, or should we try something else?

This is when we found out about Quarkus. I attended a Red Hat meetup at the start of 2020, and as the meeting closed, I was already convinced to try it. Quarkus seemed to have been designed from the ground up for the new reality of the cloud-native world. Unlike other contenders like Spring Boot, it didn't need any retrofitting - because they had the freedom to make something brand new, the Red Hat team was able to bring the best engineering decisions right from the start. And the results did not disappoint - with its lightning-fast startup times, minimal memory footprint, and first-class support for GraalVM native images, Quarkus is simply best-in-class. We could now build applications that were not only highly responsive but also optimized for the resource-constrained environments typical of containerized deployments.

Moreover, Quarkus retained everything we loved about the Java ecosystem. Here was this brand-new framework that not only felt fresh and modern, had a long future in front of itself, but also allowed us to keep using the knowledge, libraries, and tools we know and love. The "live reload" feature in Quarkus DEV mode was a game-changer. It helped us reduce the feedback loop even further and brought back the joy of rapid development we had enjoyed with Play.

Quarkus also fit perfectly with our organizational goals. We needed to move fast, innovate faster, and deploy continuously without sacrificing the things that made Java so robust and popular. Quarkus made this possible, offering the productivity of a modern framework with the power and maturity of the Java platform.

As Quarkus continues to evolve, it’s reassuring to know that the framework is not just keeping pace with the demands of modern software development but is actively shaping the future. The recent announcement that Quarkus will be moving to the Commonhaus Foundation underscores its commitment to open-source innovation. This transition is poised to foster even greater collaboration within the developer community, ensuring that Quarkus remains at the forefront of Java development.

For us at IN2, this move further solidifies our choice. By aligning with an open foundation, Quarkus is ensuring that it will continue to evolve in a direction that benefits all of us. We’re excited to be part of this journey, contributing to a framework that has already given us so much and is now set to have an even more significant impact on the industry.

In Quarkus, we found more than just a framework; we found a partner for the future. It gave us the confidence to tackle new challenges head-on, knowing we had a solid foundation that would grow with us as the industry continues to evolve. As we look forward, we're excited to see where this journey with Quarkus will take us, but one thing is certain—our commitment to innovation and excellence remains as strong as ever.