Development Java

... es lebe Spring (Boot)!

Angesichts des deutlichen Trends in Richtung Containerisierung und Cloud-native stellt sich die Frage, ob Java EE noch die richtige Entscheidung für eine zukunftsfähige IT-Architektur ist. Ein Vergleich mit Spring Boot anhand der Zwölf Faktoren von Adam Wiggins liefert ein klares Nein als Antwort. Das bedeutet nicht, dass jede Java EE-Anwendung von heute auf morgen abgeschaltet werden muss, aber zumindest, dass Java EE für neue Anwendungen nicht mehr die primäre Technologie sein sollte.

Tobias Voss

Author

31.07.2020
Lesezeit: 10 Minuten
80 Views

Der Java EE-Standard liegt auf dem Sterbebett und das Spring-Ökosystem hat die Vorreiterrolle als Quasi-Standard im Enterprise-Java-Umfeld übernommen. Die Übergabe des Java EE-Standards von Oracle an die Eclipse Foundation und der neue Name Jakarta EE sind eher der letzte Sargnagel als ein Neubeginn [Röw19].

Warum ist das so? Neben der höheren Geschwindigkeit bei Neuerungen, die das Spring-Ökosystem gegenüber dem trägen Standardisierungsprozess von Java EE auszeichnet, scheint sich Java nur aus der Spring-Community heraus für die Anforderungen der Cloud wappnen zu können. In einer Microservice-Umgebung ist kein Platz für schwergewichtige Applikationsserver, sondern Container-Technologien wie Docker und Kubernetes setzen die

Maßstäbe. Darüber hinaus bieten diese im Gegensatz zu Applikationsservern auch eine Laufzeitumgebung für Anwendungen, die nicht in Java geschrieben sind, sondern auf Node.js oder Python setzen.

In diesem Artikel werde ich ausgehend von der These, dass eine Cloud-fähige Webanwendung implementiert werden soll, mit den Zwölf Faktoren (s. Kasten „Zwölf Faktoren für Webanwendungen”) bewerten, ob Java EE eine geeignete Lösung ist, und als Vergleich Spring (Boot) heranziehen. Nicht alle Faktoren sind anwendbar auf den Java EE-Standard. Die Versionsverwaltung (Codebase), die Trennung der Build- von der Run-Phase, die Behandlung von Logs als Ereignisstrom und die Ausführung von Admin-/Management-Aufgaben sind unabhängig von Java EE und werden daher nicht betrachtet. Bleiben acht.

Abhängigkeiten explizit deklarieren

„Eine Zwölf-Faktor-App verlässt sich nie auf die Existenz von systemweiten Paketen” ist ein Prinzip, das dem Applikationsserver-Ansatz bewusst widerspricht. In Java EE verlässt man sich darauf, dass für die benutzten APIs eine Implementierung durch den Applikationsserver bereitgestellt wird. In Maven gibt es dafür sogar den Scope provided für Abhängigkeiten, die vom Servlet-Container bereitgestellt werden.

Spring Boot in Reinkultur hingegen erfüllt dieses Prinzip und erzeugt in sich abgeschlossene Anwendungen mit allen Abhängigkeiten, in denen der Servlet-Container bewusst integriert ist. Spring Boot-Anwendungen werden dann nicht als WAR-Datei auf einem Applikationsserver ausgerollt, sondern direkt als JAR-Datei gestartet. Das hat einerseits Vorteile für die einfachere Entwicklung, da keine Infrastruktur auf der Entwicklungsmaschine benötigt wird. Andererseits werden auch der Betrieb und die Skalierung vereinfacht, da auch Test- und Produktivsysteme ohne weitere Abhängigkeiten auskommen. Langfristig erhöht dieses Vorgehen auch die Wartbarkeit, da Migrationsprojekte von einem Applikationsserver zum anderen beim Hersteller- oder Versionswechsel der Vergangenheit angehören. Falls die Anwendung einen neuen Servlet-Container braucht, kann man diesen einfach in den neuen Deployments austauschen und ältere Deployments nach und nach ersetzen.

Konfiguration in Umgebungsvariablen speichern

Die betriebliche Konfiguration, die insbesondere für das Deployment wichtig ist, darf kein Teil der Codebasis im Repository sein. Das gilt für Ressourcendefinitionen (z. B. Datenbank-Verbindungen), Credentials für den Zugriff auf andere Anwendungen oder externe Dienste und auch für andere Parameter, die abhängig vom Deployment sind, wie Hostnamen. Die Zwölf-Faktor-Prinzipien sehen vor, dass die Deployment-Konfiguration vollständig über Umgebungsvariablen gesteuert wird. Die Ausnahme hiervon ist die Anwendungskonfiguration, zum Beispiel die Spring- oder JPA-Konfigurationen für das Datenbank-Mapping.

