Quarkus: Next Gen Java for Cloud-Native Environments
Java was developed as the first platform- independent language and it did set new standards: with the JVM, as preferred platform for Android development or with standards like Java EE. Modern technologies like cloud computing, microservices und containerization though present Java with new challenges.
Because the Java language originally had been designed for server-based computer programs and therefor was not optimized for the cloud. This becomes apparent in comparisons with other languages like Node.js or Go.
| Classic Java Webframe Works or Application Server | Quarkus |
|---|---|
| memory demanding | minimal memory requirements |
| long start time | very short start time |
| not well suited for serverless computing | excellent for serverless computing |
| needs JVM | natively compilable with GraalVM |
| Σ does not support use in cloud, partially impedes use | Σ ideal for use in the cloud |
Quarkus Improves your Business
If Java code meets certain requirements, it can be compiled into a native application via GraalVM. This way the native application is starting up to 30 times faster, the application’s memory requirements drops to about a tenth of the traditional cloud-native stack.
If a native compilation is wanted, not every library can be integrated into a Quarkus application. Yet Quarkus provides a rich ecosystem of libraries supporting native compilation – maintained by Red Hat as well as by the community. This includes libraries like undertow, RESTEasy and Hibernate ORM. There are also Quarkus specific features that simplify the developing of and with Quarkus applications like:
- Integration with Maven and Gradle
- Command-Line-Tooling for Management Quarkus specific dependencies
- Targets for creating a native application
- Powerful development mode for quick feedback during development
- Testing with JUnit5 and Rest Assured
- Testing of native applications
Interested? Discover the future of cloud native Java applications - today!
Important Quarkus & Java terms
What is Jakarta EE?
Jakarta EE is an open standard of the Eclipse Foundation and successor of Java EE 8. The standard defines APIs for features and the corresponding performance. The defined features include dependency injection (CDI, JSR 365), definition of RESTful web services (JAX-RS, JSR 370), mapping Java objects on relational databases (JSR 221, JSR 222, JSR 367 and JSR 338).
Implementation will be in the libraries and application servers respectively, which implement the standard: like Tomcat, Glassfish, Payara and Quarkus.
What is MicroProfile?
The MicroProfile standard builds on Jakarta EE. Like Jakarta EE MicroProfile is open source as well and is developed by the Eclipse Foundation. The features aim at the implementation of microservices. You can find APIs for defining REST Clients, monitoring the application, reading technical and functional statistics and for configuring the application.
As with Jakarta EE, implementation with MicroProfile takes place in the libraries or application servers implementing the standard.
What is GraalVM?
GraalVM is a JVM developed by Oracle, based on Java 8 and Java 11. GraalVM is offered free and open source (GraalVM CE) and in a commercial version, including support and other runtime optimizations (GraalVM EE). GraalVM CE may be used for productive purposes.
Besides aiming to optimize the runtime of Java programs, GraalVM offers the opportunity to translate Java programs into natively executable binary files. This feature is generally known as "Ahead-of-Time (AoT) compilation". In the GraalVM eco system this feature is called "native-image". The primary goal of natively compiled Java programs is not optimizing the runtime but optimizing processor and storage utilization.
Why cloud native? And what makes applications cloud native?
Automation
Hardware is unreliable, software is complex. Hardware components fail, applications need to be restarted. Both situations require manual intervention, the process is time-consuming and cost-intensive. When using a containerized infrastructure like via Kubernetes, many processes can be automated. If, for example, hardware is failing, the containers affected by the failure are restarted automatically on hardware not affected.
Containerization also provides the possibility of horizontal scaling: is the load to high on one application, it is instantiated several times and the load is distributed on all of the applications instances. If the load decreases, the instances not needed any longer will be stopped. This can be automated via metrics, provided by the containerized application via its status. The trend here is automation, one of the fundamental pillars of site reliability engineering.
Cloud native criteria
Für die Anwendung hat die Ausführung in einer solchen Umgebung einige Implikationen, sowohl technischer als auch fachlicher Natur. Einerseits ist für eine optimale Nutzung der Automatisierung ein Zuschnitt auf die Umgebung notwendig, zum Beispiel mithilfe der bereitgestellten Metriken. Andererseits sollte die Applikation in der Lage sein, mehrfach instanziiert zu werden. Für Webanwendungen mit einer Login-Funktionalität über Sessions heißt das beispielsweise, dass der Zustand der Session nicht in der Applikation gehalten werden darf. Eine Applikation, die diese Kriterien erfüllt, ist Cloud-nativ.
What is a microservice?
The definition of a Microservices is difficult to describe via lines of code or similar metrics, which might make the term misleading. It can be better described via functionality: A microservice is responsible for a functional domain, whereby domains create natural transaction boundaries. All data requiring strong consistency among each other form a domain. As such, microservices can be regarded a form of the single responsibility principle from software engineering, thought a step further.
