Adam Bien Freelancer

Falls man mit einem einzigen WAR die Fachlichkeit effizient abbilden kann, muss man sich nicht mit den Herausforderungen der verteilten Programmierung wie Konsistenz vs. Skalierbarkeit beschäftigen.

Microservices-Architekturen sind ein spannendes Konzept. Aber auch hier gilt es, pragmatisch zu bleiben. Denn nicht alles, was die großen Player machen, braucht man. Und für die Luftschlösser am Beginn eines Projekts sollte man keinen Platz einplanen. Ein praxisgerechter Ansatz sind Microservices mit Java EE in Kombination mit Docker.

Die überwältigende Mehrheit der Java-EE-Projekte wird nach höchst unwahrscheinlichen Annahmen realisiert. Ein Tausch der Datenbank während der Projektlaufzeit, magische Änderungen der Datenbank ohne jegliche Auswirkung auf das UI oder auch eine hohe Änderungshäufigkeit der Algorithmen werden als realistische Szenarien angenommen und bestimmen die Wahl der Patterns und das Design der Anwendung. Auch der hohe Grad der Wiederverwendbarkeit von internen Klassen wird ohne eine Betrachtung der Historie – oder einen Bezug zur Realität – eingeschätzt und resultiert in einer Explosion von Maven-Modulen und unnötigen Abstraktionen.

Alle diese Maßnahmen haben keinen spürbaren Mehrwert für den Benutzer, führen jedoch zu einem bedenklichen Verhältnis von Infrastruktur zu Fachcode. Die Verschleierung der Algorithmen, relevanten Domainklassen und somit auch eine schlechte Änderbarkeit und Wartbarkeit der Anwendung sind die Folge des Cargo Cult Programmings. Die Fachabteilungen, Benutzer und auch Sponsoren sind unglücklich, und es wird dringend nach neuen Lösungen gesucht. Microservices-Architekturen werden als die Lösung des Bloat-Problems gesehen.

Neben den Brown-Field-Projekten sind auch Green-Field-Projekte an Microservices interessiert. Dabei werden Best Practices der großen Vorbilder wie Netflix, Amazon oder Google imitiert. Best Practices von globalen Unternehmen adaptieren auch lokal agierende Mittelstandsfirmen. Patterns und Frameworks für zehntausende elastische Netflix-Server in den Wolken von Amazon werden auch gerne auf das eigene Rechenzentrum angewandt. Dabei hat selbst Netflix nur den sehr stark wachsenden Streaminganteil auf die Microservices-Architektur migriert. Die 5,3 Millionen von DVD-Kunden werden nach wie vor vom eigenen Rechenzentrum und einer monolithischen Architektur bedient. Eine blinde Imitation der großen Vorbilder ist lediglich eine weitere Ausprägung des Cargo Cult Programmings.

Eine kleinere Gruppe von pragmatischen Projekten sucht Lösungen für konkrete, gut abgrenzbare Herausforderungen wie unterschiedlichen Releasezyklen innerhalb einer Anwendung, Zusammenarbeit von kleineren Teams, Einführung von moderneren UI, einfacheres Monitoring und Administrierbarkeit der Anwendungen und stößt nebenbei auf den Begriff Microservices.

Was ist eine Microservices-Architektur?

Eine Microservices-Architektur (MSA) ist schnell erklärt: pragmatisch kommunizierende Prozesse. Dabei muss es schon ein echter Prozess sein. Ein Thread reicht nicht aus. Hier sind sich Martin Fowler und auch Wikipedia einig. Fowler dazu: „In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.“  Und Wikipedia: „Microservices is a specialisation of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. Services in a microservice architecture (MSA) are processes that communicate with each other over a network in order to fulfill a goal. These services use technology-agnostic protocols.“

Übertragen auf Java bedeutet es mehrere Dinge: JVM kommunizieren innerhalb einer Anwendung miteinander. Bei pragmatischen Protokollen stehen uns in Java dafür unzählige Möglichkeiten zur Verfügung. Die grenzenlose Auswahl wird aber durch die Rahmenbedingungen der UI dramatisch eingeschränkt. Unter der Berücksichtigung der aktuellen Trends wie Single Page Applications (SPAs) und nativen, mobilen Apps bleiben nur HTTP(2)/JSON und WebSocket übrig. Genau diese Protokolle werden letztendlich auch für die Kommunikation zwischen den Prozessen verwendet. Je weniger Protokolle verwendet werden, desto einfacher und verständlicher der Code und desto wartbarer die Anwendung.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 4.17 - "APIs"

Alle Infos zum Heft
579777421Praxisgerechte Microservices-Architekturen
X
- Gib Deinen Standort ein -
- or -