Suche
Unsere Interview-Serie zu Jakarta EE: Mark Struberg, Softwarearchitekt bei Research Industrial Systems Engineering (RISE)

Jakarta EE im Klartext: „Ich bin kein Fan von all dem Buzz um Cloud-native und Microservices“

Dominik Mohilo, Gabriela Motroc

© Shutterstock / LuckyN (modifiziert)

Na, auch ein wenig den Anschluss in Sachen Jakarta EE verloren? Das macht nichts. In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll. Unser heutiger Gast ist Mark Struberg, MicroProfile Spezifikationsautor und Softwarearchitekt bei Research Industrial Systems Engineering (RISE)

Es ist wahrlich kein leichtes Unterfangen, dieser Umzug der Java-EE-Technologie von Oracle zur Eclipse Foundation. Die Marke „Jakarta EE“ entwickelt sich prächtig und schnell. Zeit, für einen Moment innezuhalten und all die Pläne und Veränderungen Revue passieren zu lassen, um die Technologie fit für die neuen Herausforderungen in Sachen Cloud, Containern, Microservices, Serverless und reaktiver Programmierung zu machen.

Die Vision der technischen Zukunft von Jakarta EE beinhaltet Folgendes:

  • Eine verbesserte Unterstützung von Microservices-Architekturen.
  • Der Weg hin zu Cloud-native Java, was unter anderem die bessere Integration mit Technologien wie Docker und Kubernetes bedeutet.
  • Das Beschleunigen der Innovationsgeschwindigkeit.
  • Den Aufbau einer aktiven und engagierten Entwickler-Community.
  • Das Bereitstellen von produktionsreifen Referenzimplementierungen.

Immer auf dem Laufenden zu bleiben, was in Sachen Jakarta EE gerade in und was gerade out ist, bleibt ein kontinuierlicher Prozess. Mit Sicherheit können allerdings die bereits akzeptierten und in der Eclipse Foundation offiziell verorteten Projekte identifiziert werden. Unsere Liste von bereits angenommenen Projektvorschlägen hilft dabei, sich einen Überblick über den Status Quo zu verschaffen, aber das ist natürlich nur die Spitze des Eisbergs.

Welchen Herausforderungen sieht sich Jakarta EE derzeit gegenüber? Welche werden wohl in naher Zukunft aufkommen? Wohin geht die Reise überhaupt und wie wird die Zukunft von Enterprise Java aussehen? Mit unserer Interview-Serie wollen wir euch helfen, die aktuellen Entwicklungen im Blick zu behalten. Unsere Experten beleuchten die Hintergründe und klären darüber auf, wie es um die Zukunft der Technologie bestellt ist und wie man plant, Jakarta EE als neues Zuhause für Cloud-native Java zu etablieren.

Unsere Interview-Reihe: Jakarta EE im Klartext

In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll.

Ab geht die Reise ins Jakarta-EE-Universum mit unseren Experten!

Unser heutiger Experte ist Mark Struberg, Softwarearchitekt bei Research Industrial Systems Engineering (RISE). Ab geht die Reise ins Jakarta-EE-Universum!

JAXenter: Hallo, Mark! Glaubst du, es wäre eine gute Idee, Eclipse MicroProfile mit Jakarta EE zu verschmelzen?

Mark Struberg: Oh, das ist eine komplizierte Frage. Um dies zu beantworten, muss man zwischen drei Aspekten unterscheiden.

  1. Der Community-Aspekt: Tatsächlich gibt es große Überschneidungen im Hinblick auf die Beteiligten. Also sind sie eigentlich schon miteinander verschmolzen.
  2. Der Plattform-Aspekt: MicroProfile begann als „inoffizielles“ Java-EE-Profil, dessen Ziel es war, noch leichtgewichtiger zu sein, als das offizielle Java EE WebProfile. Natürlich ist MicroProfile noch kein offizielles Java-EE-Profil, aber wahrscheinlich könnte es in absehbarer Zeit von Jakarta EE offiziell ratifiziert werden!
  3. Spezifikationsarbeit: Während MicroProfile zunächst nur mit Java-EE-Spezifikationen (CDI + JAX-RS + JSON-P) anfing, begannen wir bald mit der Arbeit an unseren eigenen Spezifikationen. Vor allem in den Bereichen, die schon lange Teil von Java EE sein sollten, aber die es aufgrund der EE-8-Verzögerung nicht geschafft haben. Wie z. B. microprofile-config, microprofile-health, microprofile-open-API und so weiter. In diesem Bereich gibt es einen echten Unterschied zwischen MicroProfile und Jakarta EE. MicroProfile versteht sich selbst als einen Ort, an dem wir Innovationen vorantreiben. Das bedeutet, dass wir aktiv die Grenzen verschieben und ausweiten, viel aggressiver als man es Java EE selbst tat. Das bedeutet auch, dass wir uns die Möglichkeiten lassen, APIs auf eine nicht rückwärtskompatible Art und Weise umzubauen. Bisher war das noch nicht nötig, aber theoretisch könnten wir das tun. Und das ist gut so. Ansonsten würden wir durch das Fehlen eines Rückwegs sämtlichen Fortschritt blockieren.

Jakarta EE ist hingegen der Ort für Standardisierungen. Man nimmt bestehende Ideen auf und versucht, einen kleinsten gemeinsamen Nenner zu definieren, der dann als gemeinsamer Standard festgelegt wird. Können diese beiden Aspekte kombiniert werden? Wahrscheinlich wird MicroProfile zu einer Art Inkubatorprojekt für Jakarta EE werden.

Im Moment bestimmt die MicroProfile Community ihr eigenes Tempo und deht geltende Grenzen immer weiter aus. Und das wird so bleiben, zumindest bis Jakarta EE an Fahrt gewinnt und Jakarta EE 9 veröffentlicht wird. Also fragt mich besser Anfang 2019 noch einmal 😉

JAXenter: Der Pfad, den man mit Jakarta EE beschreiten möchte, wurde bereits klar definiert und nennt sich Cloud-native Java. Wie erreicht man dieses Ziel?

Ich bin kein Fan von all dem Buzz um Cloud-native und Microservices.

Mark Struberg: Um ehrlich zu sein, bin ich kein Fan von all dem Buzz um „Cloud-native“ und Microservices. Für mich ist dieser Begriff etwas zu sehr marketingorientiert. Für 70% aller Geschäftsprojekte macht das Ganze keinen Sinn, aber viele Unternehmen werden – aus verschiedenen Gründen – ihre hausintern gehosteten Systeme und Multi Node Cluster behalten. Wir mussten für Jakarta EE lediglich ein paar große Themen als Etikett sammeln und zeigen, dass wir auf dem neuesten Stand sind. Natürlich freue ich mich darüber, wenn es für die Leute im Marketing so funktioniert. Und wenn es dabei hilft, Jakarta EE zu verbreiten, dann bin ich damit völlig einverstanden.

Natürlich müssen wir Container ebenso unterstützen, wie Sevice Discovery oder verschiedene Design-Patterns wie z. B. Circuit Breaker usw. Aber alle diese Teile sind nicht nur in Cloud- und Microservices-Umgebungen einsetzbar. Sie werden dann wirklich benötigt, wenn man Systeme hat, die miteinander kommunizieren. Und ja, dazu gehört auch, dass ein alter Java-EE-Business-Monolith mit SAP, einem Dokumentarchivserver oder einem anderen dezentralen System kommuniziert. Für solch eine Kommunikation ist das Verwenden von Circuit Breakern oder Bulkheads eine wirklich gute Idee. Umso besser ist es, wenn es nur darum geht, eine Annotation hinzuzufügen (wie z. B. bei microprofile-fault-tolerance). Ich erwarte, dass Jakarta EE 9 die in MicroProfile geleistete Arbeit für diese Teile aufnimmt.

Bitte beachtet, dass die nächste Version von Jakarta EE, Jakarta EE 8 und nicht 9 sein wird! Jakarta EE 8 wird im Wesentlichen denselben Inhalt wie Java EE 8 haben, allerdings mit einer viel offeneren Lizenz, offenen TCKs (endlich!) und einer offenen Community. Wer heute „Cloud-native“ Patterns verwenden möchte, der sollte sich MicroProfile ansehen.

JAXenter: Wie kann Jakarta EE die Cloud-bezogenen Bedürfnisse der Nutzer befriedigen?

Mark Struberg: Falsche Frage. Es sollte, meiner Meinung nach, nicht um „Cloud-Bedürfnisse“, sondern um allgemeine „User-Bedürfnisse“ gehen! Die Leute haben einfach nur all die neuen, glänzenden Spielsachen im Blick und vergessen dabei, dass es nichts umsonst gibt. *Jede* Designentscheidung bringt nicht nur neue Features mit sich, sondern hat auch immer einen Nachteil!

Bei „Cloud-native“ denken die meisten Benutzer an Netflix. Aber 98% aller Anwendungen sind nicht im „Netflix-Stil“! Netflix hat eine wirklich coole Architektur und einen enormen Durchsatz. Java EE hingegen wird hauptsächlich zum Aufbau von Geschäftsprojekten verwendet – mit völlig unterschiedlichen Anforderungen. Dabei steht nicht so sehr der reine Durchsatz im Vordergrund, sondern die Datenintegrität und die „funktionale Skalierung“ alias Wartbarkeit. Die Datenkonsistenz ist bei den meisten Geschäftsprojekten wirklich entscheidend!

Netflix hingegen benötigt in den meisten Fällen überhaupt keine Transaktionssicherheit. Wenn ein Film nicht mit dem Streaming beginnt, drückt man ganz einfach erneut die Wiedergabetaste. Man vergleiche das jetzt mit einer Leasinggesellschaft, bei der eine Zeile in einer Datenbank einen Leasingvertrag für ein Gebäude im Wert von 15 Millionen Euro darstellen könnte… Bezeichnet mich als übervorsichtig, aber ich persönliche fühle mich viel besser, wenn ich das richtige Commit/Rollback-Handling für diese Art von Apps verwende.

Die simple Wahrheit ist die, dass es wirklich schwierig ist, Sachen wie z. B. handgeschriebene Kompensationslogik und so weiter richtig hinzubekommen. Für die meisten Anwendungen und Teams ist es daher viel besser, einfach eine implizite Transaktionsabwicklung mit einem automatischen Rollback zu haben, falls eine unerwartete Exception auftritt. Genau hier glänzt Enterprise Java. Wenn wir nun diese vorhandenen Stärken mit neuen Patterns wie Bulkheads, Circuit Breakern, long-running Actions usw. kombinieren können, dann wäre dies ein wirklich großer Gewinn und ein hervorragender Mehrwert für die Anwender. Darauf sollte sich Jakarta EE meiner Meinung nach konzentrieren.

JAXenter: Konzentrieren wir uns auf die Ergebnisse des Jakarta EE Surveys. Über 60 Prozent der Teilnehmer würden eine bessere Unterstützung von Microservices begrüßen. Wie würdest du dem nachkommen?

Mark Struberg: Das MicroProfile-Projekt enthält bereits die meisten Antworten. Zumindest aus technischer Sicht.

Aber ich will es ganz deutlich sagen: Meistens sind nicht die Tools das Problem. Es gibt viele gute Tools in Java EE und in anderen Projekten. Man kann sich einfach Apache DeltaSpike anschauen und man wird feststellen, dass vielen von ihnen bereits seit Java EE 6 funktionieren.

Das Problem ist, dass die Menschen beim Wechsel zu Microservices eine völlig andere Denkweise entwickeln müssen! Auch die Umstellung auf Spring Boot wird diese Probleme nicht lösen. Ich habe bereits die fehlenden Transaktionsgarantien und die Fehlerbehandlung als zwei Kernprobleme erwähnt. Aber es gibt noch viel mehr Bereiche, die grundlegend anders funktionieren. Ich gebe mal eine Analogie: Wenn man einem Anfänger erklärt, dass er userTransaction.commit() aufrufen soll, wird seine Anwendung nicht über Nacht magisch konsistent. Er muss wirklich erst lernen, die Konzepte dahinter zu verstehen und zu leben.

Jakarta EE und MicroProfile sollten darauf abzielen, diesen Lernprozess so schnell wie möglich zu gestalten.

JAXenter: Die native Integration von Kubernetes ist ein weiterer wichtiger Faktor, wie die Umfrage gezeigt hat. Sollte dies für Jakarta EE eine Priorität darstellen?

Ich bezweifle, dass das Kubernetes von heute, in drei Jahren immer noch das gleiche Kubernetes sein wird.

Mark Struberg: Kubernetes ist wirklich nett. Gerade jetzt allerdings ist es eine sehr unstete Sache. Ich bezweifle, dass das Kubernetes von heute, in drei Jahren immer noch das gleiche Kubernetes sein wird.

