Mikroservices oder modularer Monolith?

Wenn wir ein neues Webshop-, Bestellverwaltungs- oder Fertigungsintegrationssystem planen, ist die Frage "Mikroservices oder modularer Monolith" selten nur eine technologische Debatte. Die Wahl beeinflusst die Geschwindigkeit der Auslieferung, die Nachvollziehbarkeit von Fehlern, die Betriebslast, die Zuverlässigkeit der Integration und wie gut das System zur tatsächlichen Arbeitsweise des Unternehmens passt. Eine schlecht getimte architektonische Entscheidung kann keine sofortigen Probleme verursachen, sich aber jahrelang in die Entwicklungs- und Betriebskosten einbetten.

Systemgrenzen sind wichtiger als technologische Labels

Die beiden Ansätze werden oft vereinfacht dargestellt. Monolithen werden als veraltete, schwer zu ändernde Systeme beschrieben, während Mikroservices als automatisch skalierbare, moderne Zielzustände angesehen werden. Das ist irreführend. Ein gut aufgebauter modularer Monolith kann langfristig ein transparentes, testbares und wartbares Geschäftssystem sein. Ebenso kann eine unnötig fragmentierte Mikroservice-Umgebung dauerhafte Risiken durch Netzwerkfehler, Datenabgleich und viele separate Bereitstellungseinheiten darstellen.

Die eigentliche Frage ist, wo die natürlichen Grenzen der Geschäftsprozesse verlaufen. Zum Beispiel kann die Auftragsabwicklung die Lagerreservierung, Preisgestaltung, Rechnungsdatenübertragung, logistische Organisation und Kundenkommunikation verbinden. Wenn diese Schritte eine enge Geschäftstransaktion bilden, kann eine frühe Trennung die Komplexität erheblich erhöhen. Wenn sie jedoch in unterschiedlichem Tempo verändert werden, von verschiedenen Teams verwaltet werden oder unterschiedliche Verfügbarkeits- und Lastanforderungen haben, kann die Trennung einen geschäftlichen Grund haben.

Die Architektur sollte einen nachweisbaren Betrieb unterstützen, nicht organisatorische Moden. Das Ziel ist nicht, möglichst viele Komponenten zu haben, sondern schnell feststellen zu können, was passiert ist, wo es passiert ist und wie der Prozess kontrolliert wiederhergestellt werden kann, sei es bei einem Bestellfehler, verspäteten Lieferantendaten oder einem Ausfall der ERP-Verbindung.

Wann lohnt es sich, mit einem modularen Monolithen zu beginnen?

Ein modularer Monolith ist eine einzelne, bereitstellbare Anwendung, bei der die Funktionen klar in Geschäftsmodule organisiert sind. Beispiele sind der Produktkatalog, die Bestellverwaltung, die Lagerprozesse, Partnerintegrationen oder das Zugriffsmanagement. Die Anwendung läuft als Einheit, aber die Module haben eigene Verantwortlichkeiten, Datenmanagementregeln und gut definierte interne Schnittstellen.

Dies ist besonders ein guter Ausgangspunkt für mittelgroße Unternehmenssysteme, bei denen mehrere interne und externe Prozesse vereinheitlicht werden müssen, aber die Entwicklungs- und Betriebsorganisation noch nicht das Vorhandensein von dutzenden unabhängigen Diensten rechtfertigt. Zum Beispiel ist bei einer Bestell- und Logistikplattform die Datenkonsistenz, die Nachvollziehbarkeit der Prozesse und die schnelle geschäftliche Anpassungsfähigkeit oft wichtiger, als jede Funktion in einem separaten Container laufen zu lassen.

Der Vorteil eines modularen Monolithen besteht darin, dass die Transaktionsverwaltung einfacher ist, weniger Systeme für die Fehlersuche durchlaufen werden müssen und die Bereitstellungskette leichter überschaubar ist. Die Interaktionen der Geschäftsregeln können in einer einzigen versionierten Veröffentlichung verwaltet werden. Das bedeutet nicht, dass das System zu einem ungeordneten Codehaufen mit gemeinsamen Datenbanktabellen werden kann. Im Gegenteil, die Modulgrenzen müssen von Anfang an diszipliniert gehandhabt werden.

Die Grenzen des Ansatzes werden sichtbar, wenn ein Funktionsbereich sehr unterschiedliche Lasten erhält, in separaten Lebenszyklen entwickelt wird oder die Koordination der Veröffentlichungen unverhältnismäßig langsam wird. In solchen Fällen muss das gesamte System nicht neu geschrieben werden; vielmehr sollte geprüft werden, welche Module für eine Trennung reif sind.

Wann sind Mikroservices gerechtfertigt?

Die Mikroservice-Architektur bietet echte Vorteile, wenn die unabhängigen Dienste sowohl geschäftlich als auch betrieblich autonom sind. Ein Dienst hat eine klare Verantwortung, eine eigene Schnittstelle, idealerweise eigene Datenverwaltungshoheit und einen separaten Bereitstellungsprozess. Es geht nicht nur darum, Teile der bestehenden Anwendung in separate Prozesse oder Container zu verlagern.

Es kann zum Beispiel gerechtfertigt sein, einen stark frequentierten Produkt- und Preisinformationsdienst zu trennen, wenn er auf unterschiedliche Weise von Webshops, B2B-Portalen, Marktplätzen und internen Vertriebssystemen genutzt wird. Ebenso kann eine Lieferantenintegrationsschicht, die mit mehreren Anbietern kommuniziert und eigene Wiederholungs-, Protokollierungs- und Verarbeitungsregeln benötigt, ein unabhängiger Bereich sein. In diesen Fällen kann die separate Skalierung, unabhängige Veröffentlichungen und gezielte Fehlerbehandlung greifbaren geschäftlichen Wert schaffen.

