Monolith schrittweise in Microservices zerlegen

Wenn Releases immer riskanter werden, einzelne Änderungen mehrere Fachbereiche betreffen und Skalierung nur noch für das gesamte System möglich ist, wird Modernisierung zur Geschäftsfrage. Einen Monolithen schrittweise in Microservices zu zerlegen, kann diese Engpässe lösen. Es ist jedoch kein Architekturprojekt, das allein durch neue Technologien gelingt, sondern eine Veränderung von Verantwortlichkeiten, Datenflüssen und Betriebsprozessen.

Der häufigste Fehler liegt im Anspruch, den bestehenden Monolithen möglichst schnell vollständig zu ersetzen. Das erhöht Kosten, verlängert die Zeit bis zum sichtbaren Nutzen und schafft parallel zwei komplexe Systemlandschaften. Sinnvoller ist eine kontrollierte Migration: Geschäftlich relevante Funktionen werden zuerst entkoppelt, messbar verbessert und stabil betrieben. Erst dann folgt der nächste Bereich.

Wann eine Aufteilung wirklich sinnvoll ist

Ein Monolith ist nicht automatisch ein Problem. Viele erfolgreiche Anwendungen sind bewusst als zusammenhängendes System aufgebaut, weil Teamgröße, Produktumfang und Änderungsdynamik dies rechtfertigen. Ein gut strukturierter Monolith kann einfacher zu entwickeln, zu testen und zu betreiben sein als zehn schlecht abgegrenzte Services.

Die Aufteilung lohnt sich, wenn konkrete Belastungen entstehen: Teams blockieren sich bei Releases, ein stark genutzter Funktionsbereich muss unabhängig skalieren oder die Erweiterung einer Domäne zieht unverhältnismäßig viele Änderungen in anderen Bereichen nach sich. Auch unterschiedliche Verfügbarkeits- oder Sicherheitsanforderungen können eine Trennung begründen. Beispielsweise darf ein Wartungsfenster für eine Reporting-Funktion nicht den Bestellprozess oder ein Kundenportal beeinträchtigen.

Entscheidend ist nicht die Zahl der Services, sondern die Fähigkeit, Veränderungen sicher und wirtschaftlich umzusetzen. Wer eine überschaubare Anwendung mit stabilen Anforderungen betreibt, benötigt unter Umständen keinen Microservice-Zuschnitt. Wer mehrere digitale Produkte, SAP-Integrationen, externe Partner und schnell wachsende Nutzerzahlen koordiniert, profitiert dagegen häufig von klaren technischen Grenzen.

Monolithen schrittweise in Microservices zerlegen: mit Geschäftswert beginnen

Der erste Schritt ist keine technische Extraktion, sondern eine belastbare Bestandsaufnahme. Welche fachlichen Bereiche existieren? Wo liegen ihre Daten? Welche Schnittstellen werden intern und extern genutzt? Und welche Prozessschritte sind für Umsatz, Servicequalität oder Compliance besonders kritisch?

Dabei hilft es, den Monolithen nicht entlang bestehender Datenbanktabellen oder Programmmodule zu betrachten, sondern entlang fachlicher Verantwortlichkeiten. Ein Produktkatalog, die Preislogik, das Identitätsmanagement und die Auftragsabwicklung haben unterschiedliche Regeln, Lebenszyklen und Nutzergruppen. Daraus können eigenständige Domänen entstehen. Nicht jede Funktion verdient allerdings sofort einen eigenen Service.

Als erster Kandidat eignet sich meist ein Bereich mit drei Eigenschaften: Er hat einen klaren fachlichen Zuschnitt, wenige Abhängigkeiten zum Kern und einen nachvollziehbaren Nutzen. Das kann etwa ein Benachrichtigungsdienst, eine Dokumentenerstellung oder eine Suchfunktion sein. Gerade Funktionen mit hoher Last oder kurzen Änderungszyklen liefern früh einen sichtbaren Effekt, ohne zentrale Transaktionen unnötig zu gefährden.

