Unsere Interview-Serie zu Jakarta EE: Steve Millidge, Gründer von Payara und Mitglied im Jakarta EE PMC

Jakarta EE im Klartext: „Die Integration von Kubernetes ist ein wesentlicher Bestandteil der Cloud-native-Agenda“

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 Steve Millidge, Gründer und Geschäftsführer von Payara und Mitglied im Jakarta EE PMC. 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 Steve Millidge, Gründer und Geschäftsführer von Payara und Mitglied im Jakarta EE PMC. Ab geht die Reise ins Jakarta-EE-Universum!

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

Steve Millidge: Langfristig wäre es eine gute Idee, wenn einige Eclipse MicroProfile APIs Teil von Jakarte EE werden. Bei Jakarta EE handelt es sich um einen Standardisierungsprozess und um eine Marke, wohingegen das MicroProfile-Projekt dazu genutzt werden kann, um Innovationen voranzubringen und Experimente mit den neuen APIs durchzuführen. Sobald sich zeigt, dass diese APIs in realen Systemen nützlich sind, können sie ein Teil von Jakarta EE werden.

Kurz gesagt: Nein, sie sollten nicht zusammengelegt werden.

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?

Es wird die Aufgabe der Jakarta EE Community sein, neue Standard-APIs für aktuelle Cloud Services zu entwickeln.

Steve Millidge: Ich denke, dass man das Ziel „Cloud-native“ am ehesten erreicht, wenn man Java EE an die Programmiermodelle und Architekturen der Cloud anpasst. Damit ist gemeint, dass der Fokus auf der Anpassung an Cloud-native Trends, Containerisierung, der Orchestrierung von Containern, unveränderlichen Laufzeiten, Elastizität, durch Software definierter Infrastruktur und Serverless liegen sollte.

Bei Payara setzen wir für unsere Laufzeit auf Payara Micro, um von traditionellen Anwendungsserver-Deployments auf kleine, leichtgewichtige Laufzeiten umzuziehen.

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

Steve Millidge: Bei Jakarta EE – wie schon zuvor bei Java EE – ging es stets darum, APIs für Enterprise-Infrastrukturen zu entwickeln und dahingehend zu standardisieren. Diese APIs dienen zur Erstellung von verteilten Enterprise-Anwendungen wie z.B. Datenbanken, Benachrichtigungssystemen, TP Monitors, REST Services usw.

Demzufolge ist Jakarta EE bereits jetzt für Cloud Deployments geeignet. Allerdings bieten die aktuellen Cloud-Plattformen neue Enterprise Services an, die tendenziell über proprietäre APIs verfügen. Es wird die Aufgabe der Jakarta EE Community sein, neue Standard-APIs für diese neuen Cloud Services zu entwickeln. Es braucht also neue APIs für die Unterstützung der Orchestrierung von Containern und Service Discovery. Zudem brauchen wir Standard-APIs für die Konfiguration von Datenspeichern, Key Vaults und die Sicherheitsinfrastruktur müssen ebenfalls erstellt werden.

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?

Steve Millidge: MicroProfile hat exzellente Fortschritte beim Experimentieren von Microservice APIs gemacht, die auf Jakarte EE APIs aufsetzen. Diese APIs werden vorangetrieben und deren Einsatz aktiv getestet. Diejenigen, die sich als erfolgreich herausstellen, sollten den Spezifikationsprozess von Jakarta EE durchlaufen und zu vollständigen Jakarta EE APIs weiterentwickelt werden.

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?

Die Integration von Kubernetes ist meiner Meinung nach ein wesentlicher Bestandteil der Cloud-native-Agenda.

Steve Millidge: Die Integration von Kubernetes ist meiner Meinung nach ein wesentlicher Bestandteil der Cloud-native-Agenda. Es ist offensichtlich, dass sich für Cloud-Anbieter Kubernetes als bevorzugte Lösung für die Orchestrierung von Containern durchsetzt. Jakarta EE sollte aber nicht die Verwendung des nativen Kubernetes APIs vorschreiben. Stattdessen sollte man Abstraktionen des Standard APIs für die üblichen Services zur Verfügung stellen, die von Kubernetes bereitgestellt werden, also etwa für Service Discovery, die externe Konfiguration, Secrets und vielleicht auch APIs für das Skalieren von Pods. Es ist die Aufgabe von Payara, dafür zu sorgen, dass unsere Laufzeit in einer Kubernetes-Umgebung gut funktioniert. Für uns hat das definitiv Priorität.

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?

