An Open Plea to the Quarkus Team

This week, I updated a few of our apps to Quarkus v3.9+. As always, it was a simple process. But beyond anything else, this update was special because it brought in some significant simplification of package naming. I am extremely happy because this small change will hopefully address some people’s hesitation and certainly increase Quarkus’ adoption. I can’t recall how many times I’ve seen Quarkus get rejected as an option because people think it only applies to projects that follow the reactive style of programming. Oh, my! I am glad this reactive/non-reactive mess is coming to an end.

All of that got me thinking, though. As someone using Quarkus in production for virtually the same scenarios for which others would have chosen Spring Boot, it pains me to see it dismissed as “that cloud-native Java framework for microservices.” Because it isn’t; it’s a lot more. Quarkus is just as capable of full-stack Java development as Spring Boot. Beyond Spring’s massive adoption, there’s little it can do that Quarkus isn’t capable of doing, either. And that, with a significantly better developer experience and startup speed that can rival that of some natively compiled code.

So, here is my plea to the Quarkus team: consider tweaking the sales pitch of your product a little. You don’t get to win people over from Spring with “A Kubernetes Native Java stack … " You win them with “a Java framework that can help you bootstrap your next project in no time, regardless of whether it is a monolith or a cluster of microservices. It is specifically optimized for Kubernetes and the Cloud, but just about any other type of Java application will fit just fine.”

Quarkus deserves it!