Die Reihenfolge sollte eine wirtschaftliche Entscheidung sein. Ein Bereich mit sauberer Abgrenzung, aber geringem Nutzen ist nicht zwingend der beste Startpunkt. Umgekehrt kann eine kritische Kernfunktion trotz hoher Priorität zu früh sein, wenn ihre Abhängigkeiten noch nicht verstanden sind. Eine Migrationsroadmap verbindet daher fachlichen Wert, technische Machbarkeit, Betriebsrisiko und verfügbare Teamkapazität.

Fachliche Grenzen vor technische Grenzen setzen

Microservices funktionieren nur dann dauerhaft, wenn sie eine klare Verantwortung tragen. Ein Service für „Kunden“ ist beispielsweise zu breit, wenn er gleichzeitig Stammdaten, Marketingeinwilligungen, Bonitätsprüfung und Vertragsverwaltung abbildet. Besser ist eine Trennung nach fachlichem Kontext und tatsächlicher Entscheidungslogik.

Jeder Service braucht ein eindeutiges Daten- und Verantwortungsmodell: Welche Informationen besitzt er? Welche Regeln setzt er durch? Welche Daten stellt er anderen Systemen bereit? Ohne diese Klarheit wird aus dem Monolithen schnell ein verteiltes System mit denselben Kopplungen - nur mit Netzwerkfehlern, zusätzlichen Deployments und schwerer nachvollziehbaren Ursachen.

Eine gemeinsame Datenbank ist in der Übergangsphase manchmal pragmatisch. Sie darf aber nicht zum dauerhaften Integrationsvertrag werden. Sobald mehrere Services Tabellen direkt schreiben oder lesen, bleiben sie in Wahrheit eng gekoppelt. Das Zielbild sollte deshalb lauten: Ein Service verantwortet seine Daten selbst und stellt anderen Systemen stabile Schnittstellen oder Ereignisse zur Verfügung.

Den Strangler-Ansatz kontrolliert einsetzen

Für die schrittweise Migration hat sich der Strangler-Ansatz bewährt. Neue oder herausgelöste Funktionen werden vor den Monolithen geschaltet, während die bestehende Anwendung weiterläuft. Anfragen gelangen über einen klar definierten Einstiegspunkt entweder an den neuen Service oder an die bisherige Funktion. Mit jeder erfolgreichen Extraktion schrumpft der Verantwortungsbereich des Monolithen.

Das reduziert das Big-Bang-Risiko erheblich. Nutzer müssen nicht auf einen vollständigen Neuaufbau warten, und Teams können Annahmen im produktiven Betrieb prüfen. Voraussetzung ist eine saubere Umschaltstrategie. Feature Flags, klar versionierte APIs und ein Rückfallpfad helfen, wenn ein neuer Service unter Last oder bei Sonderfällen nicht wie erwartet reagiert.

Besonders wichtig ist die Datenmigration. Historische Daten lassen sich selten einfach kopieren und sofort freigeben. Oft ist es sinnvoll, Daten zunächst zu replizieren, Änderungen über Ereignisse abzugleichen und die Schreibverantwortung erst nach einer kontrollierten Übergangsphase zu übergeben. Bei personenbezogenen Daten kommen Anforderungen an Berechtigungen, Aufbewahrung und Löschung hinzu. Diese Regeln müssen in der Zielarchitektur von Beginn an mitgedacht werden.

Schnittstellen, Daten und Transaktionen bewusst gestalten

Im Monolithen laufen viele Prozesse innerhalb einer Datenbanktransaktion. In einer Microservice-Architektur ist das meist weder sinnvoll noch technisch wünschenswert. Ein Auftrag kann dann beispielsweise eine Zahlung anstoßen, Lagerbestand reservieren und eine Versandmeldung auslösen. Nicht jeder Schritt lässt sich atomar zurückrollen.

Stattdessen braucht es fachlich definierte Zustände und Kompensationen. Wird eine Zahlung abgelehnt, wird die Reservierung aufgehoben. Fällt ein nachgelagertes System aus, wird der Vorgang erneut verarbeitet oder gezielt zur Klärung markiert. Diese sogenannten eventual-konsistenten Abläufe verlangen mehr fachliche Präzision, machen Prozesse aber auch widerstandsfähiger gegen temporäre Ausfälle.