Die Kosten sind jedoch erheblich. Die Netzwerkkommunikation zwischen Diensten kann ausfallen oder sich verzögern. Was früher eine einfache Datenbanktransaktion war, wird zu Nachrichtenverarbeitung, Ereignisverarbeitung, wiederholter Verarbeitung und manchmal vorübergehend unterschiedlichen Datenzuständen. Die Identifizierung des Dienstes, Zugriffssteuerung, zentrale Protokollierung, Metrikensammlung, Alarme, Konfigurationsmanagement, Sicherung und Versionskompatibilität sind zu lösende Aufgaben. Diese sind keine Zusatzaufgaben, sondern Teil der Architektur.

Mikroservices oder modularer Monolith: Welche Beweise sollten unsere Entscheidung leiten?

Die Entscheidung sollte aus dem tatsächlichen Betrieb abgeleitet werden, nicht aus der angenommenen zukünftigen Größe. Die Tatsache, dass ein Unternehmen wachsen möchte, rechtfertigt allein keine Mikroservices. Wachstum erfordert oft zunächst saubere Stammdaten, zuverlässige Integrationen, konsistente Zugriffsmodelle und messbare Prozesse.

Zuerst sollte bestimmt werden, welche Geschäftsbereiche sich häufig und unabhängig ändern. Wenn jede Änderung in der Lagerlogik eine vollständige Veröffentlichung für das Kundenportal, die Abrechnung und die Preisgestaltung erfordert, sind die Grenzen wahrscheinlich zu eng. Wenn die Funktionen jedoch im Allgemeinen als Teil eines Geschäftsprozesses geändert werden, kann die separate Bereitstellung mehr Koordination als Vorteil bringen.

Zweitens sollte das Eigentum an den Daten untersucht werden. Viele Architekturen werden schwer zu handhaben, weil mehrere Dienste direkt dieselben Bestell-, Kunden- oder Bestandsdaten ändern. In Mikroservices sollte jedes kritische Datenobjekt einen klaren Eigentümer haben. Andere Systeme können Daten anfordern oder Prozesse über Schnittstellen oder Ereignisse initiieren. Dies erfordert mehr Disziplin, macht die Verantwortung jedoch berechenbarer.

Drittens sollte die betriebliche Reife realistisch bewertet werden. Gibt es eine einheitliche Protokollierung und Überwachung? Kann eine Geschäftstransaktion über mehrere Systeme hinweg verfolgt werden? Werden Geheimnisse und Zugriffe sicher gehandhabt? Sind die Test- und Veröffentlichungsprozesse mit Rollback-Optionen automatisiert? Wenn diese noch nicht vorhanden sind, lohnt es sich, die Grundlagen zu stärken, bevor Mikroservices eingeführt werden.

Eine schrittweise Trennung birgt in der Regel weniger Risiko

Die Architektur ist keine einmalige, endgültige Entscheidung. Ein disziplinierter modularer Monolith eignet sich für die spätere gezielte Trennung von Funktionen, wo die Unabhängigkeitsanforderungen gerechtfertigt sind. In einem schrittweisen Ansatz werden zunächst stabile interne Modulgrenzen, dokumentierte Schnittstellen und getrennte Verantwortlichkeiten geschaffen. Dann kann ein konkreter, wertvoller Bereich – wie die Partnerdatenübertragung oder die Benachrichtigungsverarbeitung – zu einem unabhängigen Dienst werden.

Die Trennung sollte an messbare Probleme gebunden sein. Diese können dauerhaft unterschiedliche Lastprofile, häufige und unabhängige Geschäftsänderungen, spezielle technologische Anforderungen oder Fehlerisolierung bei einer externen Integration sein. "Es wird irgendwann gut skalieren" ist kein ausreichender Grund, wenn dabei die tägliche Betriebsübersichtlichkeit leidet.

In vielen Fällen ist eine hybride Lösung die beste. Die zentralen Geschäftsprozesse bleiben im modularen Monolithen, während die asynchronen, volumenstarken oder intensiven externen Systemkommunikationsbereiche als separate Dienste betrieben werden. Dies ist besonders relevant für ERP, Webshop, Lager- und Lieferantensystemintegrationen, bei denen die Zuverlässigkeit der externen Verbindungen und die Handhabung der Wiederverarbeitung besondere Aufmerksamkeit erfordern.

Betriebsfähigkeit als Designanforderung

Unabhängig vom gewählten Modell sollten die betrieblichen Anforderungen in der Entwurfsphase festgelegt werden. Ein geschäftskritisches System muss fehlerhafte oder fehlende Nachrichten, wiederholte Verarbeitung, Zugriffsprotokollierung, Sicherung, Kapazitätsüberwachung und kontrollierte Veröffentlichungen handhaben. Diese sind nicht nur Infrastrukturaufgaben; sie beeinflussen direkt die Auftragsabwicklung, die Genauigkeit der Bestandsdaten und die Präzision der Finanzprozesse.

Im CGAT-Ansatz beginnt die Auswahl der Architektur mit der Bewertung der Geschäftsprozesse, der Identifizierung der Integrationsgrenzen und der Klärung der betrieblichen Anforderungen. Der Wert eines Systems wird nicht durch die Anzahl der enthaltenen Dienste bestimmt, sondern dadurch, wie es das Unternehmen auf eine überprüfbare, nachhaltige Weise unterstützt, die mit dem täglichen Betrieb im Einklang steht, selbst in Zeiten des Wandels.

Vor der nächsten Entwicklungsentscheidung sollte gefragt werden, nicht welche Architektur moderner klingt, sondern welche Struktur die kritischen Geschäftsprozesse verständlicher, änderbarer und betreibbarer in einem Jahr macht.