Quarkus

From Wikipedia, the free encyclopedia
Quarkus
Quarkus-logo.svg
Developer(s)Red Hat
Initial release20 March 2019; 2 years ago (2019-03-20)[1]
Stable release
2.7.3[2] / March 2, 2022; 0 days ago (2022-03-02)
RepositoryQuarkus Repository
Written inJava
PlatformJava
TypeApplication framework
LicenseApache License 2.0
Websitequarkus.io

Quarkus[3][4][5][6][7] is a Java framework tailored for deployment on Kubernetes. Key technology components surrounding it are OpenJDK HotSpot and GraalVM. The goal of Quarkus is to make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures.

Version history[]

Version Date Notes
0.12 Mar 20, 2019 Initial release
1.0 Nov 2019
1.3 Mar 2020
1.7 Jun 2020
1.11 Aug 2020
1.13 Mar 2021
2.0 Jun 2021
2.2 Aug 2021
2.4 Oct 2021
2.5.2 Dec 2021 Final — Maintenance release

In March 2019, after more than a year of internal development, Quarkus was introduced to the open source community. Quarkus is a Java framework tailored for OpenJDK HotSpot and GraalVM, boasting extremely fast boot times and low memory utilization. Many organizations since the initial release have seen the immediate value of Quarkus and joined the development effort.

Note GraalVM is a Java Virtual Machine for compiling and running applications written in different languages to a native machine binary. There are three distributions of GraalVM: GraalVM Community Edition (CE), GraalVM Enterprise Edition (EE), and Mandrel. GraalVM CE and EE have varying support and licensing requirements. Mandrel is a downstream distribution of GraalVM CE, supporting the same capabilities to build native executables but based on the open source OpenJDK. Mandrel aims to make GraalVM easy to consume by Quarkus applications by only including GraalVM CE components that Quarkus needs. Red Hat offers commercial support for using Mandrel to build native Quarkus applications since the Quarkus 1.7 release in October 2020.

Quarkus also offers near-instant scale-up and high-density utilization in container orchestration platforms such as Kubernetes. Many more application instances can be run given the same hardware resources. After its initial debut, Quarkus underwent several enhancements over the next few months, culminating in a 1.0 release within the open source community in October 2019. As a new framework, Quarkus does not need to attempt to retrofit new patterns and principles into an existing codebase. Instead, it can focus on innovation.

Note Red Hat offers enterprise support for Quarkus. For more information here.

Design pillars[]

Container first[]

From the beginning, Quarkus was designed around the container-first and Kubernetes-native philosophy, optimizing for low memory usage and fast startup times. As much processing as possible is done at build time, including taking a closed world assumption approach to building and running applications. This optimization means that, in most cases, all code that does not have an execution path at runtime isn't loaded into the JVM.

In Quarkus, classes used only at application startup are invoked at build time and not loaded into the runtime JVM. Quarkus also avoids reflection as much as possible, instead favoring static class binding. These design principles reduce the size, and ultimately the memory footprint, of the application running on the JVM while also enabling Quarkus to be natively-native.

Quarkus' design accounted for native compilation from the onset. It was optimized for using the native image capability of GraalVM to compile JVM bytecode to a native machine binary. GraalVM aggressively removes any unreachable code found within the application's source code as well as any of its dependencies. Combined with Linux containers and Kubernetes, a Quarkus application runs as a native Linux executable, eliminating the JVM. A Quarkus native executable starts much faster and uses far less memory than a traditional JVM. Here is an example how fast Quarkus can deliver significant runtime efficiencies based on Red Hat testing: 

$ ./my-native-java-rest-app
Quarkus started in 0.008s
  • Fast Startup (tens of milliseconds) allows automatic scaling up and down of microservices on containers and Kubernetes as well as FaaS on-the-spot execution
  • Low memory utilization helps optimize container density in microservices architecture deployments requiring multiple containers
  • Smaller application and container image footprint

Unifies imperative and reactive[]

For years, the client-server architecture has been the de facto standard to build applications. But a major shift happened. The one model rules them all age is over. A new range of applications and architecture styles has emerged and impacts how code is written and how applications are deployed and executed. HTTP microservices, reactive applications, message-driven microservices and serverless are now central players in modern systems. Quarkus has been designed with this new world in mind, and provides first-class support for these different paradigms. Quarkus development model morphs to adapt itself to the type of application you are developing.

Developer productivity[]

Quarkus focuses on more than just delivering sets of features; every feature should be simple, have little-to-no configuration, and be as intuitive as possible to use. It should be trivial to do trivial things while relatively easy to do more complex things, allowing developers more time to focus on their domain expertise and business logic.

