Lars Röwekamp open knowledge GmbH

Für die einen sind Microservices das Allheilmittel gegen die vielfältigen Probleme monolithischer Anwendungen, für die anderen ist es lediglich alter Wein in neuen Schläuchen. Wohl kaum ein Architekturansatz polarisiert derzeit so extrem wie Microservices. Doch was steckt wirklich hinter dem neuen Paradigma, welche Vor- und Nachteile bringt es mit sich und wie wird es in der Praxis bestmöglich umgesetzt? Dabei sollte man nicht nur die reine Entwicklung in den Fokus der Betrachtung stellen, sondern auch Real-Life-Aspekte wie Deployment und Betrieb.

In der Enterprise-Community hält sich hartnäckig das Gerücht, dass Java EE nicht wirklich als Werkzeug für die neue Wunderwelt der Microservices geeignet sei. Die Wurzeln des Enterprise-Java-Standards sind jedoch genau dort zu finden, wo wir heute mit dem Architekturansatz der Microservices hin wollen – in stark verteilten, fachlich orientierten Systemen. Warum also hat Java EE, in Bezug auf Microservices, einen so schlechten Ruf? Und ist er gerechtfertigt?

Unabhängig von den vielen Charakteristika, die eine Microservice-basierte Architektur im Detail auszeichnet, stehen vor allem die erhöhte Flexibilität bei Entwicklung und Deployment im Fokus. Etwas managementtauglicher könnte man es auch als „Time-to-Market-Optimierung“ bezeichnen. Leider scheint genau dieses „Time-to-Market“, selbst im Zeitalter von agiler Entwicklung und deutlich kürzeren Releasezyklen als noch vor Jahren, nicht wirklich zu Java EE zu passen. Dabei hebt bereits die erste J2EE-Spezifikation vor mehr als zehn Jahren hervor, dass Enterprise Developer sich zukünftig – dank J2EE – voll und ganz auf die Fachlichkeit der umzusetzenden Anwendung konzentrieren können, anstatt ihre Zeit mit der Lösung von Infrastrukturproblemen zu vergeuden. Zum ersten Mal rückt damals der Aspekt „Time to Market“ als Wettbewerbsvorteil für Anwender des Java-EE-Frameworks in den Fokus. Und auch der Begriff Enterprise Services taucht in der Spezifikation mehrfach auf: „The Java 2 Platform, Enterprise Edition reduces the cost and complexity of developing multitier, enterprise services. J2EE applications can be rapidly deployed and easily enhanced as the enterprise responds to competitive pressures.“

Woran liegt es also, dass Java EE den damaligen Ansprüchen nicht gerecht werden konnte und man sich als Java-EE-Entwickler im Kreise der Microservices-Fans wie ein Elefant im Porzellanladen fühlt?

Java EE und Microservices

Das Java-EE-Framework wird per Definition im Enterprise-Umfeld, somit also in großen Projekten eingesetzt. Derartige Projekte sind historisch bedingt häufig mit entsprechend komplexen Organisations- und Kommunikationsstrukturen versehen. Spätestens seit Conway’s Law wissen wir, dass diese Strukturen automatisch zu unnötig aufgeblähten Systemen führen, die nur wenig – sehr wenig – Flexibilität mit sich bringen: „Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization‘s communication structure.“

Aus dem eben aufgezeigten Betrachtungswinkel muss den Java-EE-Kontrahenten also zunächst einmal Recht gegeben werden. Die Frage, die sich an dieser Stelle allerdings stellt, ist, ob das beschriebene Szenario tatsächlich ein Problem von Java EE beschreibt oder eher ein Problem der Zeit, in der Java EE groß geworden ist. Eine Zeit, in der wir uns damit arrangiert hatten, dass Architekten schichtenbasierte Frameworks oder Generatoren inklusive eigener DSLs bauten, anstatt sich um fachliche getriebene Modularisierung oder fachliche Basiskomponenten zu kümmern. Eine Zeit, in der die einzelnen Teams sich mit ihren jeweiligen Spezialisten in der Regel eher an den verschiedenen Architekturschichten – wie User Interface, Businesslogik und Persistenz – orientierten, anstatt sich „cross-functional“ und somit an der gegebenen Fachlichkeit orientiert aufzustellen.

Ausgereifte Technologie

Betrachtet man einmal nur die Technologie und die APIs von Java EE, so ist es schon ein wenig verwunderlich, dass Java EE nicht für die Entwicklung von Microservices geeignet sein soll. Gehen wir davon aus, dass ein Microservice eine in sich geschlossene Fachlichkeit abbildet – auch bekannt als Bounded Context. Dieser bedient sich anderer Fachlichkeit via (RESTful) Web Services oder stellt anderen Services ihre Fachlichkeit zur Verfügung. Dann bringt Java EE mit CDI, JAX-RS, JPA und Co. alles mit, was notwendig ist, um einen solchen Service zu realisieren. Soll statt einer relationalen Datenbank eine NoSQL-Datenquelle verwendet werden, steht auch dem nichts im Wege, dank entsprechender Libraries. Und auch, wenn der Service sein eigenes, JavaScript-Framework-basiertes HTML 5 UI enthält – z. B. auf Basis des React-Frameworks oder AngularJS –, lässt sich dies problemlos realisieren.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 4.16 - "BPM: Kann mehr als man denkt"

Alle Infos zum Heft
209878Java EE trifft Microservices
X
- Gib Deinen Standort ein -
- or -