Die Architektur heutiger Legacy Systeme ist meist monolithisch: Die fachlich benötigte Funktionalität wird in einem großen Softwarepaket implementiert, ausgeliefert und in Betrieb genommen. Dabei kann der Monolith durchaus mit einer gut durchdachten Struktur entworfen worden sein. Häufig gab es aber keine technischen Mittel, die Einhaltung der Struktur über einen langen Zeitraum von Weiterentwicklungen des Systems zu erzwingen. So kam es häufig zu einer schleichenden Erosion der Struktur. Es entstanden nicht vorhergesehene Abhängigkeiten innerhalb des Systems, die mit der Zeit zu einer immer weniger handhabbaren Komplexität führten.

Klassische Softwaremonolithen sind aufgrund ihrer Größe und Komplexität den heutigen Anforderungen nach Flexibilität, wie sie beispielsweise im Retail durch den Wettbewerb mit Online-Lieferdiensten entstehen, oft nicht mehr gewachsen.

Moderne Systemarchitekturen streben im Vergleich zum Monolithen vor allem einen höheren Grad an Modularisierung an. Module sind kleinere, am besten nach fachlichen Kriterien zusammengestellte, Softwarebausteine. Sie stellen ihre Funktionalität über stabile Schnittstellen zur Verfügung. Durch Kapselung wird gewährleistet, dass sie nur auf die vorgesehene Art verwendet werden können.

Auf diese Weise tragen Module zur Vermeidung von ungewollten Abhängigkeiten innerhalb großer Systeme bei. Aufgrund ihres bewusst klein gehaltenen Funktionsumfangs sind sie besser zu verstehen. Module sind autonome Softwarebausteine, die im Zusammenspiel mit anderen Modulen die fachlich benötigte Funktionalität großer Anwendungen zur Verfügung stellen. Durch Modularisierung werden große Systeme besser wart- und erweiterbar. Klar definierte Schnittstellen erlauben eine unabhängige und zeitlich parallele Entwicklung. Moderne Ablaufumgebungen erlauben flexible, zielgenaue und automatische Skalierung.

Wie kommt man nun zu einer modularisierten Anwendungsarchitektur? Für den Architekturentwurf muss eine komplexe Domäne am besten anhand fachlicher Kriterien in überschaubare Teildomänen aufgeteilt werden. Hierzu gibt es rund um Domain Driven Design (DDD) viele bewährte Methoden und Entscheidungskriterien.

Wurde eine Domäne sauber nach fachlichen Gesichtspunkten in Teildomänen zerlegt, setzt bei Softwareentwicklerinnen und -entwicklern häufig der Reflex ein, für jede Teildomäne (jeden bounded context) einen eigenen, autarken Microservice zu bauen. Sie folgen dabei einem seit Jahren vorherrschenden Trend für Softwarearchitekturen – und tatsächlich gibt es für Microservices eine ganze Reihe sehr guter Argumente.

Microservicebasierte Architekturen haben aber auch einen Preis. Es hat sich gezeigt, dass vor allem aufgrund der für Microservices typischen Verteilung des Gesamtsystems auf viele, über ein Netzwerk kommunizierende Module eine neue Komplexität entsteht. Im Extremfall kann die Kopplung der Module zu lose werden und die Komplexität der Verteilung gerät außer Kontrolle.

Grundsätzlich bestehen Softwaresysteme immer aus Teilsystemen, die miteinander kommunizieren. Jede Kommunikation zwischen Teilsystemen ist gleichbedeutend mit einer Abhängigkeit. Wird die Anzahl der Abhängigkeiten zu groß, entsteht mit der Zeit Komplexität, die kaum zu beherrschen ist. Moderne Softwarearchitekturen reduzieren daher die Anzahl von Abhängigkeiten, indem fachlich zueinander gehörige Teilsysteme zu Modulen zusammengefasst werden. Die Kommunikation innerhalb eines Moduls ist dann sehr intensiv (hohe Kohäsion), während die Kommunikation über Modulgrenzen möglichst geringgehalten wird (lose Kopplung).

Bei der Kommunikation von Teilsystemen ist es ein fundamentaler Unterschied, ob sie innerhalb eines Betriebssystemprozesses stattfindet, oder ob sie Prozessgrenzen überschreitet und über ein Netzwerk ausgeführt wird: Kommunikation innerhalb eines Prozesses ist allgegenwärtig, verlässlich und performant. Im Unterschied dazu erfolgt Inter-Prozess-Kommunikation über Netzwerke, was nicht nur technisch aufwändiger, sondern auch weniger performant und verlässlich ist. Monitoring sowie Fehleranalyse und -behebung in vernetzten Systemen sind deutlich schwieriger als bei Teilsystemen innerhalb eines Prozesses. Bei der Aufteilung von Teilsystemen in Module kommen also neben fachlichen auch technische Aspekte zum Tragen.

Für die Kommunikation zwischen Modulen kommen zwei Varianten in Betracht: der direkte Aufruf von Schnittstellen und der Nachrichtenaustausch (Messaging). Beide Varianten können sowohl innerhalb eines Prozesses (mehrere Module können innerhalb eines Prozesses ausgeführt werden) als auch über Prozessgrenzen hinweg eingesetzt werden. Es bleibt aber bei den genannten Einschränkungen für die Kommunikation über Netzwerke.

Komplexe Geschäftsabläufe werden nicht von einem Modul abgedeckt, sondern erfordern Kommunikation zwischen Modulen. Wenn diese über ein Netzwerk verteilt sind, Prozessgrenzen also überschritten werden müssen, können die Operationen nicht transaktionsgeschützt erfolgen. Ohne Transaktionen aber ist die Gewährleistung von modulübergreifenden Geschäftsregeln (z. B. referenzielle Integrität von Objekten oder systemweite Datenkonsistenz) nicht trivial.

Auch diese Aspekte müssen bei der Aufteilung eines Systems in Module zwingend mit beachtet werden. In vielen Projekten hat sich aber herausgestellt, dass Transaktionssicherheit weit weniger häufig benötigt wird, als angenommen.

In diesem Zusammenhang sei noch erwähnt, dass bei der Aufteilung von Fachdomänen in disjunkte Teildomänen oft eine gewisse Redundanz in Kauf genommen werden muss: Bestimmte Eigenschaften von Geschäftsobjekten (identifizierende Schlüssel, Bezeichnungen etc.) sind in mehreren Teildomänen relevant. Werden die Teildomänen als voneinander unabhängige Module implementiert, lässt sich eine wiederholte Implementierung dieser Aspekte nicht vermeiden.

Ein weiterer Aspekt mit Auswirkungen auf technische Architekturentscheidungen ist der generelle Ablauf von fachlichen Prozessen: Erfordert ein Prozessschritt synchrone Kommunikation zwischen Modulen, wird also das Ergebnis einer Operation direkt für folgende Prozessschnitte benötigt, oder kann zugunsten einer loseren Kopplung der Module auch asynchron über Nachrichten kommuniziert werden, die zeitlich verzögert bei den Empfängern eintreffen?

Ein Beispiel: Fragt ein Kunde im Einzelhandel an einem Self-Service-Terminal nach dem Preis einer Ware, erwartet er direkt die entsprechende Auskunft. Interessiert er sich für Detailinformationen zu einem Artikel, ist es eventuell akzeptabel, wenn selten angefragte Teile der Informationen erst mit einer Verzögerung geliefert werden.

Verzögerungen durch asynchronen Nachrichtenaustausch können vorübergehend zu Inkonsistenzen im System führen. Die Erfahrung mit nachrichtenbasierten Systemen hat gezeigt, dass solche Inkonsistenzen sehr häufig fachlich akzeptabel sind, solange sie hinreichend schnell aufgelöst werden (eventual consistency). Ein Beispiel hierfür können Bestellvorgänge sein: Bei entsprechenden Lagerbeständen können Bestellungen abgeschlossen werden, ohne dass der Lagerbestand sofort aktualisiert wird.

Aus technischer Sicht ist eine Kommunikation von Modulen über Nachrichten immer interessant, wenn es um möglichst lose Kopplung zwischen den beteiligten Systemen geht. Bei dieser Art von Kommunikation müssen sich Sender und Empfänger nicht kennen, der Empfänger muss zum Zeitpunkt des Sendens einer Nachricht noch nicht einmal verfügbar sein. Allerdings ist der technische Aufwand für die Kommunikation über Nachrichten auch höher: Eine Infrastruktur (Messaging System) für Speicherung und Transport von Nachrichten muss vorgesehen werden.

Aufgrund der beschriebenen, komplexen technischen Rahmenbedingungen für Microservice-Architekturen wird nach alternativen technischen Konzepten gesucht, die die Vorteile der Modularisierung nutzen, ohne die technische Komplexität verteilter Systeme ausufern zu lassen.

Seit einiger Zeit wird hierzu ein „Modulith“ genanntes Konzept diskutiert. Schon der Name deutet an, dass das Beste aus zwei Welten vereint werden soll. Das Konzept basiert auf der Idee, die fachlichen Modulgrenzen innerhalb einer Deploymenteinheit auch technisch abzusichern, ohne Module in vollständig autarke Microservices „auszulagern“.

Wie eingangs beschrieben stellen fehlende technische Modulgrenzen bis heute im Monolithen ein ernst zu nehmendes Problem dar. Da der Monolith als eine einzige Deploymenteinheit ausgeliefert und in Betrieb genommen wird, konnte in der Vergangenheit Modulkapselung bestenfalls durch Konventionen und organisatorische Maßnahmen aufrechterhalten werden. Früher oder später führt die schwache Kapselung jedoch fast zwangsläufig zu unerwünschten Abhängigkeiten und bald zu nicht mehr handhabbarer Komplexität im Monolithen (Stichwort „big ball of mud“).

Trotzdem kehrt man beim Modulithen wieder zurück zu größeren Deploymenteinheiten. Diesmal aber nicht, ohne die Modulgrenzen innerhalb der Deploymenteinheit technisch wasserdicht abzusichern. Möglich wird dies etwa durch Features der verwendeten Programmiersprache, die die bestehenden Kapselungsmechanismen auf ein neues Level heben und ein Modulkonzept in der Programmierung explizit unterstützen. Durch dieses Konzept werden mehrere Probleme sowohl bei Microservices als auch beim Monolithen auf einmal gelöst: Die Kommunikation zwischen Modulen kann wieder lokal, effizient und ohne Netzwerk erfolgen. Die unerwünschten Abhängigkeiten zwischen Modulen im Monolithen werden durch technische Kapselung eliminiert.

Besitzen Modulithen also alle Vorteile beider Welten? Nicht ganz. Es gibt einige „Trade-offs“, derer man sich bei der Entscheidung für einen der Ansätze bewusst sein sollte.

Modulithen sind vergleichsweise große Deploymenteinheiten. Will man einen Modulithen skalieren, geht das wie schon bei den Monolithen nur, indem die Deploymenteinheit als Ganzes skaliert wird. Das bedeutet, dass nicht nur die Teilsysteme skaliert werden, für die eine Skalierung benötigt wird, sondern alle in der Deploymenteinheit enthaltenen Module. Durch die Modularisierung in Modulithen spricht aus technischer Sicht nichts dagegen, einen Kompromiss anzustreben: Die Teilsysteme, für die eine Skalierung nicht benötigt werden, laufen weiter im Modulith, die anderen laufen als skalierbare Microservices. Konzeptionell spricht jedenfalls nichts gegen eine Koexistenz von Modulen im Modulithen und microservicebasierten Modulen.

Ein weiterer Unterschied zum Microserviceansatz ist, dass die Module für ihre Implementierung keine so große Wahlfreiheit bezüglich der eingesetzten Technologie haben. Der Technologiestack muss beim Modulithen einheitlich sein, Programmiersprachen und Frameworks können nicht so frei gewählt werden wie bei den Microservices. In der Praxis ist allerdings fraglich, ob das wirklich ein Nachteil ist. In vielen Unternehmen ist es nämlich nicht erwünscht, dass jedes für einen Microservice zuständige Team seinen Technologiestack frei wählen kann.

Modulithen stellen bei der Modernisierung eine äußerst interessante Alternative zum Microservice-Reflex dar. Sie ermöglichen eine saubere Strukturierung von großen Softwaresystemen und reduzieren deren Komplexität, indem sie das Entstehen ungewollter Abhängigkeiten vermeiden. Gleichzeitig reduzieren sie auch die Komplexität der Infrastruktur, die aufgrund der starken Verteilung von Microservices entsteht. Schließlich bietet die Koexistenz von Modulith und Microservices die Möglichkeit, Nachteile des Modulithen bei der Skalierung effektiv zu kompensieren.

Das könnte Sie auch interessieren