APIs sollten dabei nicht die interne Datenstruktur eines Services offenlegen. Andere Teams brauchen verlässliche Verträge, keine Kenntnis über Tabellen, Frameworks oder interne Workflows. Versionierung, eindeutige Fehlerbilder und definierte Service-Level-Erwartungen verhindern, dass jede interne Änderung zu einem Integrationsprojekt wird.

Bei ereignisgetriebenen Integrationen gilt dasselbe. Ein Ereignis wie „Auftrag bestätigt“ beschreibt einen fachlichen Sachverhalt. Es sollte nicht implizit voraussetzen, dass alle Empfänger gleichzeitig verfügbar sind. Idempotente Verarbeitung, nachvollziehbare Ereignis-IDs und eine Strategie für fehlgeschlagene Nachrichten sind Pflicht, nicht Zusatzaufwand.

Betrieb von Anfang an als Architekturthema behandeln

Mit jedem Service steigen die Anforderungen an Deployment, Überwachung und Sicherheitsmanagement. Ein einzelnes Logfile reicht nicht mehr, wenn eine Nutzeranfrage fünf Systeme durchläuft. Teams benötigen zentrale Logs, Metriken und Traces, um Fehlerketten über Servicegrenzen hinweg zu erkennen. Ebenso wichtig sind technische und fachliche Kennzahlen: Antwortzeiten allein zeigen nicht, ob ein Bestellprozess tatsächlich erfolgreich abgeschlossen wird.

Automatisierte Tests und CI/CD-Pipelines sind die operative Grundlage der Migration. Jeder Service muss unabhängig gebaut, getestet und ausgerollt werden können. Contract-Tests prüfen zusätzlich, ob Schnittstellen zwischen Services weiterhin zusammenpassen. Ohne diese Absicherung werden unabhängige Deployments schnell zu einem Risiko.

Auch Sicherheits- und Berechtigungskonzepte verändern sich. Statt einer zentralen Anwendung mit einer Zugangskontrolle entstehen mehrere Angriffspunkte. Einheitliche Identitätsverwaltung, minimale Berechtigungen, verschlüsselte Kommunikation und nachvollziehbare Audit-Protokolle gehören daher in die Plattformstrategie. Für regulierte Branchen und öffentliche Einrichtungen ist das besonders relevant.

Teams und Governance passend organisieren

Architektur folgt in der Praxis oft der Kommunikationsstruktur des Unternehmens. Wenn jede Änderung durch mehrere Abteilungen, externe Dienstleister und zentrale Freigaben wandern muss, werden auch Microservices langsam. Idealerweise trägt ein Team die Verantwortung für einen fachlichen Bereich - von der Entwicklung über den Betrieb bis zur kontinuierlichen Verbesserung.

Das bedeutet nicht, dass jedes Team alle Plattformaufgaben selbst lösen muss. Gemeinsame Standards für Observability, Deployment, Sicherheit und Schnittstellen reduzieren Doppelarbeit. Die Plattform sollte Teams beschleunigen, nicht neue Abstimmungswege schaffen. Dafür braucht es klare Leitplanken: Welche Technologien sind vorgesehen? Wie werden APIs dokumentiert? Wer verantwortet Störungen außerhalb der Geschäftszeiten? Wie lange bleiben alte Schnittstellen unterstützt?

Eine solche Governance ist kein bürokratischer Überbau. Sie sorgt dafür, dass die neue Architektur auch nach dem ersten erfolgreichen Service wartbar bleibt. entrecode begleitet diesen Weg typischerweise von der fachlichen Priorisierung über Architektur und Entwicklung bis zum Cloud-Betrieb, weil die Trennung von Strategie und Betrieb bei gewachsenen Systemen selten funktioniert.

Der nächste sinnvolle Schritt

Starten Sie nicht mit der Frage, wie viele Microservices Ihre Zielarchitektur haben soll. Wählen Sie einen Geschäftsprozess, dessen Probleme heute sichtbar sind, dessen Grenzen verständlich bleiben und dessen Verbesserung messbar ist. Wenn dieser Bereich unabhängig entwickelt, sicher ausgerollt und transparent betrieben werden kann, entsteht eine belastbare Grundlage für die nächste Entscheidung - nicht nur eine neue technische Zeichnung.