Monolith oder Microservices Architektur wählen

Ein neues Kundenportal soll schnell live gehen, eine bestehende SAP-Landschaft muss angebunden werden und perspektivisch sollen KI-gestützte Funktionen hinzukommen. Spätestens an diesem Punkt stellt sich die Architekturfrage: Monolith oder Microservices Architektur? Sie entscheidet nicht über technische Eleganz, sondern darüber, wie schnell ein Produkt weiterentwickelt werden kann, welche Betriebskosten entstehen und wie gut sich geschäftskritische Prozesse langfristig absichern lassen.

Die verbreitete Annahme, Microservices seien grundsätzlich moderner und deshalb die bessere Wahl, führt in vielen Projekten zu unnötiger Komplexität. Umgekehrt kann ein Monolith zum Engpass werden, wenn Organisation, Produkt und Integrationslandschaft deutlich wachsen. Die passende Entscheidung folgt daher dem Geschäftsziel, dem Reifegrad des Teams und den realen Anforderungen an Betrieb und Skalierung.

Monolith oder Microservices Architektur: die Kernunterschiede

Ein Monolith bündelt die Funktionen einer Anwendung in einer gemeinsamen Codebasis und wird typischerweise als eine Einheit bereitgestellt. Benutzerverwaltung, Auftragslogik, Reporting und Schnittstellen laufen innerhalb derselben Anwendung. Das bedeutet nicht, dass der Code unstrukturiert sein muss. Ein modular aufgebauter Monolith kann fachliche Bereiche klar trennen und dennoch einfach zu entwickeln, zu testen und zu betreiben sein.

Microservices teilen eine Anwendung dagegen in mehrere unabhängig deploybare Dienste auf. Jeder Service verantwortet eine abgegrenzte fachliche Fähigkeit, etwa Produktkatalog, Preisberechnung, Dokumentenmanagement oder Benachrichtigungen. Die Dienste kommunizieren über APIs oder Ereignisse und können grundsätzlich separat skaliert und veröffentlicht werden.

Der entscheidende Unterschied liegt damit nicht in der Anzahl der Technologien oder Server, sondern in der Verteilung von Verantwortung. Im Monolithen findet Kommunikation vor allem innerhalb eines Prozesses statt. Bei Microservices wird sie zu Netzwerkkommunikation. Aus einer internen Methode werden API-Verträge, Authentifizierung, Timeouts, Versionsmanagement, Monitoring und Fehlerbehandlung.

Wann ein modularer Monolith wirtschaftlich sinnvoll ist

Für viele neue digitale Produkte ist ein modularer Monolith der vernünftigere Start. Er reduziert die Zahl der beweglichen Teile und bringt das Team schneller zu belastbaren Ergebnissen. Änderungen an mehreren Fachbereichen lassen sich in einem Release ausliefern. Lokale Entwicklung, automatisierte Tests und Fehlersuche bleiben überschaubar.

Das ist besonders sinnvoll, wenn ein Unternehmen zunächst Product-Market-Fit schaffen, interne Prozesse digitalisieren oder ein Kundenportal mit klar umrissenem Funktionsumfang etablieren möchte. Auch bei kleinen bis mittleren Entwicklungsteams ist eine gemeinsame Anwendung oft produktiver. Die organisatorische Aufteilung in dauerhaft eigenständige Produktteams fehlt zu diesem Zeitpunkt häufig noch - und genau diese Aufteilung ist ein wesentlicher Nutzen von Microservices.

Ein gut gestalteter Monolith ist keine technische Sackgasse. Voraussetzung ist, dass fachliche Module sauber geschnitten werden: eigene Verantwortlichkeiten, klar definierte Schnittstellen innerhalb der Anwendung und möglichst geringe direkte Abhängigkeiten. Datenbanktabellen sollten nicht beliebig über Modulgrenzen hinweg genutzt werden. Wer diese Disziplin früh aufbaut, kann später gezielt einzelne Bereiche herauslösen, wenn dafür ein nachvollziehbarer Grund besteht.

Ein weiterer Vorteil: Transaktionen sind einfacher. Wenn beispielsweise eine Bestellung angelegt, ein Auftrag im ERP erzeugt und ein Status gesetzt werden muss, kann ein Monolith diese Schritte in einer gemeinsamen Transaktion steuern. In einer verteilten Architektur müssen Teams mit zeitversetzten Zuständen, Wiederholungen und Kompensationslogik umgehen. Das ist lösbar, aber kein kostenloser technischer Fortschritt.

Wann Microservices ihren Aufwand rechtfertigen

Microservices lohnen sich, wenn eine Anwendung tatsächlich unterschiedliche Veränderungs- und Skalierungsprofile hat. Ein Beispiel ist eine Plattform, auf der ein hochfrequent genutzter Suchdienst unabhängig vom restlichen Backoffice skaliert werden muss. Ein anderes sind Produktbereiche, die von getrennten Teams mit eigenen Release-Zyklen verantwortet werden.

Auch Integrationsanforderungen können die Aufteilung sinnvoll machen. Wenn ein eigenständiger Service Daten aus SAP, CRM, Logistiksystemen und externen Partnerplattformen verarbeitet, kann eine klare Servicegrenze Stabilität schaffen. Änderungen an einer Schnittstelle betreffen dann nicht automatisch das gesamte digitale Produkt. Entscheidend ist, dass der Dienst eine fachlich verständliche Aufgabe erfüllt - nicht nur eine technische Schicht wie „Datenbank-Service“ oder „E-Mail-Service“.

Microservices sind zudem passend, wenn einzelne Komponenten unterschiedliche Verfügbarkeitsanforderungen haben. Muss ein KI-gestützter Dokumentendienst bei hoher Last gedrosselt werden, während Auftragserfassung und Kundenlogin uneingeschränkt weiterlaufen sollen, ist eine Entkopplung wertvoll. Gleiches gilt für Funktionen mit besonderen Compliance- oder Sicherheitsanforderungen, sofern diese Grenzen auch organisatorisch und fachlich tragfähig sind.

Der Gewinn entsteht nicht allein durch unabhängige Deployments. Er entsteht, wenn autonome Teams schneller entscheiden, Veränderungen begrenzt bleiben und kritische Funktionen gezielt skaliert oder abgesichert werden können. Fehlen diese Bedingungen, verlagert sich Komplexität lediglich vom Code in den Betrieb.

Die versteckten Kosten verteilter Systeme

Bei Microservices muss jedes Team mehr als die eigene Business-Logik verantworten. Services brauchen nachvollziehbare Logs, Metriken, Alarmierungen, Zugriffskonzepte, Backups und dokumentierte API-Verträge. Fehler müssen dienstübergreifend analysierbar sein. Ein fehlgeschlagener Prozess darf nicht zu doppelten Aufträgen, verlorenen Nachrichten oder widersprüchlichen Daten führen.

Besonders relevant ist das Datenmanagement. Ein Service sollte seine Daten selbst verantworten. Gemeinsame Datenbanken können kurzfristig bequem wirken, unterlaufen aber die gewünschte Entkopplung. Sobald mehrere Dienste dieselben Tabellen direkt verändern, entstehen schwer kontrollierbare Abhängigkeiten. Datenkonsistenz wird dann zur Architektur- und Prozessfrage, nicht zu einem einfachen Datenbankthema.

Auch die Cloud-Infrastruktur wächst mit. Container-Orchestrierung, CI/CD-Pipelines, Secret Management, API-Gateways und zentrale Observability sind wertvolle Bausteine, erfordern aber Erfahrung und laufende Pflege. Unternehmen sollten diese Kosten in die Wirtschaftlichkeitsrechnung aufnehmen - einschließlich Bereitschaft, Support und Weiterentwicklung. Die Zahl der Deployments kann steigen, nicht automatisch die Liefergeschwindigkeit.

Architekturentscheidung anhand konkreter Fragen treffen

Statt eine Architektur als Grundsatzentscheidung zu behandeln, sollte sie anhand des Produkts bewertet werden. Vier Fragen geben dabei eine verlässliche Orientierung:

• Verändern sich einzelne Fachbereiche deutlich häufiger als andere, und müssen sie unabhängig veröffentlicht werden?
• Gibt es wirklich unterschiedliche Last- oder Verfügbarkeitsprofile, die eine separate Skalierung rechtfertigen?
• Arbeiten mehrere langfristig verantwortliche Teams an klar abgegrenzten Domänen?
• Kann die Organisation den zusätzlichen Betriebsaufwand dauerhaft leisten?

Wer diese Fragen überwiegend mit Nein beantwortet, startet meist besser mit einem modularen Monolithen. Das ist keine Einschränkung der Zukunftsfähigkeit, sondern eine bewusste Investition in Geschwindigkeit, Transparenz und kontrollierbare Kosten.

Fallen mehrere Antworten klar mit Ja aus, lohnt eine vertiefte Domänenanalyse. Dabei werden Geschäftsprozesse, Datenflüsse, Integrationen und Verantwortlichkeiten gemeinsam betrachtet. Häufig zeigt sich, dass nicht die komplette Anwendung in Microservices zerlegt werden muss. Ein hybrider Ansatz kann sinnvoller sein: Das Kernprodukt bleibt ein modularer Monolith, während klar abgegrenzte und besonders lastintensive oder integrationsnahe Funktionen als eigene Services laufen.

Migration: schrittweise statt Komplettumbau

Bestehende Monolithen werden oft vorschnell als Altlast bewertet. Doch ein vollständiger Neubau in Microservices bindet erhebliche Kapazitäten und kann den fachlichen Fortschritt über Monate bremsen. Sinnvoller ist eine schrittweise Modernisierung entlang konkreter Engpässe.

Zuerst sollte sichtbar werden, wo Abhängigkeiten, Release-Risiken und Performance-Probleme tatsächlich entstehen. Danach lässt sich ein fachlich klarer Bereich auswählen, der einen echten Nutzen aus der Entkopplung zieht. Ein Service für Dokumentengenerierung, Suche oder externe Partnerintegration ist häufig ein besserer Kandidat als der zentrale Auftragsprozess mit vielen gemeinsamen Transaktionen.

Wichtig ist, dass die neue Grenze dauerhaft gepflegt wird. Dazu gehören versionierte Schnittstellen, klare Datenverantwortung und ein Betriebsmodell, das Ownership eindeutig zuordnet. Architekturdiagramme allein reichen nicht aus. Die technische Struktur muss im Entwicklungsprozess, in der Qualitätssicherung und im Support gelebt werden.

Für Unternehmen mit komplexen Prozess- und Systemlandschaften beginnt diese Arbeit idealerweise vor der ersten Codezeile. entrecode verbindet dafür Produktstrategie, fachliche Domänenanalyse, UX-Konzept und Cloud-Betrieb, damit Architekturentscheidungen zu den geplanten Geschäftsabläufen passen - nicht zu einem kurzfristigen Technologietrend.

Die beste Architektur ist die, die das nächste sinnvolle Produktziel vereinfacht und den übernächsten Wachstumsschritt nicht blockiert. Wer mit klaren Modulen startet, reale Engpässe misst und Services nur dort ausgliedert, wo sie fachlich und wirtschaftlich tragen, schafft eine technische Grundlage, die mit dem Unternehmen wachsen kann.