Im Java-Ökosystem haben sich für die Anwendungskonfiguration Annotationen direkt an den jeweiligen POJO-Klassen etabliert, die von diesem Prinzip auch nicht berührt werden. Betriebliche Konfigurationsparameter sind häufig in Properties-Dateien abgelegt, die dann im Build/Deployment als Parameter herangezogen werden. Grundsätzlich sind dabei Umgebungsvariablen integrierbar, sodass dieses Prinzip sowohl mit Java EE als auch im Spring-Umfeld umsetzbar ist. Allerdings existieren sicherlich viele Java EE-Anwendungen, die dieses Prinzip verletzen und deswegen nicht ohne Weiteres Cloud-fähig sind. Bei Spring Boot hingegen kann man mit der Property Source jeden Key aus einer Properties-Datei als Umgebungsvariable übergeben, die bevorzugt verwendet wird.

Unterstützungsdienste als angehängte Ressourcen behandeln

Alle Dienste, die eine Anwendung zur Erfüllung der Funktionalität benötigt, seien es Datenbanken, Messaging-Systeme sowie von Dritten oder in der Cloud bereitgestellte Dienste wie das Twitter- oder Google-Maps-API, sollen gemäß diesem Prinzip gleichbehandelt werden. Alle Dienste werden über eine URL als Ressource aufgerufen und die Parameter für den Zugriff in der Deployment-Konfiguration verwaltet. Damit wird erreicht, dass die Anwendung nicht abhängig von lokalen Diensten ist.

Für die Anwendung ist es transparent, ob der Dienst im eigenen Rechenzentrum, einer privaten oder hybriden Cloud oder im offenen Internet bereitgestellt wird, da der Zugriff immer über eine URL erfolgt. Damit wird eine lose Kopplung zwischen der Anwendung und den benötigten Diensten erreicht, die den Austausch von Ressourcen im Deployment ohne Code-Änderungen ermöglicht. Diese Eigenschaft lässt sich sowohl mit Java EE als auch mit Spring erfüllen.

Anwendungen als zustandslose Prozesse ausführen

Zwölf-Faktor-Anwendungen sollen zustandslos sein und dem Shared-Nothing-Ansatz [Wiki] folgen. Daraus leitet sich ab, dass jede Anfrage an einen beliebigen Systemprozess beziehungsweise eine beliebige Instanz geroutet werden kann und alle Daten zur Erfüllung der Anfrage in Unterstützungsdiensten gespeichert sind. Das heißt, es gibt keine Session-Daten im Arbeitsspeicher des Anwendungsprozesses und auch keine Sticky Sessions, bei denen alle Anfragen desselben Benutzers zur selben Instanz geroutet werden. Statt dem Arbeitsspeicher können Caching-Lösungen wie Memcached oder Redis als Unterstützungsdienste verwendet werden.

Das Servlet-API als Teil von Java EE setzt auf eine zustandsbehaftete HttpSession, die diesem Prinzip widerspricht. Im Spring-Ökosystem gibt es mehrere Möglichkeiten zur Realisierung von Webanwendungen wie Spring MVC oder Spring Web Flow, die ebenfalls teilweise auf eine zustandsbehaftete Session setzen. Eine häufig gewählte Architektur setzt stattdessen auf Spring-basierte, zustandslose REST-Services im Backend und eine Single-Page App mit modernen JavaScript-Frameworks im Frontend. In diesem Fall hängt es also vom konkreten Einsatzszenario ab, aber die Erfüllung des Prinzips ist mit einer Spring-basierten Architektur möglich.

Zwölf Faktoren für Webanwendungen

Dienste durch das Binden eines Ports exportieren

Auch wenn dieses Prinzip etwas sperrig formuliert ist, bedeutet es letztlich, dass die Anwendung vollständig eigenständig ist und keinen externen Web- oder Applikationsserver zur Laufzeit benötigt – also der exakte Gegenentwurf zum Java EE-Ansatz. Mit Spring Boot wird dieses Prinzip dadurch erreicht, dass ein eingebetteter Servlet-Container wie Jetty oder Tomcat als explizite Abhängigkeit mit ausgeliefert wird und damit eine unabhängige Laufzeitumgebung vollständig bereitsteht.

Durch unabhängige Prozesse skalieren

Zwölf-Faktor-Anwendungen setzen auf eine horizontale Skalierung durch viele parallele Prozesse oder Instanzen, die isoliert voneinander laufen. Diese Form der elastischen Skalierung ist eine zentrale Eigenschaft der Cloud. Die Nebenläufigkeit und Parallelisierung von Anwendungen wird damit wesentlich vereinfacht und eine schnelle Reaktion auf Lastspitzen oder unerwarteten Erfolg der Webanwendung ist möglich. Mit Spring Boot kann diese Art der Skalierung umgesetzt werden, sofern wirklich zustandslose Prozesse damit implementiert werden. Java EE hingegen verfolgt den Ansatz einer vertikalen Skalierung, in dem der Applikationsserver und die darin laufende JVM mit mehr Systemressourcen ausgestattet werden oder leistungsfähigere Hardware beschafft wird.

Robuster mit Wegwerfprozessen

Dieser Faktor verlangt, dass Prozesse jederzeit gestartet oder gestoppt werden können, ohne Auswirkungen auf die Benutzer der Anwendung zu verursachen. Dies erhöht die Robustheit des Gesamtsystems durch bessere Skalierbarkeit und schnellere Deployments. Eine Spring Boot-Anwendung kann als Wegwerfprozess ausgeführt werden. Allerdings handelt es sich dabei um eher schwergewichtige Prozesse durch die JVM und den

eingebetteten Servlet-Container mit entsprechend langen Startup-Zeiten. Um die angestrebte minimale Anlaufzeit zu erreichen, gibt es mittlerweile mehrere Technologien wie Quarkus, Micronaut und GraalVM.

Im Java EE-Umfeld sind der Applikationsserver und die darin deployten Webanwendungen auf einen Endlosbetrieb ausgelegt und es ist nur schwer vorstellbar, daraus Wegwerfprozesse zu designen.

Entwicklung und Produktion ähnlich halten

Zur Unterstützung von Continuous Deployment und um DevOps zu ermöglichen, sollten Entwicklungs- und Produktionsumgebung so ähnlich wie möglich sein – idealerweise komplett identisch bis auf andere Ressourcen-URLs und eine größere Anzahl von Prozessen oder Deployments in Produktion. Damit gehören auch merkwürdige Effekte und Diskussionen wie das berühmt-berüchtigte „auf meinem Entwicklungsrechner läuft es – in Produktion aber nicht” der Vergangenheit an.

Spring Boot ist ein idealer Kandidat zur Umsetzung dieses Prinzips, wenn man die Spring Boot-Anwendung als Docker-Container verpackt und dort die JVM mitliefert – ansonsten besteht noch eine Abhängigkeit zur lokal installierten JVM, die zwischen Entwicklung und Produktion abweichen kann. Für Java EE lässt es sich hingegen nur schwer umsetzen, da der schwergewichtige Applikationsserver allein aus Lizenz-, Performanz- und Komplexitätsgründen nicht auf jedem Entwicklerrechner laufen kann. Für die üblicherweise genutzten Ressourcen wie relationale Datenbanken oder Message-Queue-Systeme gilt das genauso. Der Betrieb dieser Systeme hat in der Vergangenheit häufig eine Wissenschaft für sich dargestellt und auf die Expertise hat sich der IT-Betrieb spezialisiert, sodass Entwickler auf ihren lokalen Systemen auf vereinfachte Technologien wie H2 als Datenbank ausgewichen sind.

Tabelle 1: Bewertung der diskutierten acht Faktoren

Fazit: Java EE ist Legacy

Nach der Betrachtung der einzelnen Faktoren fasst Tabelle 1 nochmal die vereinfachte Einschätzung der Erfüllung der Faktoren durch das Spring-Ökosystem mit Spring Boot und dem Java EE-Standard zusammen.

Natürlich bestehen nicht für jede Unternehmensanwendung alle Anforderungen, die sich aus den Zwölf Faktoren ableiten. Gleichwohl gibt es durch die DevOps-Bewegung und den vermehrten Einsatz von Container-/Cloud-Technologien einen deutlichen Trend in diese Richtung. Es lohnt sich also zu hinterfragen, ob Java EE noch die richtige Entscheidung für eine zukunftsfähige IT-Architektur ist. Meine Einschätzung spiegelt sich in der Tabelle in einem deutlichen NEIN wider. Damit muss man konsequenterweise Java EE als Legacy-Technologie betrachten, die mittelfristig abgelöst werden sollte.