Red Hat blog
Despite being relatively new to the scene, Quarkus is making quite the stir in the world of Java and application development. The open source community project, which Red Hat now supports as part of Red Hat Runtimes, is a full stack, Kubernetes-native Java framework. It is designed to work with popular Java standards, frameworks and libraries, making Quarkus and Java a great fit for new, cloud-native technologies like serverless and microservices. Java developers can use the language they are already proficient in to develop in these new frameworks. This is crucial, because Java remains one of the most popularly used programming languages in the world, with IDC finding that 9.3 million of 13.5 million professional developers worldwide self-identify as “moderate to heavy” Java users.
Recently, Arnal Dayaratna, a research director and analystocused on Software Development at IDC, explored Quarkus in an IDC Lab Validation report, sponsored by Red Hat. The report quantifies performance metrics for Quarkus to another widely used Java framework for cloud-native development, referred to throughout as Framework A. The comparison is based on attributes that are important for developers and the developer experience, as well as those that are important for containers, Kubernetes and cloud deployments.
Read on to see key findings and highlights.
One of the benefits that has been touted for Quarkus is the cost savings, and the IDC Validation Report confirmed this benefit, finding that running Quarkus apps either on a traditional JVM or as a natively-compiled app leads to cost-savings through lower memory consumption and faster start up times, driving higher deployment density of Kubernetes pods and reduced memory utilization. Quarkus also has a lower cost of operation. When compared to Framework A, cost savings with Quarkus running in native mode - which uses GraalVM to create a standalone, optimized executable that does not run in a traditional Java Virtual Machine (JVM) - can be as much as 64%, and 37% when running on a JVM. These cost savings also came from container utilization, and only using resources when and how you need them.
The report validated that Quarkus improves developer productivity compared to Framework A. This is important because improvements in developer productivity can lead to faster time-to-market and more innovative solutions to enable organizations to stay highly competitive. Compared to Framework A, Quarkus reduced the number of operational steps required to update applications, so updates can be done more efficiently. Specifically, the report notes that with Quarkus, a developer making and testing changes to source code has two steps - change code and save - compared to a developer using Framework A, which has up to six steps - make the project change, stop the service, start the service, test the change, run the Framework A app and test the app again. Quarkus’ two step process not only increases developer productivity, but also makes compiling code easier and more efficient. Quarkus has so few steps because of live coding. Updates to applications using live coding are seen immediately, improving developer operational efficiency, and also lending to more efficient troubleshooting with the ability to track back to display the most meaningful error first.
Quarkus also unifies imperative and reactive programming to give developers the option to freely combine both programming options, and can reduce maintenance time and the amount of projects developers need to manage, by allowing for a smaller number of projects and source files.
The report found that developers using Quarkus can spin up more pods than can be started for Framework A. Specifically, developers using natively-compiled Quarkus apps can spin up 8x more pods, and developers running Quarkus apps on traditional JVMs can spin up 1.5x more pods. This means that with Quarkus, customers can do more with the same amount of resources, and more applications can be deployed using the same amount of memory. Deployment density and reduced memory utilization are a few of the key ways that Quarkus optimizes Java for containers.
One of the initial benefits that developers found when using Quarkus was that it improved memory utilization, which is especially important because Java has traditionally been said to use too much memory at startup, and not be compatible with lightweight applications. The study found that natively-compiled Quarkus apps reduced startup memory use by 90% and Quarkus apps running on a traditional JVM reduced it by 20%. The memory savings at startup results in much higher throughput for the same memory footprint in both JVM and native modes, meaning that more can be done with the same amount of memory. And, Quarkus is much faster at startup than Framework A -- as a natively-compiled app, Quarkus is 12x faster than Framework A, while Quarkus running on traditional JVMs is 2x faster. This makes the application more responsive to changing loads and more reliable during heavy scaling operations (think serverless), increasing innovation and offering an edge over competitors.
Overall, IDC’s report validates that Quarkus streamlines and improves developers’ day-to-day work better than Framework A. These are just some of the main points that IDC validates in the report - there are much more specifics in the full report. To dig deeper into the findings, download the full report here.
About the author
James Falkner is a technology evangelist, teacher, learner, author and dedicated to open source and open computing. He works at Red Hat as a technical marketing director for Red Hat's cloud native application runtimes and loves learning from others, and occasionally teaching at conferences. He's been doing this for the last two decades, and is a Computer Engineering graduate of the University of Florida.