Interview mit Alex Soto

Quarkus – Gegenwart und Zukunft des leichtgewichtigen Java Frameworks

Hartmut Schlosser

© Shutterstock / Ezume Images

Was bedeutet „Container first“? Welche Stärken hat das Fremwork Quarkus? Und welche neuen Features bringt Update 0.20? Diese und weitere Fragen beantwortet Alex Soto, Java Champion und Director of Developer Experience bei Red Hat, im Interview. Er geht dabei auch darauf ein, was für die Zukunft von Quarkus geplant ist und wann Version 1.0 das Licht der Welt erblicken wird.

JAXenter: Quarkus ist ein relativ neues Framework, welches die leichtgewichtige Entwicklung von Java-Anwendungen nach dem „Container-first“-Prinzip verspricht. Was ist in dem Zusammenhang mit „Container first“ gemeint?

Alex Soto: „Container first“ bedeutet, dass von Anfang an alles darauf ausgelegt ist, möglichst problemlos innerhalb eines Containers zu funktionieren. Probleme, die sich nicht mit der Anwendung selbst befassen, werden weitestgehend ausgeblendet. Um dieses Ziel zu erreichen haben wir zwei unterschiedliche Ansätze verfolgt:

Zunächst stellten wir eine Möglichkeit zur Verfügung, Enterprise-Anwendungen in nativen Code zu kompilieren. Dies ist essentiell wichtig, da eine JVM-Anwendung, die in einem Container läuft, ohne jeglichen ersichtlichen Grund einfach sprichwörtlich in die Luft fliegen kann – ein Problem, das in der Java Community bekannt ist. Der wahre Grund für die Crashs ist die Tatsache, dass Java (und die JVM) sehr viel älter ist als es Linux (und Docker) Container sind. Bei der Erschaffung der JVM hatte man das Konzept von Containern noch nicht im Blick und so versucht der Prozess so viel Speicher und CPU-Kapazitäten wie möglich zu nutzen. Packt man eine Java-Anwendung (insb. eine Java-8-Anwendung) in einen Container, versucht die JVM ganz nach ihrem Design, so viele Ressourcen wie möglich zu nutzen, auch über die Grenzen des Containers hinaus. Geschieht dies, stoppt der Linux-Kernel den Container und dementsprechend auch den Prozess, der in ihm läuft.

Eines der Ziele von Quarkus ist, Java als mögliche Sprache für Microservices und Serverless-Architekturen zu etablieren.

Auch wenn dies in den letzten Jahren verbessert wurde und Java 11 fit für den Einsatz in Containern ist, muss man nach wie vor erst einmal wissen, wie man das Ganze möglich macht. Quarkus löst das Problem, indem ein Weg bereitgestellt wird, unter Zuhilfenahme der GraalVM eine nativ ausführbare Version einer Enterprise-Java-Anwendung zu erstellen. Hierdurch erhält man für seine Java-Anwendung im Container die gleiche Verhaltensweise wie mit jedem anderen nativ kompilierten Programm, das etwa in Go oder C++ geschrieben ist.

Der zweite Ansatz ist, keine großen Uber-JARs zu erstellen. Stattdessen setzen wir auf kleine Uber-JARs, damit eine schnelle Build-Zeit gewährleistet werden kann. Dieses Feature ist dann nützlich, wenn man keine nativ ausführbaren Anwendungen erstellt, sondern Quarkus-Anwendungen (oder -Services) im JVM-Modus mit Java (11) ausführt. Andere Frameworks verfolgen das Konzept, die Anwendung selbst und die notwendigen Bibliotheken in das JAR zu packen, das am Ende ausgegeben wird. Das ist per se kein Problem, wenn man keinen Container erstellt, um das Programm auszuführen. Nutzt man aber die Container-Technologie (Docker), werden die Dinge etwas interessanter. Ein Docker-Container wird in Ebenen (Layers) generiert. Jeder Schritt, der beim Erstellen eines Containers durchgeführt wird, wird in einem Layer gespeichert, der dann für andere Builds wiederverwendet werden kann.

