Modulare Monolithe statt Microservices

Ein Monolith ist kein verteiltes System, deshalb hat er auch nicht die Probleme, die verteilte Systeme haben. Wenn zwei Services miteinander kommunizieren, wissen wir im Fehlerfall nicht, ob Requests beim Ziel angekommen sind oder ob wir einfach länger warten müssten – im Monolith gibt es keine Netzwerk-Kommunikation innerhalb der Anwendungsschicht. Sobald eine Geschäftstransaktion auf mehrere Microservices aufgeteilt ist, wird es schnell sehr aufwändig, weil wir Muster wie "Two Phase Commit" oder ein "Saga"-Pattern einsetzen müssen [1]. Im Monolith dagegen läuft alles in einem Prozess und wir haben die Transaktionsgrenzen einfach unter Kontrolle.

Modularisierung to the rescue

Leider ist es bei Monolithen sehr einfach, Code zu koppeln, der nicht gekoppelt sein sollte – daher auch ihr schlechter Ruf als "Big Ball of Mud". Die Lösung für einfache Koppelungen kennen wir schon seit den 70ern: wir modularisieren. Das heißt, wir zerlegen unser System in abgegrenzte Bausteine mit hoher Kohäsion und loser Koppelung und klaren Schnittstellen zwischen den Bausteinen. Wir pimpen unsere Monolithe zu modularen Monolithen (auch "Modulithe" genannt) – und erhalten so die Lösung für alle unsere Probleme.

Natürlich sind modulare Monolithe nicht die allumfassende Lösung, denn wir kommen nicht in den Genuss der Vorteile von Microservices. Der Build-Prozess ist langwieriger. Alles läuft in einer Laufzeit-Umgebung. Damit kann man zur Lastverteilung und Ausfallsicherheit nur insgesamt skalieren, anstatt einzelne Teile gezielt zu skalieren. Ein Fehler in einem Teil der Anwendung kann unter Umständen das gesamte System lahmlegen. Wenn man eine neue Version ausrollt, muss man immer alles komplett ausrollen. Damit wird es schwieriger, mit mehreren Teams parallel zu entwickeln, weil alle sich im gemeinsamen Deployment treffen müssen und nicht unabhängig liefern können.

Am Ende ist es eine Architektur-Entscheidung und wir müssen abwägen: Gibt es gute Gründe, die gegen einen Monolithen sprechen? Verstehen wir die fachlichen Anforderungen so gut, dass wir uns einigermaßen sicher sind hinsichtlich der Aufteilung des Systems in Bausteine? Oder wollen wir im Sinne von "Keep it simple, stupid!" mit etwas Einfachem anfangen und den Monolithen als Sprungbrett für eine spätere Aufteilung in Microservices nutzen?

Fachlich vor technisch

Module sind klar erkennbare Bausteine, die sich jeweils um getrennte Belange kümmern (Separation of Concerns) und durch bewusst entworfene Schnittstellen miteinander kommunizieren. Die erste Frage ist: Schneiden wir die Module fachlich oder technisch? Technische Schnitte, z. B. in Datenbank-Schicht, Business-Schicht und REST-API-Schicht (s. Listing 1), sind naheliegend, aber sie verletzen das Single-Responsibility-Prinzip. Für jeden neuen oder geänderten Use Case müssen wir jede dieser Schichten anfassen. Damit gibt es in jedem technischen Modul viele Gründe für Veränderungen. Fachliche Modulschnitte sind in der Regel besser, denn fachliche Erweiterungen und Änderungen betreffen einen Use Case oder eine Gruppe von Use Cases, während die anderen unbeeinflusst bleiben. Aus dem gleichen Grund hat ein technischer Schnitt eine niedrige Kohäsion und eine starke Koppelung zwischen den Modulen: Für jeden Use Case müssen die Module miteinander kommunizieren, aber innerhalb der gleichen Schicht haben die verschiedenen Use Cases selten etwas miteinander zu tun. Fachliche Module verfügen dagegen über eine hohe Kohäsion und lose Koppelung, weil es viele fachliche Gründe für Kommunikation innerhalb eines Moduls gibt und wenige dafür, dass Module untereinander reden.

Listing 1: Technische Modularisierung.

src/main/java
 ├── rest
 ├── domain
 └── persistence

Das erste Problem besteht also darin, die fachlichen Anforderungen sinnvoll zu zerlegen. Diese Herausforderung bekommen wir frei Haus, unabhängig davon, ob wir modulare Monolithen oder Microservices implementieren. Um sie zu meistern, helfen Techniken aus dem Domain-driven Design wie Event Storming oder Domain Story Telling[2]. Mit ihnen finden wir auf jeden Fall einen guten initialen Schnitt der Module. Nun werden wir im Laufe der Zeit bestimmt fachliche Aspekte dazulernen. Das ist für sich genommen erfreulich, bedeutet aber, dass wir den anfänglichen Entwurf immer wieder anpassen müssen. Den perfekten fachlichen Schnitt ohne Verfallsdatum gibt es wohl nicht.

Was sieht ein neues Teammitglied, wenn es zum ersten Mal den Code öffnet? Im Idealfall "schreit" die Architektur aus dem Code heraus, wie es Robert Martin fordert [3]. Die Module sind klar zu erkennen und man kann sofort ahnen, was die Applikation alles macht. Wenn wir also ein Zeiterfassungssystem implementieren, sollte uns die Ordnerstruktur direkt verraten, dass es hier darum geht, Zeiten zu erfassen, Urlaub zu buchen und Krankmeldungen abzugeben (Listing 2).

Listing 2: Fachliche Modularisierung

src/main/java
 ├── application
 ├── krankheit
 ├── urlaub
 ├── zeiterfassung
 └── infrastructure

Module werden miteinander reden müssen, denn sonst wären sie besser nicht Bestandteile eines größeren Systems. Deshalb ist es unerlässlich, einen Weg zur Kommunikation vorzusehen.

Wie so oft gibt es dafür etablierte Muster, die wir für unseren Einsatzzweck anpassen können: Messaging, Direct Call und Shared Database Data [7]. Schauen wir uns also die drei Muster genauer an und wählen dazu zwei Anwendungsfälle aus unserem Fallbeispiel, die Kommunikation erfordern:

Zum Beispiel möchte man in der Zeiterfassung sehen, ob man an einem bestimmten Tag Urlaub gebucht oder sich krankgemeldet hat. Die Zeiterfassung braucht also eine Sicht auf die Urlaubs- und Krankheitsdaten, mindestens auf der UI-Ebene. Allerdings reicht für diesen Anwendungsfall eine eingeschränkte Sicht auf die Daten. Wichtig ist, dass für den betreffenden Tag eine Krankmeldung vorliegt, ob z. B. auch eine Arbeitsunfähigkeitsbescheinigung abgegeben wurde, ist nicht wichtig.

Der zweite Anwendungsfall betrifft eine Krankmeldung während eines Urlaubs. Diese soll dazu führen, dass der zuvor gebuchte Urlaub während dieses Zeitraums storniert wird. In diesem Fall ist also Wiederverwendung von Business-Logik der Grund für die Kommunikation.

Messaging

Messaging hilft, Microservices möglichst lose zu koppeln. Es gibt eine zentrale Stelle, den Message Bus, bei dem man Nachrichten eines bestimmten Typs abonnieren kann und dann alle Messages dieses Typs erhält. Bei modularen Monolithen befindet sich der Message Bus im Code statt in der Infrastruktur und ist allen Modulen bekannt.

Jedes Modul hat dabei selbst die Hoheit über seine Daten, was gleichzeitig heißt, dass es für die Daten anderer Module weder Lese- noch Schreibrechte besitzt. Wenn es Daten anderer Module braucht, muss es diese bei sich repliziert speichern. Erlaubt ist durchaus, innerhalb des modularen Monolithen den gleichen Datenbank-Server zu verwenden, nur werden die Tabellen nicht zwischen den Modulen geteilt, stattdessen ist jedes Modul Herr über eine Menge an Tabellen.

Das urlaub-Modul schickt z. B. im Fall einer neuen Urlaubsbuchung eine Nachricht; das zeiterfassung-Modul hört auf diese Nachrichten und merkt sich, dass an einem bestimmten Tag Urlaub gebucht wurde. Genauso hört das urlaub-Modul auf Krankmeldungs-Nachrichten und storniert gegebenenfalls den Urlaub (s. Abb. 1).

Der größte Vorteil von Messaging ist die lose Koppelung: Module kennen sich nicht gegenseitig, sondern nur den Message Bus und das Datenaustausch-Format. Die Business-Logik, z. B. für die Stornierung von Urlaub, befindet sich außerdem an einer einzigen Stelle und die getrennte Datenhaltung macht es einfach, die Module später in einzelne Services auseinanderzuziehen.

Die getrennte Datenhaltung und die damit verbundene Daten-Replikation bringen jedoch auch einiges an Komplexität mit sich. Immerhin muss man sich weniger Sorgen um die Konsistenz der Daten machen als bei Microservices, weil keine Netzwerkkommunikation notwendig ist. Deshalb kann man sich sicher sein, dass die Daten angekommen sind. Ein weiterer Nachteil: Durch die Indirektion über Messages statt des Methoden-Aufrufs ist der Datenfluss außerdem etwas schwerer nachzuvollziehen.

Direct Call

Letzteres ist etwas einfacherer, wenn die Module mittels direkter Aufrufe miteinander reden. Bei Microservices setzt man für dieses Muster typischerweise auf eine Kommunikation über REST-APIs; bei modularen Monolithen kann man diese Kommunikation einfacher realisieren, weil man nur Methoden-Aufrufe benötigt. Folglich entfällt der gesamte Overhead der Netzwerkkommunikation und der damit verbundenen Serialisierung, De-Serialisierung, Authentifizierung und Autorisierung.

Kommunikation per Direct Call führt allerdings zu einer stärkeren Koppelung, denn der Aufrufer kennt das Interface des Aufgerufenen. Außerdem muss man – wie bei Microservices auch – auf die Vermeidung zyklischer Abhängigkeiten achten.

Die Datenhoheit liegt weiterhin bei den einzelnen Modulen. Wenn also ein Urlaub gebucht wird, sagt das urlaub-Modul dem zeiterfassung-Modul per Methoden-Aufruf Bescheid. Dann merkt sich das zeiterfassung-Modul, dass an bestimmten Tagen Urlaub gebucht ist. Wenn eine Krankmeldung erfasst wird, ruft die krankmeldung das urlaub-Modul auf, damit es den Urlaub während des Krankheitszeitraums storniert (s. Abb. 2).

Wie sehen die Parameter dieser Methoden-Aufrufe aus? Beim Stornieren des Urlaubs sollen in unserem Beispiel drei Dinge übermittelt werden: der Zeitraum, der betroffene Mitarbeiter und der durchführende Benutzer. Möchten wir generische Typen dafür verwenden oder eigene Typen einsetzen? Eigene Typen sollten die Rolle von DTOs (Datentransfer-Objekten) haben, denn damit kann man die interne Repräsentation der Daten eines Moduls von der Schnittstelle trennen. Der Preis dafür ist der Mapping-Overhead zur Übersetzung von Schnittstellen-Typ in einen internen Typ. Solange die Parameterliste also noch klein genug ist, kann man mit primitiven Typen oder JDK-eigenen Typen auskommen und spart sich diesen Overhead.

In den bisherigen Kommunikationsmustern mussten wir Daten replizieren, die zwischen Modulen geteilt werden. Bei Shared Database Data teilen wir die Datenbank-Schicht zwischen den Modulen. Das urlaub-Modul speichert die Urlaubsbuchung in der Datenbank und die zeiterfassung greift über den gleichen Weg lesend auf die Urlaubsbuchung zu. Bei einer Krankmeldung storniert das krankheit-Modul die Urlaubsbuchung für den Zeitraum, indem es ebenfalls direkt auf der Datenbankschicht operiert (s. Abb. 3).

Der Vorteil besteht darin, dass man keine Datenreplikation zwischen den Modulen benötigt. Im Beispiel sieht man aber deutlich, wie teuer dieser Vorteil erkauft wird. Die Module sind über die Datenbank stark miteinander gekoppelt und es kann beispielsweise im Fall der Urlaubsstornierung nötig werden, Business-Logik in mehreren Modulen, urlaub und krankheit, zu implementieren.

Wir müssen den Shared-Database-Data-Ansatz also zähmen, wenn wir das Muster sinnvoll einsetzen wollen. Die Duplikation von Business-Logik sollten wir in jedem Fall vermeiden; für diesen Fall brauchen wir eines der anderen Kommunikationsmuster. Auf Datenbankseite sollte jedes Modul die schreibende Hoheit über bestimmte Tabellen haben. Andere Module dürfen darauf höchstens lesend zugreifen.

Als zweite Maßnahme können wir z. B. Spring Data-Projections [8] oder ein explizites Mapping von Datenbank-Entities zu Fachobjekten nutzen, um die Datenbankrepräsentation von der Verwendung innerhalb eines Moduls zu entkoppeln. Für die zeiterfassung ist nur wichtig, dass an einem Tag Urlaub gebucht wurde. Wer ihn wann gebucht hat, interessiert dieses Modul nicht, und es kommt mit einer abgespeckten Sicht auf die Daten blendend zurecht.

Mit diesen beiden Gegenmitteln wird Shared Database Data als Muster erträglich. Wenn man für später eine Aufspaltung in mehrere Services mit getrennter Datenhaltung anstrebt, ist die Verwendung allerdings eine Hürde, die man zuvor aus dem Weg räumen muss.

Die Kommunikationsmuster in der Praxis

Alles klar, wir wählen also Muster 1, 2 oder 3. Doch wie wir gerade gesehen haben, fängt die Arbeit damit erst an: Wie genau wollen wir die Muster einsetzen? Und wie erhalten wir darüber im Entwicklungsteam ein gemeinsames Verständnis? Das Problem ist allgemein – wir werden es bei Microservices genauso antreffen.

Ein Ansatz zur Lösung ist: Wir geben uns gemeinsam Regeln für die Kommunikation zwischen den Modulen. Diese müssen möglichst konkret sein, damit ich als Entwickler weiß, was ich tun soll, und möglichst einfach, damit ich sie nachvollziehen kann. Die Regeln dürfen auch nicht in Stein gemeißelt sein, denn wir werden immer wieder dazulernen oder in Probleme laufen, die eine Anpassung der Regeln notwendig machen – Inspect and Adapt eben.

Beispiele für eine Regel:

• Fachliche Module dürfen sich, wenn notwendig, auch gegenseitig aufrufen
• Zur Wiederverwendung von Business-Logik einsetzen
• Als Aufruf-Parameter keine DTOs verwenden, sondern primitive Typen oder Common-Typen wie "Zeitraum", um den Mapping-Overhead zu vermeiden
• Nicht zum bloßen Holen von Daten einsetzen