Quarkus has made its debut just two and half months ago on March 7th, 2019 with the release of version 0.11 and this public announcement, and since then it has made a lot of buzz in the Java universe while attracting significant developer interest. This is still early days so most people are mostly in the experimental stage getting their feet wet and having a first taste of what it means to write Supersonic Subatomic Java apps. (And just in case you haven't heard of Quarkus check out this introductory video.)
By some twist of luck the first public release of Quarkus came right out of the Red Hat Neuchâtel Office in Switzerland, the original JBoss HQ for Europe, where a large part of the very much distributed Quarkus engineering team was having a meeting that concluded with a release hackathon.
Of course, Quarkus was not born there. For years various people and teams at Red Hat including the WildFly/EAP team with Galleon, as well as the sister WildFly-Swarm/Thorntailv4 projects, the Drools team with Submarine, the OpenJDK team and others, were experimenting with evolutionary approaches for reducing the runtime overhead of Java
applications to make them more space and time efficient for cloud native
deployments.
However, at some point it became evident that evolutionary approaches wouldn't cut it for the order-of-magnitude scale improvements we were targeting so three of our most prominent architects, (alphabetically) Bob McWhirter, Emmanuel Bernard and Jason Greene came together and with our CTO's blessings started a Proof-of-Concept (initially stealth) effort that would attempt to unify the various research projects into one looking into revolutionary approaches for developing that one single Runtime to rule them all.
An interdisciplinary team of engineers (non exaustive list) was gradually formed with each one bringing along with them a ton of ideas and experience from different areas of the Middleware/Enterprise Java spectrum, from kernel design and JVM internals to networking, security and persistence, integration frameworks and performance optimizations (and more). Within 3-4 months the team put in place the base architectural elements and design abstractions and delivered a prototype that satisfied the original goals but also went way beyond. It produced innovations that will be studied and copied over for years to come and provided justification for the project to continue, eventually leading to its public announcement.
The cool thing about Quarkus is that it works equally well in standard JVM and native compiled mode. By essentially pre-computing application and framework initialization and eliminating dead code (and performing many other optimizations) it can greatly reduce boot time, artifact size and runtime memory requirements (RSS space).
In one sense things are moving to the opposite direction from the days of early JBoss. Back them we've disrupted the application server space by moving compile time operations into deployment time. With dynamic proxies, a plugable microkernel architecture and an aspect oriented/interceptor design we could avoid precompilation steps and do things you now take for granted like hot-deployment and instant-clustering. Even the collapse of the Web and EJB layers within the same JVM was a selling point. Now we go for extreme distribution with all the benefits and challenges that come with it.
A very rough rule of thumb is that by using Quarkus in standard JVM mode you can expect your app to boot in a fifth of the time compared to most other popular runtimes and consume about half the memory. In native mode things go crazy: expect one to two orders of magnitude of reduced boot time (supersonic, in the order of tens of milliseconds) and about a fifth to a third of runtime memory consumption (subatomic).
It's funny to see people trying out Quarkus and reporting an impressive 1.65 seconds boot time for an app that would take 56 seconds to boot on Google Cloud and then the Quarkus team reacts because that looks "slow" and with DNS issues resolved the boot time should be closer to 0,015 seconds! To say it differently, beyond an awesome enabler for writing microservices, Java can now be used as a launching platform for serverless apps and cloud functions. Which in turn means that the millions of Java programmers in the world can keep using their favorite programming language, frameworks and APIs and carry forward their know-how in this brave new cloud native world, while companies can maintain their multi-year investments in Java. This is a game changer, IMO.
However, to reap the full benefits of Quarkus, frameworks needs to be enabled for it, they need to be Quarked. The team has written extensions for popular frameworks/libraries (listed here) that help provide Quarkus' opinionated programming model but our expectation is that the community will step up and provide their own extensions for popular frameworks in order to enhance the Quarkus ecosystem. With enough Quarkus extensions in place the benefits of Ahead of Time Compilation (AOT) will be offered to a larger percentage of the Java Developer base in a way that makes the production of native binaries almost transparent to the end user.
Quarkus offers a lot more than a Supersonic speed, a Subatomic footprint and a set of best of breed technologies and standards. It provides both an imperative and a reactive programming model and most importantly it brings back developer joy in the life of the programmer. I've been in a couple of Quarkus presentations already and the moment we show how a code change in the IDE is immediately picked up by Quarkus in developer mode the next time the web browser gets refreshed with the change recompiled and the whole app redeployed *instantly*, that moment, the people's reaction is simply priceless. Back in the JBoss days our motto was to"put back the developer into the driver's seat". Same thing now with Quarkus.
I hope that helps explains a bit some of the excitement behind Quarkus inside and outside Red Hat, and my own personal excitement, too, especially from the moment I was offered the opportunity to come and help run the extended Quarkus team as its Engineering Manager. I am humbled by the sheer amount of brain power behind the project, although, coming from the WildFly/EAP team this is not something new to me. I've seen a few times in my career the type of magic that can happen when you put exceptional people working together on a common stretched goal.
Being a JBoss alumni and having worked on all transformations that the JBoss Application Server project underwent since version 2.x, I've delivered my last JBoss EAP 7.2 release as Engineering Manager while I was transitioning to Quarkus and handed over the product to Tom Jenkinson with whom I've I've worked in the EAP team for many years. Tom was Engineering Manager & Project Lead of the Nayarana Transactions Engine that powers all of JBoss Middleware, a project even older than JBoss AS.
Tom in turn is supported by Brian Stansberry in the role of WildFly project lead, as well as a great team of JBoss/WildFly veterans, so I'm confident that EAP is in the best hands possible to continue evolving and thriving, tracking the latest developments in the Jakarta EE / Microprofile space.
This is all for now - stay tuned on Quarkus - and join the revolution.
/Dimitris
By some twist of luck the first public release of Quarkus came right out of the Red Hat Neuchâtel Office in Switzerland, the original JBoss HQ for Europe, where a large part of the very much distributed Quarkus engineering team was having a meeting that concluded with a release hackathon.
 |
| History in the making - Quarkus about to be released to the public |
However, at some point it became evident that evolutionary approaches wouldn't cut it for the order-of-magnitude scale improvements we were targeting so three of our most prominent architects, (alphabetically) Bob McWhirter, Emmanuel Bernard and Jason Greene came together and with our CTO's blessings started a Proof-of-Concept (initially stealth) effort that would attempt to unify the various research projects into one looking into revolutionary approaches for developing that one single Runtime to rule them all.
An interdisciplinary team of engineers (non exaustive list) was gradually formed with each one bringing along with them a ton of ideas and experience from different areas of the Middleware/Enterprise Java spectrum, from kernel design and JVM internals to networking, security and persistence, integration frameworks and performance optimizations (and more). Within 3-4 months the team put in place the base architectural elements and design abstractions and delivered a prototype that satisfied the original goals but also went way beyond. It produced innovations that will be studied and copied over for years to come and provided justification for the project to continue, eventually leading to its public announcement.
The cool thing about Quarkus is that it works equally well in standard JVM and native compiled mode. By essentially pre-computing application and framework initialization and eliminating dead code (and performing many other optimizations) it can greatly reduce boot time, artifact size and runtime memory requirements (RSS space).
In one sense things are moving to the opposite direction from the days of early JBoss. Back them we've disrupted the application server space by moving compile time operations into deployment time. With dynamic proxies, a plugable microkernel architecture and an aspect oriented/interceptor design we could avoid precompilation steps and do things you now take for granted like hot-deployment and instant-clustering. Even the collapse of the Web and EJB layers within the same JVM was a selling point. Now we go for extreme distribution with all the benefits and challenges that come with it.
A very rough rule of thumb is that by using Quarkus in standard JVM mode you can expect your app to boot in a fifth of the time compared to most other popular runtimes and consume about half the memory. In native mode things go crazy: expect one to two orders of magnitude of reduced boot time (supersonic, in the order of tens of milliseconds) and about a fifth to a third of runtime memory consumption (subatomic).
It's funny to see people trying out Quarkus and reporting an impressive 1.65 seconds boot time for an app that would take 56 seconds to boot on Google Cloud and then the Quarkus team reacts because that looks "slow" and with DNS issues resolved the boot time should be closer to 0,015 seconds! To say it differently, beyond an awesome enabler for writing microservices, Java can now be used as a launching platform for serverless apps and cloud functions. Which in turn means that the millions of Java programmers in the world can keep using their favorite programming language, frameworks and APIs and carry forward their know-how in this brave new cloud native world, while companies can maintain their multi-year investments in Java. This is a game changer, IMO.
However, to reap the full benefits of Quarkus, frameworks needs to be enabled for it, they need to be Quarked. The team has written extensions for popular frameworks/libraries (listed here) that help provide Quarkus' opinionated programming model but our expectation is that the community will step up and provide their own extensions for popular frameworks in order to enhance the Quarkus ecosystem. With enough Quarkus extensions in place the benefits of Ahead of Time Compilation (AOT) will be offered to a larger percentage of the Java Developer base in a way that makes the production of native binaries almost transparent to the end user.
Quarkus offers a lot more than a Supersonic speed, a Subatomic footprint and a set of best of breed technologies and standards. It provides both an imperative and a reactive programming model and most importantly it brings back developer joy in the life of the programmer. I've been in a couple of Quarkus presentations already and the moment we show how a code change in the IDE is immediately picked up by Quarkus in developer mode the next time the web browser gets refreshed with the change recompiled and the whole app redeployed *instantly*, that moment, the people's reaction is simply priceless. Back in the JBoss days our motto was to"put back the developer into the driver's seat". Same thing now with Quarkus.
I hope that helps explains a bit some of the excitement behind Quarkus inside and outside Red Hat, and my own personal excitement, too, especially from the moment I was offered the opportunity to come and help run the extended Quarkus team as its Engineering Manager. I am humbled by the sheer amount of brain power behind the project, although, coming from the WildFly/EAP team this is not something new to me. I've seen a few times in my career the type of magic that can happen when you put exceptional people working together on a common stretched goal.
Being a JBoss alumni and having worked on all transformations that the JBoss Application Server project underwent since version 2.x, I've delivered my last JBoss EAP 7.2 release as Engineering Manager while I was transitioning to Quarkus and handed over the product to Tom Jenkinson with whom I've I've worked in the EAP team for many years. Tom was Engineering Manager & Project Lead of the Nayarana Transactions Engine that powers all of JBoss Middleware, a project even older than JBoss AS.
Tom in turn is supported by Brian Stansberry in the role of WildFly project lead, as well as a great team of JBoss/WildFly veterans, so I'm confident that EAP is in the best hands possible to continue evolving and thriving, tracking the latest developments in the Jakarta EE / Microprofile space.
This is all for now - stay tuned on Quarkus - and join the revolution.
/Dimitris