Nutzt man nun schwere und große Uber-JARs, bedeutet das, dass man bei jeder noch so kleinen Änderung neue Ebenen erstellt, deren Größe im zweistelligen Megabyte-Bereich liegt, denn der Anwendungs-Layer ist eben die Anwendung selbst und alle Abhängigkeiten. Mit Quarkus werden zwei Artefakte erstellt: Ein JAR enthält den ausführbaren Code und ein anderes JAR (ein Verzeichnis) enthält alle Abhängigkeiten. Effektiv bedeutet dies, dass im Container zwei Layer erstellt werden, einer für den Code, der andere für die Abhängigkeiten. Ändert man nun etwas im Code, wird nur eine sehr kleine neue Ebene angelegt, denn die mit den Abhängigkeiten wird einfach wiederverwendet.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

JAXenter: Wie kam das Projekt zustande? Wer hat es vorangetrieben und mit welcher Motivation wurde Quarkus entwickelt?

Alex Soto: Quarkus wird von Red Hat gesponsert, aber es arbeiten viele Einzelpersonen daran mit, die nichts mit Red Hat zu tun haben. Das Projekt hat zwei Hauptziele: Eines ist, die Developer Experience beim Entwickeln von Microservices zu verbessern. Das zweite Ziel ist, Java als mögliche Sprache für Microservices und Serverless-Architekturen zu etablieren.

JAXenter: Was sind die Stärken von Quarkus?

Alex Soto: Die richtige Antwort auf diese Frage kommt ein wenig darauf an, wer genau sie liest. Eine große Stärke von Quarkus ist, dass es dabei hilft, Geld zu sparen. Früher hat jedes Unternehmen große Investitionen in die Hardware machen müssen, auf denen die Anwendungen laufen sollten. Heute sind wir bereits in der Cloud-Ära angelangt, kaufen also die Hardware nicht mehr selbst, sondern bezahlen für deren Nutzung. Je mehr CPU- und RAM-Ressourcen wir benötigen, desto mehr bezahlen wir, sodass heutzutage die Kosten in den entsprechenden Kapazitäten liegen, die wir verbrauchen. Da Quarkus im nativen Modus die Notwendigkeit für CPU-Ressourcen durch eine Verkürzung der Zeit für das Booten und die Zeit pro Request verringert sowie den nötigen Speicher um den Faktor 10 im Vergleich zu anderen traditionellen Java Frameworks verringert, lässt sich Geld sparen. Aber diese Reduktion des Ressourcenverbrauchs ist nicht nur im nativen Modus evident, selbst bei Verwendung der JVM ist der Speicherverbrauch um den Faktor 2 geringer.

Eines der beliebtesten Features von Quarkus ist das Live Reloading. Andere Sprachen haben dieses Features bereits, aber für Java-Entwickler ist es etwas ziemlich Neues. Mit Live Reloading ist es möglich, Änderungen in irgendeiner Datei der eigenen Anwendung zu ändern, etwa in einer Klasse, ohne die gesamte Anwendung neu kompilieren oder zu einem Package zusammenfügen zu müssen. Die Änderungen werden automatisch in der laufenden Instanz der Anwendung dargestellt. Früher musste man dafür die gesamte Anwendung neu kompiliert und gepackt werden, dann musste die vorherige Instanz gestoppt und die Anwendung komplett neu gestartet werden. Mit Quarkus und dem Live Reloading muss nur die Änderung gespeichert werden, woraufhin umgehend diese Änderung in der laufenden Instanz verfügbar ist. Keine Kompilierung, kein neues Packen und kein Neustart sind nötig.

Eines der beliebtesten Features von Quarkus ist das Live Reloading.

Für Entwickler, die JPA Code schreiben, ist die Integration des Panache Frameworks ein großer Vorteil. Die Menge an benötigtem Boilerplate-Code, der in den Datenzugriffs-Layer geschrieben werden muss, wird signifikant reduziert.

Zu guter Letzt basiert Quarkus auf vielen wohlbekannten Spezifikationen wie JAX-RS, JPA, CDI, Bean Validation und MicroProfile. Man kann also sein ganzes Fachwissen diesbezüglich auch in Verbindung mit Quarkus nutzen. Das gilt im Übrigen auch andersherum: Alles, was man über diese Spezifikationen in Quarkus-Projekten lernt, lässt sich auch in anderen Projekten anwenden, die nicht auf Quarkus basieren. Der Vorteil daran ist, dass man nicht lernen muss, jedes Framework einzeln zu beherrschen.

JAXenter: Quarkus 0.20.0 wurde gerade veröffentlicht. Was sind die Highlights des neuen Releases?

Alex Soto: Diese Version wurde bereits vor einiger Zeit veröffentlicht, neue Releases kommen im Turnus von zwei Wochen. Version 0.20.0 hatte die folgenden Features an Bord:

  • Multi-Line-Unterstützung in Hibernate-ORM-Importskripten
  • Verbesserte Integration des Hibernete Validators in CDI
  • Eine neue Implementierung des MicroProfile REST Clients
  • Upgrade auf MicroProfile Metrics 2.0
  • Konfiguration eines Per-Method-Transaktions-Timeouts
  • Unterstützung von Syslog für das Logging
  • Unterstützung von Jackson als Marshaler/Unmarshaler
  • Unterstützung von OAuth 2
  • Eine neue Anleitung für das Deployment von Quarkus auf Microsoft Azure

Natürlich wurden auch wieder etliche Bugs gefixt sowie vorhandene Features und die Performance verbessert.

JAXenter: Wie sieht die kurzfristige Planung aus – welche neuen Features und Versionen sind geplant?

Alex Soto: Da es sich bei Quarkus um ein Open-Source-Projekt handelt, wird Version 1.0.0 genau dann fertig sein, wenn sie fertig ist. Allerdings planen wir schon damit, dieses Release noch im laufenden Jahr zu veröffentlichen. Wir sind sehr zuversichtlich, was die Qualität des Codes von Quarkus angeht. Zumindest können wir sicher sein, dass der Runtime-Code nur Frameworks aufruft, die solide sind (Netty, Vert.x, RESTEasy, Hibernate ORM, Camel usw.). Der Grund, warum Quarkus noch nicht in Version 1.0 erschienen ist, ist darin begründet, dass wir noch nicht so weit sind, alle Erweiterungs-APIs in Stein zu meißeln. Wir arbeiten zudem am Ökosystem-Modell und wollen es für Version 1.0 fertig haben.

Viele Unternehmen nutzen Quarkus trotz allem bereits in der Produktion. Dies ist auch kein Problem, da Versionsnummern am Ende eben nur Nummern sind. Wir behandeln jedes Release so, dass es am Ende reif für die Produktion ist.

Wir behandeln jedes Release so, dass es am Ende reif für die Produktion ist.

Für die nächsten Releases von Quarkus haben wir eine Menge neuer Features geplant. Unter anderem wollen wir die Developer Experience kontinuierlich verbessern. Dafür wollen wir neue Funktionen anbieten, die das alltägliche Entwicklerleben erleichtern. Zudem wollen wir das „Panache-Konzept“ auch für andere Backends als JPA nutzbar machen.

Der HTTP Stack wird von uns aktuell weitergedacht, sodass eine sehr tiefe Verbindung zwischen Netty, Vert.x, Undertow und RESTEasy etabliert werden kann. Dies stellt ein wichtiges Fundament für die Zusammenführung von imperativer und reaktiver Entwicklung dar, aber auch im Bereich Serverless wird dies Vorteile bringen. Gleichzeitig sind wir dabei, die Sicherheits-Layer zu vereinen, um sie evolutiver zu machen und sie leichter über den Stack zu verteilen. Zu guter Letzt arbeiten wir an weiteren Integrationen mit Frameworks wie Vault oder JMS.

Alex Soto is a Software Engineer at Red Hat in the developers group. He is passionate about the Java world and software automation, and he believes in the open source software model. Alex is the creator of the NoSQLUnit project, a member of the JSR374 (Java API for JSON Processing) Expert Group, co-author of the Testing Java Microservices book for Manning and contributor to several open source projects. A Java Champion since 2017 and international speaker, he has talked about new testing techniques for microservices and continuous delivery in the 21st century.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: