Unsere Interview-Serie zu Jakarta EE: Rudy De Busscher

Jakarta EE im Klartext: „Wir sollten uns nicht zu sehr auf Microservices konzentrieren“

Dominik Mohilo, Gabriela Motroc

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 Rudy De Busscher, Senior Java Entwickler, Java-EE-Experte & Mitglied der Java EE Guardians. 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 Rudy De Busscher, Senior Java Entwickler, Java-EE-Experte & Mitglieder Java EE Guardians. Ab geht die Reise ins Jakarta-EE-Universum!

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

Rudy De Busscher: Auf lange Sicht, ja. Einige Konzepte rund um Konfiguration, Metriken, Resilienz und Sicherheit sind von MicroProfile standardisiert worden, um nur ein paar zu nennen, die in allen modernen Applikationen nützlich sind. Das betrifft aber nicht nur Anwendungen, die auf Microservices aufbauen, sondern auch eher traditionelle Anwendungen.

Für ein Zusammenführen von MicroProfile und Jakarta EE ist es noch zu früh.

Ich glaube allerdings, dass es für einen Zusammenschluss der Projekte noch zu früh ist. Jakarta EE ist noch nicht vollständig ausgereift und es wird hart daran gearbeitet, die gesamte Government- und Verwaltungsstruktur einzurichten – vom Umzug der gigantischen Code-Basis von Java EE zur Eclipse Foundation einmal abgesehen. Die Projekte jetzt zusammenzuführen, würde wahrscheinlich bedeuten, dass sich die Innovation im Bereich von MicroProfile verringern würde und das ist unerwünscht. Aber sobald Jakarte EE bereit ist, würde ich es als ganz natürlich empfinden, dass man sie zusammenlegt und sie zu einem gemeinsamen Profil werden, etwa auf zertifizierten Jakarta-EE-Servern.

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?

Rudy De Busscher: Wenn man mich fragt, sind ein paar dieser Dinge bereits realisiert worden. Zum Beispiel eine verbesserte Entwicklungsgeschwindigkeit: Beim Einsatz von Jakarta EE können sich Entwickler auf die Implementierung der Businesslogik konzentrieren und die Infrastruktur wird von dieser getrennt. Die Skalierung kann auch schon optimiert werden, wenn man die Metrics- und Health-Konzepte von MicroProfile nutzt. Das Instanzenmanagement, wie das Starten, Stoppen oder Hoch- oder Herunterskalieren, kann dann anhand der tatsächlichen Metriken abgestimmt werden.

Ein weiterer wichtiger Faktor ist die Provisionierung der Server. Bereits heute kann man in diesem Bereich gute Ergebnisse erzielen, denn die Installation der meisten Server bedeutet in vielen Fällen lediglich, eine einzelne JAR-Datei auszuführen. Die Dinge können optimiert werden, wenn Jakarta EE die Hollow-Jar-Technik standardisiert, bei der eine optimierte Version des Servers die Anwendung (gepackt als WAR-Datei) ausführt. Dann können die eigenen Dockerfiles etwa effizient geschichtet werden, das Ausführen des Servers bleibt trotzdem so leicht wie das Ausführen eines einfachen Java-Programms.

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?

Meiner Meinung nach sollten wir uns nicht zu sehr auf Microservices konzentrieren.

Rudy De Busscher: Wie bereits erwähnt, können im Moment die Spezifikationen von MicroProfile die noch leeren Stellen von Jakarta EE ausfüllen, wenn man schon heute Microservices einsetzen will. Meiner Meinung nach sollten wir uns aber nicht zu sehr auf Microservices konzentrieren. Sicher, es gibt Anwendungsfälle, für die diese Art der Architektur am besten geeignet ist, aber sie ist nicht das Allheilmittel, für das sie viele Menschen halten. Selbst der Großteil führender Analytiker hält es für verfrüht, flächendeckend auf Microservices zu setzen. Sie halten es sogar generell für unwahrscheinlich, dass dies je passieren wird. In den meisten Projekten, mit denen ich mich befasst habe, ging die Umstellung auf eine Microservices-Architektur jedenfalls schief, da aus den falschen Gründen umstrukturiert wurde.

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?

Rudy De Busscher: Nein. Kubernetes ist nur eines von den Produkten, die man für die Verwaltung von containerisierten Services einsetzt. Wenn dieser Bereich in ein paar Jahren stärker standardisiert und jeder davon überzeugt ist, wie man mit diesen containerisierten Services umgehen sollte, dann können wir über eine tiefergehende Integration nachdenken. Allerdings sollten diese Management-Tools klar von den Jakarta-EE-Servern getrennt sein. Es kann nicht das Ziel sein, eine sehr enge Integration umzusetzen, wenn das dann standardisierte Kubernetes nur eine von vielen Möglichkeiten ist, wie man einen Server betreiben kann.

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?

Rudy De Busscher: Ich würde langsamere Releases bevorzugen, etwa einmal im Jahr, die dann dafür eine große Anzahl neuer Features enthalten. Jakarta EE ist eine Spezifikationen und kein Produkt, bei dem schnellere Releases Probleme vorheriger Versionen beheben sollen.

Ich würde langsamere Releases bevorzugen, etwa einmal im Jahr, die dann dafür eine große Anzahl neuer Features enthalten.

Eine neue Version von Jakarte EE zu veröffentlichen, bei der die Hälfte der Spezifikationen nur eine zusätzliche Funktion bekommt und alles andere unverändert bleibt, ergibt einfach keinen Sinn. Auch das schnelle Wechseln der Hauptversionsnummer ohne wirklich neue und große Features, wird keinen Benutzer dazu ermutigen, auf eine neue Version umzusteigen.

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

Rudy De Busscher: In den letzten Jahren habe ich mich die meiste Zeit auf JavaServer Faces und das Security-Projekt konzentriert. Da ich mich mit diesen Spezifikationen gut auskenne und miterlebt habe, was alles verbessert werden kann oder fehlt, denke ich, dass dies die Bereiche sind, in denen ich am meisten helfen kann. Im Moment bin ich bereits Committer für die Security-Spezifikation und die Soteria-Implementierung bei Jakarta EE. Möglicherweise kommt da später noch eine weitere Spezifikation hinzu, vielleicht im Bereich JAX-RS Client. Doch ich sollte nicht zu viel auf einmal angehen, da die Mitarbeit sehr viel Zeit beansprucht. Man kann eben nicht an allen Schrauben gleichzeitig drehen.

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

Rudy De Busscher: Die Community hat nun die Kontrolle über den Code von Java EE und die entsprechenden Prozesse erhalten. Jetzt liegt es an uns, das Projekt voranzutreiben und zu verbessern. Damit wir auch in Zukunft die bewährten Rezepte einsetzen können, die wir brauchen, damit wir Anwendungen auch auf lange Sicht hin unterstützen können.

Ich lade auch all diejenigen, die Java EE aus welchen Gründen auch immer kritisiert haben, herzlich ein, um an Jakarta EE mitzuarbeiten. Letzten Endes wird jeder davon profitieren, wenn wir gute Tools haben, um Anwendungen zu schreiben, die wir in diesem digitalen Zeitalter benötigen.

JAXenter: Vielen Dank für das Interview!

Rudy De Busscher ist Senior-Java-Entwickler und Java-EE-Experte sowie Mitglied bei den Java EE Guardians member und der Erschaffer von Atbash.

Auf Twitter ist er unter dem Handle @rdebusscher zu finden.
 

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: