4 Vorteile
Einsatz von Quarkus in der Finanzbranche
Quarkus: Next Gen Java für Cloud-native Umgebungen
Java ist als erste plattformunabhängige Sprache entwickelt worden und hat als solche neue Maßstäbe gesetzt: sei es mit der JVM, als bevorzugte Plattform für Android-Entwicklung oder mit Standards wie Java EE. Moderne Technologien wie Cloud Computing, Microservices und Containerisierung stellen Java jedoch vor neue Herausforderungen.
Denn die Java-Sprache ist ursprünglich für serverbasierte Computerprogramme konzipiert worden und daher nicht für die Cloud optimiert. Dies fällt unter anderem auf im Vergleich mit anderen Sprachen wie Node.js oder Go.
| Klassische Java-Webframeworks oder Applikationsserver | Quarkus |
|---|---|
| speicherhungrig | minimaler Speicher-Bedarf |
| lange Startzeit | sehr kurze Startzeit |
| nicht gut geeignet für Serverless Computing | exzellent geeignet für Serverless Computing |
| braucht JVM | nativ kompilierbar mit GraalVM |
| Σ fördert den Einsatz in der Cloud nicht, behindert ihn teilweise | Σ ideal für den Einsatz in der Cloud |
Quarkus macht Ihr Business schneller
Erfüllt Java Code bestimmte Voraussetzungen, kann er mittels GraalVM zu einer nativen Applikation kompiliert werden. Die native Applikation startet dadurch bis zu 30x schneller, der Speicherbedarf der Applikation sinkt auf bis zu ein Zehntel des traditionellen Cloud-native-Stacks.
Wenn eine native Kompilierung gewünscht wird, kann nicht jede Bibliothek in eine Quarkus-Applikation eingebunden werden. Quarkus bietet jedoch ein reichhaltiges Ökosystem von Bibliotheken an, die native Kompilierung unterstützen - sowohl von Red Hat als auch von der Community gepflegt. Hierzu zählen Bibliotheken wie undertow, RESTEasy und Hibernate ORM. Hinzu kommen Quarkus-spezifische Features, die das Entwickeln von und mit Quarkus-Applikationen vereinfachen, wie beispielsweise:
- Integration mit Maven und Gradle
- Command-Line-Tooling zum Management Quarkus-spezifischer Abhängigkeiten
- Targets zum Erstellen einer nativen Applikation
- ein mächtiger Entwicklungsmodus für schnelles Feedback während der Entwicklung
- Testen mit JUnit5 und Rest Assured
- Testen nativer Applikationen
Interesse? Dann entdecken Sie die Zukunft von cloud-nativen Java Applikationen - schon heute!
Wichtige Begriffe rund um Quarkus & Java
Was ist Jakarta EE?
Jakarta EE ist ein offener Standard der Eclipse Foundation und der Nachfolger von Java EE 8. Der Standard definiert APIs für Features und das zugehörige Verhalten. Zu den definierten Features gehören Dependeny Injection (CDI, JSR 365), Definition von RESTful Web Services (JAX-RS, JSR 370), Mapping von Java-Objekten auf relationale Datenbanken (JPA, JSR 338) und Verarbeitung von XML und JSON (JSR 221, JSR 222, JSR 367 und JSR 338).
Die Umsetzung erfolgt in den Bibliotheken bzw. Applikationsservern, welche den Standard implementieren: beispielsweise Tomcat, Glassfish, Payara und Quarkus.
Was ist MicroProfile?
Der MicroProfile-Standard setzt auf Jakarta EE auf. Wie Jakarta EE ist auch MicroProfile quelloffen und wird von der Eclipse Foundation entwickelt. Die Features zielen auf die Implementierung von Microservices ab. So finden sich beispielsweise APIs für die Definition von REST Clients, Überwachung der Applikation, Auslesen von Statistiken - sowohl technischer als auch fachlicher Natur und zur Konfiguration der Applikation.
Wie auch bei Jakarta EE erfolgt die Umsetzung bei MicroProfile in den Bibliotheken bzw. Applikationsservern, welche den Standard implementieren.
Was ist GraalVM?
GraalVM ist eine von Oracle entwickelte JVM auf der Basis von Java 8 und Java 11. GraalVM wird sowohl kostenlos und quelloffen (GraalVM CE) als auch kommerziell mit Support und weiteren Laufzeitoptimierungen (GraalVM EE) angeboten. GraalVM CE darf produktiv eingesetzt werden.
Neben dem Ziel, die Laufzeit von Java Programmen zu optimieren, bietet GraalVM die Möglichkeit, Java-Programme in nativ ausführbare Binärdateien zu übersetzen. Dieses Feature ist allgemein als "Ahead-of-Time (kurz: AoT) compilation" bekannt, im GraalVM-Ökosystem heißt dieses Feature "native-image". Das primäre Ziel von nativ kompilierten Java-Programmen ist nicht die Optimierung der Laufzeit, sondern die Optimierung von Prozessor- und Speicherauslastung.
Warum Cloud-nativ und was macht Applikationen Cloud-nativ?
Automatisierung
Hardware ist unzuverlässig, Software ist komplex. Hardwarekomponenten fallen aus, Applikationen müssen neu gestartet werden. In beiden Fällen ist ein manueller Eingriff notwendig, und der Prozess ist zeit- und kostenintensiv. Bei der Verwendung einer containerisierten Infrastruktur, beispielsweise über Kubernetes, können viele Vorgänge automatisiert werden. Fällt beispielsweise Hardware aus, so werden die Container, die von dem Ausfall betroffen sind, automatisch auf nicht betroffener Hardware neu gestartet.
Containerisierung bietet ferner die Möglichkeit der horizontalen Skalierung: Ist die Last auf einer Applikation zu hoch, so wird sie mehrmals instanziiert und die Last wird auf alle Instanzen der Applikation verteilt. Verringert sich die Last, werden nicht mehr benötigte Instanzen gestoppt. Dies kann über Metriken automatisiert werden, welche die containerisierte Applikation über ihren Zustand bereitstellt. Der Trend hier ist Automatisierung, eine der Grundsäulen des Site Reliability Engineerings.
Cloud-native Kriterien
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.
Was ist ein Microservice?
Die Definition eines Microservices lässt sich schlecht über Codezeilen oder ähnliche Metriken ausdrücken, wodurch der Begriff irreführend sein kann. Besser lässt er sich über die Fachlichkeit definieren: Ein Microservice ist für eine fachliche Domäne verantwortlich. Hierbei bilden Domänen natürliche Transaktionsgrenzen. Alle Daten, die untereinander starke Konsistenz benötigen, bilden eine Domäne. Als solches können Microservices als eine weiter gedachte Form des Single Responsibility Prinzips aus dem Software Engineering gesehen werden.
Ihr Ansprechpartner
Christoph Ehlers