Steve Millidge: Es gibt ein paar Dinge, über die man nachdenken muss. Ich wünsche mir eine schnellere Release-Kadenz für die Schirmspezifikation, also etwa Jakarta EE 8 und Jakarta EE 9, wünschen. Vielleicht alle 12 bis 18 Monate. Allerdings denke ich auch, dass dies vollständig von der Release-Kadenz der Java SE entkoppelt werden sollte.

Das neu zu bestimmende Release-Train-Modell sollte zudem berücksichtigen, dass alle Teilspezifikationen, aus denen sich Jakarta EE dann zusammensetzt, eine eigene gesunde Release-Kadenz in den jeweiligen Projekten definieren können. Zu einem festen Zeitpunkt würden so die aktuellen Versionen aller Spezifikationen „eingesammelt“ und als Ganzes veröffentlicht werden.

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

Steve Millidge: Das Payara-Team ist stark in den gesamten Jakarta-EE-Prozess eingebunden. Ich persönlich vertrete Payara in den meisten Committees und bin Mitglied des Board of Directors der Eclipse Foundation. Ich bin auch Co-Projektleiter für GlassFish und eine Reihe anderer Spezifikationen wie z.B. die Concurrency-Spezifikation. Mir wird vermutlich nicht langweilig werden.

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

Wenn die Nutzer von Jakarta EE sich nicht einbringen, um die von ihnen verwendeten Teile voranzutreiben und zu entwickeln, kann es sein, dass diese Teile von Jakarta EE sterben.

Steve Millidge: Man sollte sich noch einmal vor Augen führen, dass nach dem Umzug zur Eclipse Foundation Jakarta EE komplett bei einer Open-Source-Organisation sein wird. Das bedeutet, dass alles offen sein und die Weiterentwicklung vollständig in den Händen der Community liegen wird. Die großen Softwareanbieter werden keine Kontrolle über die EE4J-Projekte haben, die den Code liefern. Jeder kann durch Code, GitHub Issues, das Schreiben von Spezifikationsdokumentationen, das Erstellen von Build-Pipelines etc. einen Beitrag leisten.

Doch mit dieser Freiheit geht auch eine Verantwortung einher. Wenn die Nutzer von Jakarta EE sich nicht einbringen, um die von ihnen verwendeten Teile voranzutreiben und zu entwickeln, kann es sein, dass diese Teile von Jakarta EE sterben.

JAXenter: Was ist als nächstes für Eclipse GlassFish geplant?

Steve Millidge: Zunächst muss der Code von Oracle GlassFish zur Eclipse Foundation umgezogen werden. Dieser erste Schritt ist noch nicht vollständig vollzogen. Danach ist der Plan, Eclipse GlassFish als konform zu Java EE 8 zu veröffentlichen. Um das zu erreichen, müssen alle Projekte, aus denen GlassFish besteht, bei der Eclipse Foundation und mit Eclipse Foundation JARs erstellt werden.

Schließlich, sobald wir eine Jakarta-EE-8-Spezifikation haben und alle TCKs auf Eclipse übertragen und dort gebaut wurden, soll Eclipse GlassFish mit Jakarta EE 8 kompatibel werden. Damit soll die Kontinuität von Java EE 8 bis Jakarta EE 8 gewährleistet werden. Ist das geschafft, liegt es an der Community, die Entwicklung von Eclipse GlassFish wie bei jedem anderen Open-Source-Projekt fortzusetzen.

JAXenter: Könntest du bitte beschreiben, worum es Eclipse GlassFish geht?

Steve Millidge: Grundsätzlich wird der Code von Oracles quelloffenem GlassFish-Server als Eclipse GlassFish zur Foundation umgezogen. Sobald dieser Schritt abgeschlossen ist, wird Eclipse GlassFish eine Implementierung von Jakarta EE werden.

JAXenter: Vielen Dank für das Interview!
 

Steve Millidge is the Founder and Director of Payara and C2B2 Consulting. Having used Java extensively since pre1.0, Steve has over 15 years’ experience as a field based Professional Service Consultant along with extensive knowledge of Java middleware. Before running his own business, Steve worked for Oracle as a Principal Consultant in Oracle’s Technology Architecture Practice, specialising in Business Process Integration and scalable n-tier component architectures. Steve now uses this knowledge to build and grow Payara and C2B2 Consulting and is responsible for the strategic direction of both companies.

Follow him on Twitter LinkedIn, and find him on GitHub.

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: