© Just dance/Shutterstock.com
Erste Schritte mit Quarkus und MicroProfile

Nebenbuhler


Quarkus hat aus unterschiedlichen Gründen große Aufmerksamkeit auf sich gezogen. Es verbindet technologische Innovation und spannende Features mit hoher Produktivität für Entwickler. Gleichzeitig bietet es weitreichende Kompatibilität mit gängigen Lösungen, die Entwicklern seit Langem vertraut sind. Insbesondere bietet Quarkus die Möglichkeit, zeitgemäße Anwendungen für den Betrieb in der Cloud auf Basis von JAX-RS, CDI und Hibernate zu entwickeln, ergänzt um die Features des MicroProfile. Somit eröffnet es für Unternehmen mit Java-EE-Historie einen möglichen Pfad in die Zukunft. Wächst hier ein ernstzunehmender Konkurrent für Spring Boot heran?

Bereits seit längerer Zeit diskutieren Entwickler leidenschaftlich darüber, ob Java denn eigentlich gut für die Entwicklung zeitgemäßer Anwendungen und Architekturen aufgestellt ist. Es geht dann in der Regel um Themen wie Microservices, Cloud oder Serverless. Naturgemäß gibt es unterschiedliche Meinungen, jedoch lässt sich anhand verschiedener Kriterien ein klarer Trend ablesen: Als Framework für Neuentwicklungen hat Spring Boot aktuell eindeutig die Nase vorn – und Jakarta EE [1] (früher Java EE) ist ziemlich abgehängt.

Das hat im Wesentlichen zwei Gründe: Erstens wird Jakarta EE vielerorts noch immer mit dem Betrieb eines monolithischen Application-Servers gleichgesetzt, der nun wirklich nicht mehr in moderne IT-Infrastrukturen hineinpasst. Tatsächlich ist es aber längst so, dass auf Basis von Jakarta EE entwickelte Anwendungen als Runnable JARs gebaut und als vergleichsweise leichtgewichtige Prozesse betrieben werden können. Beim Vergleich der Frameworks sollte man sich also eher auf APIs, Features und Produktivität während der Entwicklung konzentrieren.

Dies führt zum zweiten Grund für die Favoritenrolle von Spring Boot: Im Zuge der Übergabe der Java-EE-Plattform von Oracle an die Eclipse Foundation erfolgte über mehrere Jahre praktisch keinerlei technischer Fortschritt mehr an den APIs. Das wird sich zwar hoffentlich in naher Zukunft ändern, der aktuelle Stand gilt aber zu Recht als nicht mehr zeitgemäß und bietet für die genannten Einsatzgebiete in vielen Fällen schlicht zu wenig Unterstützung. Auch in Sachen Produktivität ist Spring Boot enteilt.

Doch auch Spring Boot erfüllt nicht alle Anforderungen zufriedenstellend. So entstehen beim Build vergleichsweise große Artefakte, die dann zu deployen und zu starten sind. Zudem sind die Start-up-Zeiten und der Ressourcenverbrauch zur Laufzeit im Vergleich mit anderen Technologien immer noch recht hoch. All dies führt im Cloud-Betrieb letztlich zu (Mehr-)Kosten, die zu reduzieren im Sinne des Anwendungsbetreibers wäre. Und nicht zuletzt gibt es auch weiterhin zahlreiche Unternehmen, die über viele Jahre hinweg große Investitionen in die Entwicklung und Wartung von Java-EE-Anwendungen getätigt haben. Für sie wäre eine Zukunftsperspektive wünschenswert, wie zumindest existierende Anwendungen auf der gleichen Plattform weiterentwickelt und modernisiert werden können, ohne dass eine Neuentwicklung bedeutender Codeanteile auf Basis eines neuen Frameworks wie Spring Boot notwendig wird.

So haben sich im Windschatten des großen Erfolgs von Spring Boot einige interessante Alternativen entwickelt. Zum einen ist hier das MicroProfile [2] zu nennen. Dabei handelt es sich um eine Reihe von APIs, die als Erweiterung von Jakarta EE dienen sollen und eine ganze Menge von Features implementieren, die man typischerweise für den Einsatz in der Cloud oder in Microservices-Architekturen benötigt. So werden etwa Metriken, Health Checks, JSON Web Tokens, OpenAPI, Open Tracing oder Strategien zur Fehlertoleranz unterstützt. Hier geht es also darum, den aktuellen Rückstand der Jakarta-EE-Plattform wettzumachen. Im Wesentlichen wird vieles kopiert, das Spring Boot bereits seit Längerem bietet. Das ist aber nicht unbedingt negativ zu bewerten, ist es doch besser, andernorts bewährte Konzepte zu übernehmen, als das Rad immer neu zu erfinden. Die Funktionalität der Frameworks wird sich also mit der Zeit zunehmend angleichen. Eine ausführliche Betrachtung des MicroProfile war bereits in [3] zu lesen.

Ein weiterer interessanter Trend ist die Entwicklung zahlreicher neuer (Micro-)Frameworks, die die Entwicklung von Cloud-basierten Anwendungen oder Microservices erleichtern wollen. In diesem Bereich entstehen aktuell viele Ideen und Konzepte. Ein besonders spannender Kandidat ist Quarkus [4] aus dem Hause Red Hat. Es bietet sehr gute Unterstützung für Container und Kubernetes sowie vor allen Dingen die Möglichkeit, eigene Anwendungen oder Services mit Hilfe der GraalVM [5] in ein natives Image zu kompilieren. Damit geht das Konzept des „Write once, run anywhere“ zwar verloren, für den produktiven Betrieb von Anwendungen ist das jedoch im Zeitalter von Docker ohnehin nur noch von geringer Bedeutung. Dafür ergeben sich durch den Einsatz von nativen Images jedoch extrem schnelle Start-up-Zeiten und ein deutlich reduzierter Ressourcenverbrauch, was für den Einsatz in der Cloud ausgesprochen attraktiv ist. Ein weiterer interessanter Aspekt von Quarkus liegt darin, dass es sowohl die wichtigsten Jakarta EE APIs bzw. darauf basierende Frameworks unterstützt (u. a. JAX-RS, CDI und Hibernate) als auch die APIs des MicroProfile. Somit lassen sich auf modernstem technologischem Fundament zeitgemäße Anwendungen auf Basis der bekannten Jakarta EE APIs entwickeln.

Probieren geht über …

Als Proof of Concept soll mit Quarkus ein kleiner Service implementiert werden, der Zugriff auf Produktdaten im JSON-Format bietet, auf Basis von JAX-RS implementiert ist und gleichzeitig den Einsatz von MicroProfile-Features demonstriert. Während dieser Artikel verfasst wird, liegt Quarkus in Version 1.4.2 vor. Dieses Release unterstützt die ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang