Interview mit Anatole Tresch zur JAX 2017

Microservices, Container, Serverless – brauchen wir da überhaupt noch Java EE?

Hartmut Schlosser

Anatole Tresch

Microservices, Container, Serverless – die Entwicklung in der digitalen Welt geht immer rasanter vonstatten. Die Frage, ob wir klassische Technologien wie Java EE in „Cloud-native“-Zeiten überhaupt noch brauchen, wird immer häufiger gestellt. Im Interview spricht JAX-Speaker Anatole Tresch über den Kontext, in dem Java und Java EE ursprünglich entstanden sind, und ob dieser Kontext so heute noch gegeben ist.

JAXenter: In deinem JAX-Vortrag stellst du die Frage, ob wir angesichts der Entwicklung der letzten Jahre Java EE eigentlich noch brauchen. Um das herauszufinden, gehst du zurück an die Ursprünge von Java EE. In welchem Kontext ist Java EE überhaupt entstanden?

JavaScript-Programmierung war damals wirklich fast mit Folter zu vergleichen.

Anatole Tresch: ​Eigentlich muss man sich meiner Meinung nach die Zeit vergegenwärtigen, in der es noch kein Java gab, um auch Java EE in seiner Entstehung zu verstehen. Damals​ in den 90er Jahren gab es MS-DOS/Windows, ein monolithisches in C++ geschriebenes MacOS, Solaris und andere UNIX-Systeme sowie erste experimentelle Systeme in der Wissenschaft, die sich mit hochparallelen Algorithmen und Verteilung befassten. Grundsätzlich waren alle Platformen mehr oder weniger komplett inkompatibel. Es gab zwar Ethernet, aber IBM Tokenring, TCP/IP und Appletalk sind komplett unterschiedliche Protokolle.

Auch plattformunabhängige Programmierung steckte damals noch in den Kinderschuhen und bestehende Ansätze wie z.B. ET++ waren sehr aufwendig und instabil. C/C++ war typischerweise die Programmiersprache der Wahl und so endete auch das Programmieren eines „Hallo Welt“ zwischen zwei Maschinen schnell in einem mehrseitigen C++-Programm und entsprechenden Segmentation Faults. Das hier einiges an Potential verborgen liegt, haben James Gosling und Kollegen rasch gesehen und bereits 1992 mit Oak (Object Application Kernel) den Grundstein für Java gelegt. Allerdings waren sie ihrer Zeit weit voraus und zielten damals auf Kleingeräte wie Kaffeemaschinen und Fernseher ab. Da sie bei den damaligen Herstellern nicht erfolgreich waren, mussten sie sich ein anderes Umfeld suchen und haben sich schließlich das damals aufkommende Internet ausgesucht. Nach einem ersten Versuch die Plattform mit dem damals unter Solaris verwendeten Mosaic-Browser zu integrieren (die Geburtsstunde der Applets), erfolgte dann aber der Durchbruch mit Netscape, dem damals am weitesten verbreiteten Browser.

JavaScript-Programmierung zu dieser Zeit war wirklich fast mit Folter zu vergleichen und die Applets boten mit einem Schlag die Möglichkeit, in einer strukturierten und objektorientierten Sprache wirklich coole, sich bewegende Dinge zu bauen. Und zwar plattformunabhängig. Es war schlicht genial. Und das galt bei weitem nicht nur für Applets, sondern auch für all die anderen Dinge, die bereits im Funktionsumfang von Java 1.0 enthalten waren (java.awt, java.io, java.util, java.net).

In den folgenden Jahren hat sich Java dann kontinuierlich weiter verbreitet. Im Zusammenhang mit dem UI-Bau kamen bald Konzepte auf, Konstruktionsregeln zu definieren, wie Klassen zu implementieren seien, um die Integration mit entsprechenden Third-Party Tools zu erleichtern. Das war die Geburtsstunde von JavaBeans. Lange Zeit waren aber die Seiten immer noch sehr statisch und es dauerte bis 1999, dass Java EE 1.0 fertig wurde und ein Komponentenmodell auch für die Serverseite definierte. Natürlich war es nicht der einzige Versuch, aber Java und Java EE waren von Anfang an frei verfügbar und jeder Entwickler auf der Welt konnte nun entsprechende Komponente bauen und in einem portablen Format ausliefern. Das hat die Entwicklung im Enterprise-Kontext damals extrem vereinfacht, da mit Java EE eine Menge standardisierter Lösungsmodelle zur Verfügung standen und das Rad nicht in jedem Projekt wieder neu erfunden werden musste.

Treffen Sie Anatole Tresch live auf der JAX 2017:

Brauchen wir noch Java EE?

Donnerstag, 11. Mai, 12:00 – 13:00

JAXenter: Und dann stellt sich natürlich die Frage, wie sich dieser Kontext bis heute verändert hat. Was sind aus deiner Sicht hier die Meilensteine der Entwicklung? Denkst du, dass Java EE bis heute mit der eben skizzierten Entwicklung mithalten konnte?

Anatole Tresch: ​In den Folgejahren hat sich Java EE kontinuierlich weiterentwickelt und es wurden immer größere und komplexere Lösungen damit gebaut. Entsprechend taten sich dann auch nach und nach Grenzen von Java EE bzw. von Java selbst auf. So zeigte Spring sehr schön, dass gewisse Dinge wirklich viel einfacher gehen. Viele Entwickler können sich heute nicht an die Zeiten erinnern, wo man für eine einzige EJB ganze acht Artefakte erzeugen musste (Home, Remote, LocalHome, RemoteHome, Interfaces, Bean Implementation, Deskriptoren).

Aber es zeigten sich auch Probleme, die in der Java-Sprache ihren Ursprung haben, etwa die verwässerten Zugriffsmechanismen (protected, package private) von Java selbst, die fehlende Isolation zur Laufzeit (z.B. bei Speicherproblemen oder Reflection) oder die fehlenden Möglichkeiten echter Modularisierung (was letztendlich zu OSGi geführt hat). Auch die Versionierung einzelner Baukomponenten wurde mit dem maven-build-System extern gelöst. Parallel dazu sind die Anforderungen an die Performanz und Leistungsfähigkeit der Java-EE-Plattform kontinuierlich mit der Verbreitung von Java gestiegen. Entsprechend haben wir vertikal und horizontal skaliert, aber der architektonische Grundansatz blieb weitgehend unverändert und basiert nach wie vor auf kooperierenden Applikationsservern.

Lesen Sie auch: Java EE trifft Microservices: Elefant im Porzellanladen?

Spätestens mit der Mobiltechnologie, die eine Größenordnung mehr Last beispielsweise bei 24×7-Betrieb erfordert, können wir Java EE nicht mehr einfach blind einsetzen. Wir müssen uns eben auch über die Auswirkungen von serverseitigem Kontext, Ausfällen, Locks und Transaktionen Gedanken machen. Die Datenmengen im IOT-Umfeld und globale ereignisgesteuerte Systeme erfordern dann definitiv flexiblere Architekturansätze, wo sich für mich Java EE nicht zwingend als beste Lösung präsentiert.

Ein wichtiges Merkmal der Java-Plattform haben wir bis jetzt aber noch nicht angesprochen: die Portabilität. Mit dem Aufkommen der Container-Technologie ist Portabilität als Vorteil der Java-Technologie praktisch verschwunden. Ich kann praktisch jede andere Technologie, die im Container betrieben werden kann, nutzen und diese entsprechend portabel deployen. Dabei bringen Container auch einige Verbesserungen, die wir im Java-Umfeld lange vermisst haben. Dazu zählen eine klare Isolation und Ressourcenkontrolle sowie die Möglichkeiten, Komponenten zur Laufzeit auszutauschen und in mehreren Versionen betreiben zu können. Orchestrierung nutzt diese Basis und erlaubt es uns, große Systeme mit einem sehr hohen Automatisierungsgrad zu betreiben und auch größere Ausfälle des Subsystems (HW, Netzwerke) vollautomatisiert zu beheben. Kommt noch dazu, dass die Isolation und Ressourcenkontrolle es erlaubt, genau die Teilsysteme (im besten Fall automatisch) zu skalieren, welche den aktuellen Flaschenhals einer Lösung bilden. Diese Flexibilität sucht man bei Java EE vergeblich und es sieht auch nicht so aus, als ob diese in absehbarer Zeit in den Standard einfließen wird.

JAXenter: Java EE 9 soll das „Cloud & Microservices“ Release für Java EE werden. Nach dem, was wir darüber aus Oracles Ankündigungen wissen: Wird Java EE 9 mit den Cloud-nativen Technologien wie AWS Lambda, Kubernetes, Mesos, etc. mithalten können?

Oracle hat das Thema „Cloud“ leider lange Zeit ignoriert.

Anatole Tresch: ​Oracle hat das Thema „Cloud“ leider lange Zeit ignoriert. Java EE 8 wird einige wichtige Verbesserungen bringen, die Unterstützung der neuesten HTTP-Standards und die Möglichkeit Security-Mechanismen als Teil des Applikations-Deployments mitzuliefern. Gerade letzteres ermöglicht es, Java-EE-Komponenten flexibel und vollautomatisiert ohne Vendor-spezifische Vorkonfiguration von Ressourcen zu deployen, ähnlich der Funktionen von AWS Lambda oder Apache Openwhisk. Aber es gibt auch diverse Bereiche, in denen sich auch in Java EE 8 nichts tun wird. Wir werden nach wie vor eine relativ monolithische Plattform haben, Transaktionen werden nach wie vor an den Request-Thread gebunden sein, JDBC und damit auch JTA werden keine asynchrone Verarbeitung unterstützen. Im Bereich der Standardisierung von NoSQL-Datenbanken gibt es erste Initiativen, aber ob und in welcher Form diese in Java EE 9 einfließen werden, ist aktuell komplett offen.

Generell scheint mir eine Aussage zu Java EE 9 sehr schwierig. Mein persönliches Gefühl ist, dass Java EE in Zukunft an Bedeutung verlieren wird und dass wir wieder mehr individuelle Frameworks und Lösungen sehen werden, die neuere Entwicklungen schneller aufnehmen können. Die Containerisierung begünstigt dabei ein solches Vorgehen und erlaubt es, auch bestehende Lösungsansätze aus anderen Ökosystemen in eine Lösungsarchitektur zu integrieren. Kommt hinzu, dass Infrastrukturaspekte wie Service Location und Skalierung nur noch beschränkt im Java-Kontext zu implementieren sind, da diese durch die Orchestrierung abgedeckt werden.

JAXenter: Was ist die Kernbotschaft deiner Session, die jeder mit nach Hause nehmen sollte?

Anatole Tresch: ​Java EE hat sich lange Zeit sehr gut bewährt und hat aus historischer Sicht Sinn gemacht. Mit dem Aufkommen von Containern und Orchestrierungsplattformen werden aber viele Funktionalitäten obsolet bzw. werden von der Orchestrierung effizienter und besser gelöst. Das macht auch die Entwicklung aus Java-Sicht einfacher, da viele Infrastrukturaspekte nicht mehr in Java selbst abgehandelt werden müssen. Selbst die Modularisierung, wie sie aktuell mit Java 9 im Raum steht, könnte man bzgl. Kosten-Nutzen-Faktor in Frage stellen. Dennoch werden uns Java und Java EE noch lange begleiten und richtig eingesetzt ist es nach wie vor eine gute und bewährte Technologie, um Microservices zu implementieren. Aber Java und Java EE sind keine Inseln mehr, sondern müssen sich in Zukunft vermehrt in Sachen Interoperabilität, Performanz und Ressourceneffizienz mit Java-fernen Technologien auseinandersetzen.

Nach dem Wirtschaftsinformatikstudium an der Universität Zürich war Anatole Tresch mehrere Jahre lang als Managing Partner, Berater, Lead Engineer und technischer Architekt tätig. Er sammelte weitreichende Erfahrungen in allen Bereichen des Java-Ökosystems von IOT bis Java EE. Aktuell ist Anatole Tresch Principal Consultant bei Trivadis AG und beschäftigt sich in diesem Zusammenhang mit evolutionärer Architektur, Resilient Design, DevOps und verteilten Systemen. Weiter ist er JCP Star Specification Lead und aktiver Apache PPMC Member.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.