Quarkus Gives Spring Boot Users a Path to Serverless and Live Coding
When you think of serverless computing, microservices and the open hybrid cloud, there’s one language you’re probably not hearing the cloud pundits talk about: Java. And that’s a real shame. Despite its lack of sexiness at present, Java was and is the workhorse language of business. It remains the third most popular language in the world, in fact, according to the Tiobe Index. It’s been the language of choice for corporations that need to keep a single application up and running for years at a time, where even a single minute of an outage can cost millions of dollars.
And then, the world decided that not only is it not necessary to build such complex bullet-proof applications and runtimes, but it’s actually desirable to go around your clusters kicking servers offline occasionally — just to keep the chaos consistent. Instead of humongous expensive servers with giant CPUs and mountains of RAM, apps in the open hybrid cloud run consistently on whatever, wherever: server, desktop, edge systems, VMs, public clouds, and everything in between.
Indeed, the world of fast booting, small-memory-footprint, stateless and serverless applications seems to have left the traditional (and lucrative) world of monolithic Java applications behind. And as such, the complex world of Java and its wildly diverse universe of ancillary tools and open source projects has been largely left out of the cloud revolution. That’s a lot of smart people and tools to change or retrain.
That’s why a team of developers at Red Hat created the Quarkus Project. In 2017, while working on ways to modernize Java EE applications, the team decided that the endless race to tweak and trick out the Java Virtual Machine (JVM) had reached a dead end. With companies like Azul Systems offering 100-core CPUs and specially designed JVMs to handle humongous, non-stop Java applications with gigabytes of memory required, it seemed as though the race to further optimize the JVM had been fought and won around garbage collection and just-in-time compilation projects.
Instead, the fledgling Quarkus team went up the stack. Quarkus, they decided, would drastically change how Java could be used; and it would do so as a framework, not as a replacement for Tomcat or WebSphere. Instead, it would entirely reframe what it meant to develop in Java. Plus, when combined with Red Hat OpenShift, it can tap into the multitude of benefits offered by Kubernetes as a base infrastructure.
The Slow Start Upstart
One of the biggest things going against Java in the microservices and serverless cloud domains is the length of time it takes to spin up a JVM and application. Much of the work for running a Java application is done up front, when the application boots. That’s no big deal when your application should boot once and run forever, but when you’re treating your applications like cattle instead of pets in this cloud native era, startup time becomes a real issue. You can’t spin up replacement servers on-demand when it takes 10 seconds just to get the application running.
So much of an issue is startup time that at present, only 6% of AWS Lambda applications are written in Java. Of course, you could also chalk that up to the size of the memory footprint Java apps tend to take. For a simple “Hello World” application, for example, Java using Spring Boot takes up over 100MBs. A Node.js application requires around 40MBs. Java with Quarkus requires only 17MBs of RAM.
Quarkus also provides the ability to natively compile and run your Java application with Mandrel (part of the GraalVM community), allowing all those expensive up-front computing costs to be paid once at compile time. That means Quarkus apps can jump up and run as fast as Go or Node applications, something that was not feasible for Java before.
James Falkner, technology evangelist at Red Hat, said that Quarkus is able to do all of this while still running in a traditional JVM, because it’s a framework. “You can run it on a traditional JVM like Hotspot. It is still bytecode and it is interpreted. For native compilation, we use Substrate VM; it’s a very highly optimized simple VM running your bytecode in VM. There’s no JIT, and it has a simpler garbage collection. Quarkus makes a trade-off; it’s not focused on maximizing throughput at the expense of footprint.”
Said Falkner, “It’s a very different way of building and running a Java application. Quarkus has done all the prework. The native compilation capability does dead code elimination, where it looks at all paths [and] it eliminates any paths that will never be taken. It resolves dependencies and annotation scanning and JAR file loading that were traditionally done at runtime, and does it once at build time.“
For existing Spring Boot users, Daniel Oh, principal technical marketing manager at Red Hat, said that there is a path for migrating to Quarkus. The Quarkus team has included Spring compatible APIs for Quarkus, which allows applications to be quickly ported. “If you use that capability on Quarkus, the Spring developer doesn’t have to change any code, just import and run Quarkus,” said Oh.
For developers with Spring Boot applications, the process of migration gets even easier when using the new Migration tool. The Migration Toolkit for Applications (MTA) is a toolset that supports large-scale Java application modernization and migration projects across a broad range of transformations and use cases. It accelerates application code analysis, supports effort estimation, accelerates code migration, and helps you move applications to the cloud and containers.
Of course, just using the Spring compatibility layer won’t give developers access to some of the Kubernetes and cloud-focused features of Quarkus, such as single sign-on and support for tying into Kubernetes features and triggers.
But developers will still be able to take advantage of the Hotspot features in the JVM when developing with Quarkus. Oh said that Quarkus provides developers with a live coding experience. They can run their code in the cloud, edit it, then quickly swap it out onto a running Hotspot JVM and see the results immediately, rather than waiting for a lengthy redeployment.
“The inner loop development speed is lightning fast,” said Falkner. He added that Quarkus also requires “less code to build the same application.” In the end, a Java application can require fewer classes overall when ported to Quarkus, saving RAM and development time, while also lowering technical debt.
Miguel Perez Colino, product manager for Migration Toolkit for Applications at Red Hat, said that “When you compile to native, people managing infrastructure are going to love it. One user told me they come for the speed, they stay for productivity. They check the numbers on the speed of Quarkus, and it’s lightning-fast.”
Indeed, the benefits of Quarkus are many, but they are, unfortunately, not going to be applicable to every Java application. Indeed, one of the great things about Quarkus is simply that it enables existing enterprise Java developers to go back to Java and start building open hybrid cloud applications — like their cooler cousins in Go and JavaScript.
Further, Quarkus isn’t really intended to be used to migrate existing monolithic Java applications that must run 24/7. Falkner said that highly scalable stateless applications are still the way to go for building with containers using Quarkus; and traditional monolithic Java applications are not that.
However, as many enterprises are hoping to migrate those monolithic applications to microservices long term, Falkner said that Quarkus is a great target for those migrations. While the application itself may have to be redesigned and require more than just refactoring, the speed and performance of Quarkus can help to make that journey one that is undertaken with more agile velocity, thanks to the faster developer feedback loop it enables.
That’s what Lufthansa Technik found when it adopted the project for this very reason. In the end, it was able to migrate Java EE artifacts to the cloud using Quarkus. Falkner expects there’s a whole universe of applications that would be better served by moving to Quarkus instead of being rewritten in some other newer language. After all, with Quarkus at hand, Java can finally take flight in the serverless cloud.