Unified configuration[]

Gone are the days of a thousand configuration files and formats. We’re aiming for cohesion, so a single configuration file is all it takes for Quarkus applications to configure every single extension. Not only that, but we’ve made sure that every configurable option has the most useful and sensible defaults so you can get started with no configuration whatsoever.

Live coding[]

One of the major productivity problems that face most Java developers is traditional Java development workflow. For most web developers this will generally be:

Write Code → Compile → Deploy → Refresh Browser → Repeat

This can be a major drain on productivity, as the compile + redeploy cycle can often take up to a minute or more. Quarkus aims to solve this problem with its Live Coding feature. When running in development mode the workflow is simply:

Write Code → Refresh Browser → Repeat

This will work out of the box, with no special setup required. This works for Java file, application config, and static resources.

Note When you run mvn compile quarkus:dev Quarkus will launch in development mode. When it receives a HTTP request it will hold the request, and check to see if any application source files have been changed. If they have it will transparently compile the changed files, redeploy the application with the changed files, and then the HTTP request will continue to the redeployed application. Quarkus redeploys are much faster than a traditional app server, so for all but the largest applications this should take well under a second.

Interactive developer user interface (DEV UI)[]

Quarkus provides an interactive developer UI to showcase all added dependencies when a developer accesses the http://localhost:8080/q/dev endpoint after the Quarkus dev mode gets started via mvn quarkus:dev command-line. The developers also can update configurations then the changes will sync the application.properties file up automatically.

Zero configuration with dev services[]

Installing a database in a developer's local environment is not a trivial task if the database should be the same as the production version. Of course, Linux users (developers) can run the database easily using a container command-line tool (e.g., Docker and Podman) and a container engine (e.g., Docker, quay.io). They still tend not to run production-ready databases (e.g., PostgreSQL and MariaDB) due to high consumption of the resources (e.g., CPU, memory, and disk space). Instead, they prefer to use in-memory datastores like the H2 database.

Quarkus provides the Dev Services built on Testcontainers to solve this problem. For example, a developer can do test applications if they work in the production database, PostgreSQL rather than H2 in-memory datastore in the application.properties file:

quarkus.datasource.devservices.image-name=postgres:latest

DevServices is generally enabled by default, unless there is an existing configuration present. When DevServices is enabled Quarkus will attempt to automatically configure and start a database when running in development or test mode.

Continuous testing[]

Testing is not an option to develop robust applications in software development from monolith to microservices. Developers probably think of external continuous integration (CI) tools that a QA team most likely has responsibility for verifying test cases. What if the developers do not need to integrate the CI tools but perform the test cases on a runtime environment where business applications are developing and running. Quarkus provides a continuous testing feature through the command-line interface as well as the DEV UI. This feature removes the developer's efforts to integrate an external CI tool and ensures the functionality while continuously developing business logic.

Built on standards[]

Quarkus rests on a vast ecosystem of technologies, standards, libraries, and APIs. Developers do not have to spend lots of time learning an entirely new set of APIs and technologies to take advantage of the benefits Quarkus brings to the JVM or native images. Among the specifications and technologies underlying Quarkus are Eclipse MicroProfile, Eclipse Vert.x, Contexts & Dependency Injection (CDI), JAX-RS, Java Persistence API (JPA), Java Transaction API (JTA), Apache Camel, and Hibernate, just to name a few.

Quarkus is also an Ahead-of-Time compilation (AOT) platform, optimizing code for the JVM as well as compiling to native code for improved performance. All of the underlying technologies are AOT-enabled, and Quarkus is continually incorporating new AOT-enabled technologies, standards, and libraries.

All the technologies and capabilities needed for building microservices are available and optimized for Quarkus. These technologies take advantage of all the compile-time and runtime optimizations that have already been discussed. Technologies like Keycloak for authentication and authorization, or Infinispan for distributed caching, are optimized for use within Quarkus, regardless of whether they run in the HotSpot JVM or as a native image. Third-party framework and library developers can take advantage of this AOT platform to optimize them for Quarkus.

References[]

  1. ^ "Quarkus Github repository, First release commit". github.com.
  2. ^ "Quarkus Github repository, Last release commit". github.com.
  3. ^ "Red Hat, What is Quarkus?". redhat.com.
  4. ^ "Introducing Quarkus: a next-generation Kubernetes native Java framework". developers.redhat.com.
  5. ^ "LogicMonitor, Quarkus vs. Spring". logicmonitor.com.
  6. ^ "Guide to QuarkusIO". Baeldung.
  7. ^ "Getting started with QuarkusIO". mastertheboss.com.

Bibliography[]

External links[]

Retrieved from ""