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.

Quarkus makes
Java play nice
in the cloud

Quarkus is a cloud-native Red Hat stack for for developing web applications, based on Jakarta EE and MicroProfile standards. Compared with an application developed using common competitor products, a Quarkus application provides a much shorter start time and significantly lower memory requirements, a great advantage especially in serverless computing environments.

Quarkus also pursues the "
container first" approach. These qualities make Quarkus an excellent choice for use in cloud and container environments.

Classic Java Webframe Works or Application ServerQuarkus
memory demandingminimal memory requirements
long start timevery short start time
not well suited for serverless computingexcellent for serverless computing
needs JVMnatively 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!

Quarkus Workshops: From Testing to Productive Deployment

Trial Course, Deep Dive & Support During the First Days of Development

 

While some libraries and features are standardized or their use is known from other stacks, other libraries are Quarkus-specific. They also have to be correctly integrated into the application. In order to enable you and your team to do that and to train you for the development of Quarkus applications as well as for productive use, we offer the following workshops.

1 Day: Quarkus Basic Features at a Glance

  • Setting up a small REST application from scratch
  • Configuring the application with regard to cloud native deployments
  • Linking a persistence layer in the form of a relational database
  • User authentication via JWT tokens, including the basic configuration of a Keycloak server
  • Native compiling of the application
  • Developing Unit Tests
  • Containerizing the application

3 Days: In-depth knowledge of individual Quarkus segments

  • Setting up a multi module project with Maven
  • Creating an own docker image
  • Health & readiness checks, implementing custom checks
  • MicroProfile Metrics
    • @Counted, @Timed, @Gauge, @Metered
    • Histogramme
  • MicroProfile Fault Tolerance
    • @Retry, @Timeout, @Fallback
    • Circuit Breaker
  • Consuming REST-APIs with MicroProfile REST client
  • MicroProfile OpenTracing
    • Integrating Jaeger
    • Configuring request independent spans
  • Hibernate and Panache: differences, common features
  • Integrating messaging systems (JMS & Kafka)
  • Integrating Apache Camel Mutiny for reactive programming

We support you and your team during the first five days of development. We coach you and are available for questions and bug fixes, this way you achieve the best possible results with Quarkus.

Tip: Basically, the levels build on each other but can also be booked separately, depending on the level of knowledge in your company.

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.

Contact

Thomas Pietrzykowski

Managing Director

+971 4509 9003