Red Hat recently released Quarkus, a Kubernetes native Java framework tailored for GraalVM and OpenJDK HotSpot. Expanding on our initial coverage of this release, InfoQ has spoken to several experts within Red Hat in order to learn about the motivations, use cases, and future direction of the project.
In the cloud era, where containers, Kubernetes, microservices, functions-as-a-service (Faas), and cloud native applications are delivering higher levels of productivity and efficiency, Quarkus emerges as a very interesting alternative.
InfoQ spoke with John Clingan, senior principal product manager at Red Hat, and Mark Little, vice president of engineering at Red Hat.
InfoQ: Quarkus aims to make Java a leading platform in Kubernetes and serverless environments. How did the idea emerge? How many years have you been working on this?
Red Hat: Red Hat is one of the organizations that early on identified several limitations with using a JVM in a container, and we have and are still contributing to solve some of these limitations. We discussed this in a recent Red Hat Developer blog post. Today Java application on the JVM can successfully run in containers, which is seen by our customers who are using this combination in production. However, some limitations remain that can be hard to solve by improving the JVM.
One example of such a limitation is the initial startup time and memory consumption required to run an Enterprise Java application on a JVM. At Red Hat, we have been looking at similar solutions like GNU compiler for Java and the Avian projects, but when the GraalVM was announced as part of the Java Community we saw a lot of potential for working together with that community.
InfoQ: What was the inspiration for Red Hat to create Quarkus?
Red Hat: When we saw the way GraalVM works, we realised that in order to reap all the benefits we had to take a holistic approach and think of the problem not only at the VM level, but also at the framework level. When building native applications in Java for GraalVM there are some limitations from which GraalVM gains its benefits, primarily around the more dynamic features of Java, like reflection. The problem is not very hard to solve for an application with few to no dependencies, but it quickly becomes overwhelming when building an Enterprise Java application.
Developers tend to use a lot of different frameworks. One such popular framework is Hibernate, which is the most used Object-Relational Mapping framework for easy access to database content. Getting Hibernate to run optimally on GraalVM requires pretty deep knowledge about the Hibernate internals, and to do it effectively, one would also require deep knowledge of both the JVM and how GraalVM works. During that experimental work, we saw an opportunity to create a common architecture where other frameworks could more easily embrace GraalVM's idiosyncracies.
We used the extension system in Quarkus to port even more projects over, like our Eclipse MicroProfile implementation project (SmallRye) and RESTEasy. That list is now at roughly 40 extensions and is growing. Quarkus has even received its first community extension in swagger-ui. This has now resulted in a Java stack that is easy to use and very familiar to Enterprise Java developers regardless of whether they have been using Java EE, MicroProfile, or Spring.
InfoQ: Shortly after the release of Quarkus, it was announced that the development of Thorntail 4.x will end and that Thorntail 2.x will be supported through November 2020. What kind of impact could Quarkus have on other Java middleware vendors such as Payara and Tomitribe?
Red Hat: Quarkus has created some pretty innovative features like the extension API, extension ecosystem, and the unified imperative and reactive programming model. The largest impact on other vendors will occur in the context of Eclipse MicroProfile, where we collaborate on next generation Enterprise Java specifications. MicroProfile is targeting cloud-native Java. Quarkus is an example of how to begin targeting more modern cloud-native deployment scenarios with a unified imperative and reactive programming model.
We can combine what we have learned with these ideas in Quarkus with what other implementations (like Payara and Tomitribe) have learned to move the industry forward through MicroProfile and Jakarta EE. It is important to note that we must all innovate first before we attempt to create specifications. It may take months, if not years, before an idea is adopted in a specification, so it will take time.
InfoQ: What can developers expect from Quarkus?
- A container first experience ideal for Kubernetes
- Blazing fast startup times in milliseconds that enable the cold start of serverless Java, supporting a more responsive and scalable environment
- Minimal footprints up to a 10th the size of a standard Java process, which allows you to have much greater density, improving the overall elasticity of the system.
- An architecture that embraces 12 factor app, allowing you to develop more robust and reliable applications
- Real developer joy
- Opinionated well-integrated platform supporting both imperative and reactive styles
- Based on the best of breed standards and OSS
InfoQ: Can languages that are currently supported in GraalVM, such as Scala and Python, be used with Quarkus? If yes, could you give us some examples? If not, will it be supported eventually?
Red Hat: Java continues to be a primary language used by the Enterprise and by Red Hat customers, so that's where we are focusing most of our attention today. We include Kotlin to experiment beyond Java and to see what the community comes up with.
InfoQ: Could you give us more details regarding Quarkus Metrics?
Red Hat: Quarkus enables the monitoring of applications through the SmallRye Metrics implementation of the Eclipse MicroProfile Metrics specification. It exposes a set of default base metrics for an application, while also allowing the developer to add custom application metrics. All metrics are accessible from the /metrics endpoint of an application and can be scraped by Prometheus and other monitoring systems. Quarkus also comes with health-check support and distributing tracing features, making applications ops-friendly.
InfoQ: What is planned regarding the release cycle of Quarkus?
Red Hat: There has been a tremendous amount of interest in Quarkus, so we want to be as responsive as possible. We have been delivering features and bug fixes roughly every few weeks and will continue to do so until we feel there is sufficient feedback and developer hands-on use.
One of our main objectives is to help the community write extensions. Quarkus is an ecosystem for us.
InfoQ: Do you plan to maintain backward compatibility with initial versions?
Red Hat: Backward compatibility is very important to us at Red Hat and to our communities. but we are a young project and innovation is happening at a pace where it's too early to lock that down. However, we will be working with the community to determine when, why and how.
The good thing, however, is that Quarkus builds on the shoulders of giants: Hibernate, Vert.x, Camel, Netty, RESTEasy, etc. All of these are mature frameworks with backward compatibility history. Quarkus simply exposes these framework APIs. We have seen quite a few community members porting Java EE applications into Quarkus in record time. That's the power of best of breed mature frameworks and standards in action.
InfoQ: What is the roadmap for Quarkus?
Red Hat: First off, the community is very young and we want to listen to what people do with and need from Quarkus.
We also see the ecosystem as very important; we want the Java ecosystem to embrace this new paradigm shift for Java, as we see it as the future. So a lot of our effort is focused on making sure writing extensions for the frameworks developers use and love is as easy as possible.
Then that's when it gets difficult. We launched Quarkus in a state in which it has a vision, and there is a lot to do to reach it. I'll list the main subjects, but remember, the community and its needs will drive the roadmap more than anything else:
- Serverless: Quarkus low memory usage and extremely fast startup time makes it a perfect candidate for a FaaS function framework.
- Imperative and reactive: Reactive is critical in cloud native resilient applications. We have shown where we want to go with our unification of the programming models. Now it's time to increase the area. For example, we are exploring reactive non-blocking ways to do persistence.
- Security: how to deal with the deluge of CVEs that the industry is having to get used to? We learned a lot from our experience with Wildfly and expect good things from Quarkus in the near future.
- Containers and Kubernetes: an application is of no use if it's not deployed. There is a lot of value that can be added to smooth the deployment of Quarkus application on container platforms and Kubernetes in particular.
InfoQ: What is the compile time boot technique you used in Quarkus?
Red Hat: There are quite a few tricks, but let's explore what we feel are the most interesting aspects. One key point of Quarkus is to shift a lot of what frameworks traditionally do at startup time and make it happen at build time: classpath scanning, reflection, parsing configuration, gathering the metadata and building the runtime model, etc. This is awesome for a few reasons:
- You only do that work once at build time, and not each time the application starts
- All of the code necessary to bootstrap frameworks that would normally take memory in the JVM (class metadata etc) are simply not present at runtime
That is how we can make Quarkus applications start and accept requests so fast, and how we can squeeze as much memory overhead as possible.
The other interesting aspect of Quarkus extensions is that they have been designed to help the GraalVM dead code elimination algorithm as much as possible. GraalVM is doing a fantastic job at detecting unnecessary call paths but it needs help from framework to know whether an optional dependency is really optional for that specific application. This can be a bit tedious, but it pays off.
InfoQ: What's the best way for developers to get the technology? Are there preferred ways for developers to engage with the community and ask questions?
Get Quarkus: See Getting Started Guide
Twitter: @QuarkusIO
Chat: Zulip Chat Room
Q/A: StackOverflow