Die meiste Zeit denke ich, dass die Jakarta-EE-Spezifikationen sich nicht um Kubernetes kümmern müssen. Geschweige denn um irgendeinen anderen Container, was das angeht. Das alles sollte von den Java-EE-Anbietern abstrahiert werden, denn das ist ja einer der großen Vorteile von Java EE seit jeher: Es abstrahiert die Java-EE-Laufzeit von der Anwendung. Im Idealfall wirkt sich die Nutzung von Kubernetes nur auf den ersteren Teil aus und ist für den späteren völlig transparent.

Um ein Beispiel zu geben: Wenn man microprofile-config oder die neue JSR-382 ConfigJSR verwendet, dann hat man zwei Teile:

  1. Das auf den User gerichtete API zur Lösung der Konfiguration für die jeweilige Anwendung.
  2. Das SPI für die Integration und Erweiterung der Konfigurationsinfrastruktur.

Wenn man Kubernetes nutzt, muss man nur ein JAR mit einer ConfigSource in seine Anwendung einbauen. Wahrscheinlich bietet der Container sogar eins out-of-the-Box. Diese ConfigSource wird dann mit kubeconfig integriert. Die eigene Jakarta-EE-Anwendung weiß nicht einmal davon! Es ist wirklich vollständig transparent und wegabstrahiert, da es ein Problem von Operations/Integrations ist.

Um es zusammenzufassen: Jakarta EE sollte solche Abstraktionen und Integrationen ermöglichen. Aber niemand sollte gezwungen werden, diese sofort von Haus aus bereitzustellen. Denn warum sollte ein IoT-Gerät beispielsweise eine kubeconfig-Integration benötigen?

JAXenter: Würdest du eine höhere Release-Kadenz (wie es nun bei Java der Fall ist) oder lieber größere und langsamere Releases bevorzugen?

Mark Struberg: Etwas, das genau in der Mitte liegt. Ist es zu lang, ist dies tödlich für die Verbreitung. Aber zu schnell ist auch nicht gut – Geschwindigkeit tötet ebenfalls. Nagelt mich nicht auf irgendwas fest, aber ich denke, zwei bis drei Jahre für ein Major Release mit neuen, großen Funktionen wären toll.

Ich habe jedoch einen zusätzlichen Wunsch: Jakarta EE sollte zwischenzeitlich „Bugfix Releases“ bringen. Releases, die API-kompatibel bleiben, aber zusätzliches Wording und TCK-Tests beinhalten, um die Portabilität zu verbessern und Blockaden zu beheben.

JAXenter: Wie planst du dich in den Entwicklungsprozess von Jakarta EE einzubringen? Gibt es irgendwelche Spezifikationen oder TCKs, die dich besonders interessieren?

Mark Struberg: Abgesehen davon, dass ich die Leitung der Spezifikation JSR-382 ConfigJSR (zusammen mit Emily Jiang von IBM) übernommen habe, bin ich auch ein Kernmitglied von MicroProfile. Zudem arbeite ich an einem halben Dutzend Jakarta-EE-Spezifikationen wie JSON-P, JSON-B, CDI, etc. als aktives EE-Mitglied. Das ist alles, was ich neben meinem Tagesjob an Zeitaufwand betreiben kann.

JAXenter: Wie sollte die Community mit den Veränderungen umgehen, die in letzter Zeit stattgefunden haben?

Mark Struberg: Mein Ratschlag ist seit 20 Jahren derselbe: Folgt nicht blind jedem Hype. Denkt stattdessen darüber nach, wie man die Vorteile für die eigenen Umgebungen nutzen kann. Versucht wirklich, die Kernideen und Designentscheidungen eines neuen Ansatzes zu verstehen, bevor ihr ihn anwendet. Denn jede Designentscheidung hat nicht nur positive Seiten, sondern hat auch immer einen Nachteil!

Jaxenter: Vielen Dank für das Interview!

Mark Struberg is a software architect at Research Industrial Systems Engineering (RISE). He has over 25 years of programming experience, has worked with Java since 1996 and is actively involved in open source projects in Java and Linux. Mark is an Apache Software Foundation Member and PMC on Apache OpenWebBeans, MyFaces, Delta-Spike and many other Apache projects. As a Java Expert Group Member, he is actively involved in Java EE specifications. He is also active in research and teaching at the Research Group for Industrial Software (INSO) of the TU Vienna.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: