Mikroservices oder modularer Monolith?

Wenn wir ein neues Webshop-, Bestellverwaltungs- oder Fertigungsintegrationssystem planen, ist die Frage "Mikroservices oder modularer Monolith" selten nur eine technologische Diskussion. Die Wahl beeinflusst die Veröffentlichungsrate, die Rückverfolgbarkeit von Fehlern, die Betriebslast, die Integrationszuverlässigkeit und wie gut das System zu den tatsächlichen Abläufen des Unternehmens passt. Eine schlecht getimte architektonische Entscheidung kann nicht sofort Probleme verursachen, aber sie kann sich über Jahre hinweg in die Entwicklungs- und Betriebskosten einfügen.

Systemgrenzen sind wichtiger als technologische Labels

Die beiden Ansätze werden oft vereinfacht dargestellt. Monolithen werden als veraltete, schwer anpassbare 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 nachhaltiges Geschäftssystem sein. Ebenso kann eine unnötig fragmentierte Mikroservice-Umgebung dauerhafte Risiken durch Netzwerkfehler, Datensynchronisation 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 geä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 eine nachweisbare Funktionalität unterstützen, nicht einen organisatorischen Trend. Das Ziel ist nicht, so viele Komponenten wie möglich zu haben, sondern schnell festzustellen, was passiert ist, wo es passiert ist und wie der Prozess auf kontrollierte Weise wiederhergestellt werden kann, im Falle eines Bestellfehlers, verspäteter Lieferantendaten oder eines ERP-Ausfalls.

Wann ist es sinnvoll, mit einem modularen Monolithen zu beginnen?

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

Dies ist ein besonders 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ängiger Dienste rechtfertigt. Bei einer Bestell- und Logistikplattform sind beispielsweise Datenkonsistenz, Prozessnachvollziehbarkeit und schnelle geschäftliche Anpassungsfähigkeit oft wichtiger als das Ausführen jeder Funktion in einem separaten Container.

Der Vorteil eines modularen Monolithen besteht darin, dass die Transaktionsverwaltung einfacher ist, weniger Systeme für die Fehlerbehebung durchlaufen werden müssen und die Bereitstellungskette leichter nachvollziehbar 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 vom ersten Tag an diszipliniert gehandhabt werden.

Die Grenzen des Ansatzes werden sichtbar, wenn ein funktionaler Bereich sehr unterschiedliche Lasten erhält, sich in unterschiedlichen Lebenszyklen entwickelt oder die Koordination der Veröffentlichungen unverhältnismäßig langsam wird. In solchen Fällen muss das gesamte System nicht neu geschrieben werden; es sollte vielmehr untersucht 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, vorzugsweise eigene Datenverwaltungsrechte und einen separaten Bereitstellungsprozess. Es geht nicht nur darum, Teile der bestehenden Anwendung in separate Prozesse oder Container zu verschieben.

Es kann gerechtfertigt sein, beispielsweise einen hochfrequentierten 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öffentlichung und gezielte Fehlerbehandlung greifbaren Geschäftswert schaffen.

Die Kosten sind jedoch erheblich. Die Netzwerkkommunikation zwischen Diensten kann ausfallen oder verzögert werden. Was früher eine einfache Datenbanktransaktion war, wird zu Nachrichtenverwaltung, Ereignisverarbeitung, wiederholter Verarbeitung und manchmal vorübergehend unterschiedlichen Datenzuständen. Die Identifizierung des Dienstes, Zugriffskontrolle, zentrale Protokollierung, Metrikensammlung, Alarme, Konfigurationsmanagement, Backup und Versionskompatibilität sind zu lösende Aufgaben. Diese sind keine zusätzlichen Aufgaben, 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 zuerst saubere Stammdaten, zuverlässige Integrationen, konsistente Zugriffsmodelle und messbare Prozesse.

Zuerst muss 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 muss die Datenhoheit untersucht werden. Viele Architekturen werden schwer handhabbar, weil mehrere Dienste dieselben Bestell-, Kunden- oder Lagerdaten direkt ä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 muss die betriebliche Reife realistisch bewertet werden. Gibt es eine einheitliche Protokollierung und Überwachung? Kann eine Geschäftstransaktion über mehrere Systeme hinweg nachverfolgt werden? Werden Geheimnisse und Zugriffe sicher verwaltet? Sind die Test- und Veröffentlichungsprozesse mit Rollback-Möglichkeiten 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 Risiken

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 spezifischer, 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 die Isolierung von Fehlern in einer externen Integration sein. "Es wird irgendwann gut skalieren" ist kein ausreichender Grund, wenn die tägliche Betriebsübersichtlichkeit darunter leidet.

In vielen Fällen ist eine hybride Lösung die beste. Die zentralen Geschäftsprozesse bleiben im modularen Monolithen, während asynchrone, hochvolumige oder intensive externe Systemkommunikationsbereiche als separate Dienste betrieben werden. Dies ist besonders relevant für ERP, Webshop, Lager- und Lieferantensystemintegrationen, wo die Zuverlässigkeit der externen Verbindungen und die 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, Backup, Kapazitätsüberwachung und kontrollierte Veröffentlichungen handhaben. Diese sind nicht nur Infrastrukturaufgaben; sie beeinflussen direkt die Auftragsabwicklung, die Genauigkeit der Lagerdaten und die Präzision der Finanzprozesse.

In der CGAT-Methodik 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 durch die Art und Weise, 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 lohnt es sich zu fragen, nicht welche Architektur moderner klingt, sondern welche Struktur die kritischen Geschäftsprozesse verständlicher, anpassbarer und betreibbarer in einem Jahr macht.