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.
Quarkus ist ein cloud-nativer Stack von Red Hat für die Entwicklung von Webanwendungen, basierend auf den Jakarta EE- und MicroProfile-Standards. Eine Quarkus-Applikation hat gegenüber einer mit gängigen Konkurrenzprodukten entwickelten Applikation eine deutlich kürzere Startzeit und einen erheblich geringeren Speicherbedarf, was besonders im Umfeld von Serverless Computing ein großer Vorteil ist.
Außerdem verfolgt Quarkus den Ansatz "Container First". Diese Eigenschaften machen Quarkus zu einer ausgezeichneten Wahl für den Einsatz in Cloud- und Container-Umgebungen.
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 |
Mehr als
200 Kund*innen vertrauen
ConSol in Sachen IT & Software
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 schon heute die Zukunft von cloud-nativen Java Applikationen!
Quarkus Workshops: Vom Antesten bis zum Produktiv-Deployment
Schnupperkurs, Deep Dive & Begleitung während der ersten Entwicklungstage
Während einige Bibliotheken und Features durch einen Standard genormt oder in ihrer Verwendung aus anderen Stacks bekannt sind, sind andere Quarkus-spezifisch. Zudem müssen sie korrekt in die Applikation integriert werden. Hierzu bieten wir die folgenden Trainings an, um Ihr Team und Sie in der Entwicklung von Quarkus-Applikationen zu schulen und auf den Produktiveinsatz vorzubereiten:
1 Tag: Überblick über die Grundfeatures von Quarkus
- Aufsetzen einer kleinen REST-Applikation von Grund auf
- Konfiguration der Anwendung mit Hinblick auf cloud-native Deployments
- Anbinden einer Persistenzschicht in Form einer relationalen Datenbank
- User Authentication über JWT Tokens, mit Basiskonfiguration eines Keycloak Servers
- Natives Kompilieren der Applikation
- Entwicklung von Unit Tests
- Containerisieren der Applikation
3 Tage: tiefergehendes Wissen in einzelnen Bereichen von Quarkus
- Aufsetzen eines Multi-Module-Projektes mit Maven
- Erstellen eines eigenen Docker Images
- Health- & Readiness-Checks, Implementierung von custom Checks
- MicroProfile Metrics
- @Counted, @Timed, @Gauge, @Metered
- Histogramme
- MicroProfile Fault Tolerance
- @Retry, @Timeout, @Fallback
- Circuit Breaker
- Konsumieren von REST-APIs mit MicroProfile REST Client
- MicroProfile OpenTracing
- Einbinden von Jaeger
- Konfiguration Requestübergreifender Spans
- Hibernate und Panache: Unterschiede, Gemeinsamkeiten
- Anbindung von Messaging-Systemen (JMS & Kafka)
- Einbindung von Apache Camel Mutiny für reaktive Programmierung
Wir begleiten Ihr Team und Sie in den ersten fünf Entwicklungstagen, coachen und stehen für Fragen und Problembehebung zur Verfügung, sodass Sie die bestmöglichen Resultate mit Quarkus erzielen.
Hinweis: Die Level bauen grundsätzlich aufeinander auf, sind jedoch je nach Kenntnisstand in Ihrem Unternehmen auch separat buchbar.
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.
Fit für's Cloud Computing: Noch Fragen rund um Quarkus Workshops?
Lassen Sie uns sprechen!
Judith Bato