Unsere Interview-Serie zu Jakarta EE: Markus Eisele, Java Champion und Head of Developer Advocacy bei Lightbend

Jakarta EE im Klartext: „Container und Orchestrierung sind zum neuen Standard geworden“

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 Markus Eisele, Java Champion und Head of Developer Advocacy bei Lightbend. Ab geht die Reise ins Jakarta-EE-Universum!

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 Markus Eisele, Java Champion und Head of Developer Advocacy bei Lightbend. Ab geht die Reise ins Jakarta-EE-Universum!

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

Markus Eisele: Es ist noch nichts entschieden. Ich persönlich würde es bevorzugen, wenn die beiden Projekte aufeinander abgestimmt werden, aber getrennt bleiben. Ich sehe die MicroProfile-Bemühungen gerne als Inkubator für neue Spezifikationen. Java EE hat damit zu kämpfen, die Balance zwischen dem Bereitstellen von Standards und der Innovation zu halten. Ich denke, es wäre ein Fehler, diesen Weg fortzusetzen. Mit einem agileren und weniger standardisierten MicroProfile-Projekt, das auf den Grundlagen von Jakarta EE aufbaut, hätten Erfahrungen aus der echten Welt eine höhere Chance, sich in späteren Standards widerzuspiegeln, als dies bei Java-EE-Spezifikationen der Fall war.

MicroProfile als Inkubator für Jakarta EE klingt für mich sehr verlockend.

Ich habe mir das Ganze noch nicht komplett durch den Kopf gehen lassen, aber würde MicroProfile das Upstream- oder Inkubationsprojekt von Jakarta EE werden, würde dies der Plattform wahrscheinlich den Spielraum geben, die TCKs weiter zu vervollständigen und zu stabilisieren und eine allgemeinere Laufzeitumgebung bereitzustellen. Auf dieser können dann die nächsten innovativen Feature-Sets im Rahmen des MicroProfile-Projektes entwickelt werden. Dadurch würde die gesamte Bandbreite des Projektes noch einmal vergrößert werden. Anstatt sich lediglich auf das Web-Profil zu stützen, hätte man so die Möglichkeit, mit den Full-Profile-Spezifikationen zu arbeiten. Alternativ könnte es auch andere Profile geben, die diesen Teil übernehmen. Die Situation ist ähnlich wie bei der Definition neuer Profile in Jakarta EE. Die Idee eines Inkubationsprojektes, mit dem die ersten Erfahrungen in der echten Welt gesammt werden, bevor es in Jakarta EE übernommen wird, klingt für mich sehr verlockend.

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?

Markus Eisele: Ich glaube, dass Mike Milinkovich bereits ein großartiges Interview dazu gegeben hat. Es ist eine natürliche Fortsetzung des heutigen Branchentrends, Cloud-Deployment-Modelle und schlanke Laufzeiten vollständig zu nutzen. Viele verschiedene Bemühungen und Überlegungen zu technischen Implementierungen stehen im Raum und sie alle haben das gemeinsame Ziel, Jakarta EE besser für kleinere Workloads in leichtgewichtigen Containern zu machen.

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

Markus Eisele: Eine einfache Frage mit einer nicht so einfachen Antwort. Ich glaube, es ist mittlerweile jedem klar, wie anders es ist, verteilte Cloud Workloads auszuführen, die möglicherweise Echtzeitdaten zuverlässig verarbeiten müssen.

Microservices-Architekturen sind ein großer Schritt in diese Richtung und ermöglichen viele Systeme, die noch vor wenigen Jahren nicht hätten implementiert werden können. Der Nachteil ist, dass für diese Art von Systemen viel mehr unterstützende Technologien vorhanden sein müssen. Die üblichen Verdächtigen sind Service Discovery, Cross-Service Security, verteiltes Logging sowie Tracing und so weiter. Bisher wurde noch nichts standardisiert und der Raum für Lösungen ist nahezu unbegrenzt, sodass man für jede Anforderung eine große Auswahl an möglichen Lösungen parat hat. Hinzu kommt die Tatsache, dass nicht alle Anwendungen die volle Ausfallsicherheit und Flexibilität benötigen, die mit hochverteilte Microservices-Architekturen einhergeht.

Es fehlen einfache Rezepte, die Anfängern helfen und Profis Flexibilität bieten.

Auch wenn man in unserer Branche viel gelernt hat und es einige sehr solide Frameworks und Lösungen gibt, die das Leben der Entwickler einfacher machen, müssen wir immer noch viel Klempnerarbeit leisten, um schließlich eine geeignete Umgebung zum Laufen zu bringen. Meistens geht dies weit über den Application Stack bis in die Infrastruktur hinein und erfordert Orchestrierung und Containerisierung. Was fehlt, sind die einfachen Rezepte, die genügend Hilfestellung für den Anfänger und Flexibilität für den erfahrenen Fachmann zur Verfügung stellen.

Für mich wäre es ein erster Schritt, die offensichtlichsten und allgemeinsten Bedürfnisse zu lösen, die näher an den bestehenden Spezifikationen liegen. Logging, Monitoring und Konfiguration kommen da zuerst in den Sinn. Aber auch Konzepte auf höherer Ebene rund um Service APIs oder Grundlagen, wie die Plattform-Modularisierung. Dies würde beispielsweise einen einfacheren Austausch von Persistenzanbietern ermöglichen. Ich bin fest davon überzeugt, dass es viel zu tun gibt, um Jakarta EE für die Zukunft fit zu machen.

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?

Markus Eisele: Das kommt, wie immer, darauf an: Die größten Fragen drehen sich um die Definition des Begriffs Microservices und die „bessere Unterstützung“ im Kontext von Jakarta EE. Angelehnt an die technischen APIs in Java EE (EJB, Servlet, etc.) könnte es sich bei der Antwort um ein übergeordnetes „Service API“ handeln, das verschiedene Wege zur Kommunikation nutzen und gleichermaßen auf Plattformdienste zugreifen kann. Nachdem ich die ersten Projekte mit Lagom als Microservices-Framework für die JVM gesehen habe, glaube ich, dass dieser Ansatz dabei behilflich sein kann, eine Microservices-basierte Architektur zu entwerfen und umzusetzen. Eine „bessere Unterstützung“ kann sich auch auf alle Aspekte der vorherigen Frage beziehen. Sollte sich jemand die Hoffnung gemacht haben, dass es hierbei nur darum ginge, eine Handvoll Spezifikationen hinzuzufügen, kann ich mit Sicherheit sagen, dass dies nicht der Fall ist.

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?

Markus Eisele: Container und Orchestrierung sind zum neuen Standard für den Operations-Bereich in unserer Branche geworden. Was früher tar-Dateien und bash-Skripte waren, funktioniert heute anders. Und ehrlich gesagt, verdient man mit Software nur dann Geld, wenn sie in der Produktion eingesetzt wird. Entwicklungsleistungen in eine Produktionsumgebung umzulagern, war schon immer ein wesentlicher Bestandteil der Spezifikation. Wir müssen überlegen, wie und welche Komponenten für den Einsatz in heutigen Produktionsumgebungen zusammengepackt und konfigriert werden müssen – fernab von EAR- oder WAR-Dateien.

Ich weiß nicht, ob ich es zur Priorität machen würde, eine Art technischer Integration vorläufig zu implementieren. Es gibt vernünftige Lösungen, die das Deployment auf Kubernetes unterstützen. Aber während die Realisierbarkeit davon abhängt, wo die Lösung eingesetzt wird (in der lokalen Entwicklung oder dem sog. Production Packaging), gibt es auch hier Vor- und Nachteile. Die Integration von Kubernetes steht sicher auf meiner persönlichen Wunschliste für Jakarta EE, könnte aber kurzfristig mit einigen Empfehlungen und Richtlinien angesprochen werden.

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?

Markus Eisele: Ich würde stabile und relevante Releases mit einem vernünftigen Supportangebot bevorzugen. Das initiale Gedankenspiel zu Projekten in einer Art Inkubator und Jakarta EE als finale Spezifikation trifft meine Vision wohl am ehesten. Betrachten wir das einmal genauer.

Ich bevorzuge größere und besser getestete Feature Releases gegenüber schnelleren Sprints.

Nehmen wir einmal an, wir haben uns auf eine erste Version einer neuen Bibliothek geeinigt. Diese wurde in unserem Beispiel im MicroProfile-Projekt entwickelt, getestet und hat über einen bestimmten Zeitraum (etwa 6-12 Monate) erhalten, sodass sie in Jakarta EE aufgenommen werden könnte. Inkubation, Tests und die Übernahme durch die Anbieter könnten weitere 6-12 Monate dauern. Das würde zu einem Release-Zyklus von 12 bis 24 Monaten für Jakarta EE führen. Ich glaube übrigens, dass es tatsächlich sinnvoller wäre, die Vendor-Implementierung zu einem Teil des Inkubationsprozesses zu machen und so Feedback und wichtige Verbesserungen möglichst früh zu sammeln. Auf diese Weise wäre es so möglich, mit MicroProfile Innovationen voranzutreiben und diese dann langsam und reibungslos in Produkte einfließen zu lassen, sobald sie standardisiert sind.

Um die Frage zu beantworten: Ich bevorzuge größere und besser getestete Feature Releases gegenüber schnelleren Sprints. Aber ich würde die Tür für Early Adopters gerne offen halten.

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

Markus Eisele: Mit meinem aktuellen Fokus und der ganzen Geschichte, die mich mit Java EE verbindet, wäre es mir eine Freude, der Community wieder stärker zu helfen. Aus technologischer Sicht interessiere ich mich eher für die neuesten MicroProfile-Entwicklungen. In erster Linie die Reactive-Spezifikationen von MicroProfile. Ob und wie ich zukünftig Zeit finden werde, muss ich sehen.

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

Markus Eisele: Sie sollten sich dem Ganzen anpassen. Die aktuelle Entwicklung ist das beste, was Java EE passieren konnte und wurde wohl nur durch extreme Anstrengungen im Hintergrund möglich. Die Eclipse Foundation ist ein großartiger Ort, um die Zukunft von Java EE und ein vertrauenswürdiger Partner für unser Ökosystem.

Die aktuelle Entwicklung ist das beste, was Java EE passieren konnte.

Nach langjähriger Arbeit mit und im Umfeld von Java EE bzw. der Spezifikationen freue ich mich persönlich auf das offene Governance-Modell und ein breiteres Engagement der Community. Java EE ist für sich eine Erfolgsgeschichte und ein Synonym für das Rückgrat unzähliger Anwendungen, die täglich branchenübergreifende Requests bedienen. Auch wenn der Raum für Lösungen sich in der Tech-Branche massiv erweitert hat und es immer mehr Ansätze, Sprachen und Frameworks gibt, glaube ich, dass Standardisierungsbemühungen nicht nur zum Erfolg von Java EE beigetragen haben. Sie werden in meinen Augen auch ein Symbol für die Qualität in Produktion innerhalb eines sehr instabilen Ökosystems werden, das ständig neue Hypes hervorbringt.

Dies ist nun die Gelegenheit, bewährte und getestete Elemente auf die nächste Stufe zu heben, indem sie erfahrenen Java-EE-Experten zugänglich gemacht werden. Diese können dann ihre Erfahrung und ihr Wissen, dass sie sich angeeignet haben, weiterhin nutzen, während sie die Plattform weiterentwickeln. All dies kann aber nur dann passieren, wenn die Community aktiv bleibt, die richtigen Fragen stellt und innerhalb der einzelnen Organe von Jakarta EE arbeitet, um diesen Standard für deren Bedürfnisse relevant zu halten.

JAXenter: Vielen Dank für das Interview!

Markus Eisele is the Head of Developer Advocacy at Lightbend and a Java Champion.
 
 
 
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: