Modernisierung ohne Wachstumsstopp: wie geht man vom Monolithen zu einer skalierbaren Architektur über?

Viele Unternehmen kommen an den Punkt, an dem der Monolith „noch funktioniert“, aber jedes weitere Feature immer mehr kostet: Releases sind stressig, Änderungen „beißen“ sich gegenseitig und Skalierung bedeutet, dass man dem gesamten System Ressourcen hinzufügt, statt dem, was tatsächlich der Engpass ist. Die gute Nachricht ist: Man kann modernisieren, ohne das Geschäft abzuschalten – vorausgesetzt, dass man sich nicht für den Ansatz „wir fangen bei null an“, sondern für einen inkrementellen Ansatz auf Basis bewährter Muster entscheidet.

Unten finden Sie einen Leitfaden, der Sie durch diesen Prozess führt: von der Entscheidung „brauchen wir wirklich Microservices?“ über Migrationsmuster (Strangler Fig, Branch by Abstraction, Expand & Contract) bis hin zur Arbeit mit Daten, Observability und Deployments ohne Ausfallzeiten.

Was blockiert das Wachstum im Monolithen wirklich?

Ein Monolith ist nicht per Definition „schlecht“. Das Problem beginnt dann, wenn die Änderungskosten schneller wachsen als der Wert der Änderung. Die häufigsten Symptome sind:

• Die Liefergeschwindigkeit sinkt (lange Lead Times, schwierige Regressionstests, wachsender „Time‑to‑Production“).
• Hohes Ausroll‑Risiko: eine Änderung kann das halbe System umwerfen.
• Skalierung „alles auf einmal“: um ein Modul abzufangen, müssen Sie den gesamten Monolithen skalieren.
• Starke Datenkopplung: eine gemeinsame Datenbank und gemeinsame Transaktionen erschweren die Aufteilung der Verantwortlichkeiten.
• Fehlende Transparenz: niemand kann beantworten, „was passiert, wenn wir X ändern?“.

In der Praxis verfolgt die Modernisierung zwei parallele Ziele:

• die Roadmap weiterhin zu liefern,
• die Änderungskosten im Zeitverlauf zu senken.

„Skalierbare Architektur“ bedeutet nicht immer Microservices

Bevor Sie die Entscheidung für eine Microservices‑Architektur treffen, präzisieren Sie, was genau skalieren soll – das Team, die Deployments, der Traffic, die Zuverlässigkeit oder vielleicht alles zusammen.
Martin Fowler und James Lewis beschreiben Microservices als eine Menge von Eigenschaften (unter anderem Organisation rund um Business‑Capabilities, Automatisierung, Design für Ausfälle, dezentrale Daten). Es handelt sich nicht um eine „Technologie“, sondern um eine Art und Weise, ein System zu bauen und zu betreiben.

In der Praxis gewinnt oft eine schrittweise Strategie:

• Modularer Monolith (ein guter erster Schritt): Sie ordnen Modulgrenzen und Abhängigkeiten, behalten aber ein einziges Deployment.
• SOA / Domänen‑Services: Sie extrahieren die wichtigsten Teile der Domäne in separate Services.
• Microservices dort, wo es sinnvoll ist (z. B. Module mit anderem Änderungsrhythmus, anderem SLA, anderem Lastprofil).

Fundament: inkrementelle Modernisierung (Strangler Fig) statt „Big‑Bang‑Rewrite“

Das sicherste Migrationsmuster für einen Monolithen ist Strangler Fig: Die neue Architektur „wächst um“ die alte herum und fängt nach und nach Traffic und Funktionen ab, bis die alte Komponente abgeschaltet werden kann.
Das Wesentliche ist:

• Änderungen können stattfinden, ohne dass die Nutzer davon wissen.
• Sie liefern unterwegs Mehrwert (und nicht nur „am Ende“).
• Sie verteilen das Risiko auf kleine Schritte.

Azure beschreibt eine typische Umsetzung mit einer Fassade/einem Proxy, der Anfragen an den alten Monolithen oder an neue Services weiterleitet – je nachdem, was bereits migriert wurde.
AWS betont hingegen, dass das Ziel dieses Ansatzes die Minimierung von Risiko und Störungen im Geschäftsbetrieb ist.

Migrationsplan „ohne Wachstumsstopp“ – 10 Schritte, die funktionieren

1. Definition von Erfolg (Metriken + SLO)

Ohne Kennzahlen kann Modernisierung schnell zu einem „Projekt für Architekten“ werden. Stellen Sie sicher, dass Sie festlegen:

• DORA / Four Keys (Deployment‑Häufigkeit, Durchlaufzeit für Änderungen, Fehlerquote bei Änderungen, Zeit zur Wiederherstellung des Dienstes).
• SLO/SLI + Error Budget: wie viel Fehler/Ausfallzeit Sie in einem Zeitraum „verbrauchen“ können, bevor Sie Deployments verlangsamen und sich auf Stabilität konzentrieren.

2. Domäne und Grenzen abbilden (Bounded Contexts)

Das Zerlegen des Systems nach technischen Schichten endet oft in Problemen und erschwert die Softwareentwicklung. Ein besserer Ansatz ist die Aufteilung nach Domäne und Geschäftssprache, im Sinne von Domain‑Driven Design (DDD). Das ist eine Art, Software zu entwickeln, die sich auf den tatsächlichen Geschäftsbereich oder das Problem konzentriert, das die Anwendung lösen soll – und nicht auf Technologie oder Architektur an sich.
Microsoft definiert DDD als einen Bereich (Grenze), in dem ein konsistentes Domänenmodell gilt, und empfiehlt, Funktionen dort zu gruppieren, wo dieses Modell gemeinsam ist. Martin Fowler betont, dass DDD hilft, mit umfangreichen Modellen umzugehen, indem sie in sogenannte Bounded Contexts aufgeteilt und klare Beziehungen zwischen ihnen definiert werden.
Das Ergebnis dieses Ansatzes? Es entstehen sinnvoll abgegrenzte Module oder Services, und gleichzeitig werden „zufällige Microservices“ vermieden.

3. Den „ersten Service“ strategisch auswählen (Thin Slice)

Der erste ausgelagerte Service sollte ein kleiner, aber vollständiger vertikaler Ausschnitt der Funktionalität sein, der drei Bedingungen erfüllt:

• Er liefert echten geschäftlichen Mehrwert – die Kosten der Auslagerung lassen sich leicht rechtfertigen, weil er ein konkretes, wichtiges Problem löst.
• Er hat klar definierte Daten – es ist klar, welche Daten er benötigt und wo die Verantwortungsgrenze zum restlichen System verläuft.
• Er erlebt hohe Reibung im Monolithen – er wird häufig geändert, fällt oft aus oder bremst die Entwicklung anderer Teile.

Eine solche Auswahl minimiert das Risiko und reduziert gleichzeitig sofort die Last des Monolithen.

4. Eine Schicht zur Abfangung des Traffics einziehen (Fassade / Gateway / Routing)

Strangler Fig beginnt in der Regel mit einer Komponente, die:

• den Traffic terminiert (z. B. HTTP) – sie nimmt alle eingehenden Anfragen der Clients entgegen,
• Anfragen an den Monolithen oder den neuen Service routet – anfangs geht der Großteil an den Monolithen und ausgewählte Pfade an neue Komponenten,
• schrittweises Umschalten von Endpunkten ermöglicht – nach und nach verlagern Sie einzelne Funktionsbereiche vom Monolithen auf neue Services, wobei Sie nur die Routing‑Konfiguration anpassen statt das gesamte System auf einmal.

So vermeiden Sie einen „großen Schalter“ an einem Tag und können das System in kleinen, kontrollierten Schritten weiterentwickeln.

5. Sichere Deployments sicherstellen: Feature Flags + gestufte Änderungen

Zwei Techniken, die bei einer Systemmigration oft entscheidend sind:

• Feature Toggles (Feature Flags) – sie ermöglichen es, das Verhalten des Systems ohne erneutes Deployment zu ändern: Sie können unfertige Funktionen verstecken, neuen Code nur für einen Teil des Traffics (z. B. einen Prozentsatz der Nutzer) aktivieren und Änderungen „live“ testen, müssen aber die wachsende Komplexität der Konfiguration bewusst im Blick behalten.
• Branch by Abstraction – ermöglicht große Änderungen in mehreren Schritten: Sie führen eine gemeinsame Abstraktion (Interface/Schicht) ein, unter der Sie die alte und die neue Implementierung austauschen, häufig in Kombination mit Flags, um zu steuern, wann welche Version genutzt wird.

In der Praxis erlauben beide Ansätze, das System „von innen“ zu modernisieren, ohne den Hauptzweig des Codes (Trunk) zu blockieren und ohne die Auslieferung laufender Funktionalitäten anzuhalten.

6. Observability, bevor Sie das System verteilen (Logs, Metriken, Tracing)

Bevor Sie beginnen, den Monolithen in mehrere Services zu zerlegen, sorgen Sie für solide Observability, denn ohne Telemetrie wird Debugging in einem verteilten System zum „Stochern im Dunkeln“.
OpenTelemetry ist heute de facto Standard für die Instrumentierung und den Export von Logs, Metriken und Traces in herstellerneutraler Weise.
Ein Minimal‑Set vor einer größeren Dekomposition ist:

• Gemeinsame Correlation IDs – derselbe Identifikator durchläuft alle Services, was die Rekonstruktion des vollständigen Request‑Pfads ermöglicht.
• Verteiltes Tracing kritischer Pfade (z. B. Checkout, Zahlung, Login) – Sie sehen genau, wo Verzögerungen und Fehler auftreten.
• SLO‑Dashboards und dazugehörige Alerts auf Basis des Error Budgets – Sie definieren das erwartete Qualitätsniveau, messen dessen Einhaltung und erhalten ein Signal, wenn das System das Fehlerbudget „verbraucht“.

7. Datenstrategie: „zuerst Koexistenz, dann Trennung“

Der schwierigste Teil einer Migration sind fast immer die Daten.
Ein sicherer Pfad:

• Stufe 1: der neue Service nutzt Daten über den Monolithen oder über eine kontrollierte Zugriffsschicht,
• Stufe 2: Sie führen schrittweise Schema‑ und Client‑Änderungen ein,
• Stufe 3: Sie trennen Verantwortlichkeiten und (perspektivisch) Daten.

Für Schema‑Änderungen und Migrationen bewährt sich Expand and Contract (zuerst „erweitern“, dann „umschalten“, schließlich „aufräumen“).

8. Konsistenz zwischen Services: Outbox, CDC und Sagas statt 2PC

In Microservices ergibt eine „globale Transaktion für alles“ keinen Sinn mehr, daher kommen andere Ansätze zum Einsatz. Drei praktische Muster sind in der Regel:

• Saga – zerlegt einen Prozess in eine Reihe lokaler Transaktionen in verschiedenen Services mit kompensierenden Schritten statt eines globalen Rollbacks.
• Event Sourcing – der Systemzustand wird aus einer Folge von Events aufgebaut, was das Wiederherstellen und Korrigieren von Fehlerfolgen erleichtert.
• CQRS + asynchrone Nachrichten – trennt den schreibenden vom lesenden Teil und akzeptiert eventual consistency.

Kurz gesagt: Statt künstlich eine einzige „verteilte Transaktion“ über viele Services zu erzwingen, entwerfen Sie bewusst eventual consistency dort, wo das Business kurzfristige Datenabweichungen akzeptieren kann.

9. Deployments ohne Ausfallzeiten: Blue/Green + Canary + schneller Rollback

Um ein System zu modernisieren, ohne sein Wachstum zu bremsen, brauchen Sie die Möglichkeit, häufig und sicher zu deployen. Der Blue/Green‑Ansatz bedeutet, zwei parallele Umgebungsstände (alt und neu) zu betreiben und den gesamten Traffic in einem Schritt umzuschalten, was einen sofortigen Rollback ermöglicht, wenn etwas schiefgeht.
Der Canary‑Ansatz erlaubt es, eine neue Version schrittweise auszurollen – zunächst auf einen kleinen Teil des Traffics, dann auf mehr und mehr – bei genauer Beobachtung technischer und geschäftlicher Metriken.
In Kubernetes‑basierten Umgebungen sind kontrollierte Rollouts in Deployments entscheidend, basierend auf Replikas und schrittweisen Updates. So lassen sich sowohl Blue/Green‑ähnliche als auch Canary‑Szenarien umsetzen und das Risiko jedes Deployments reduzieren.

10. Eine „Definition of Done“, die verhindert, dass die Migration ewig dauert

Betrachten Sie jeden Migrationsausschnitt erst dann als abgeschlossen, wenn:

• Produktiv‑Traffic tatsächlich durch den neuen Pfad läuft und der alte im täglichen Betrieb nicht mehr benötigt wird.
• Sie sinnvolles Monitoring und SLOs für den neuen Service haben, sodass Sie Verfügbarkeit, Fehler und Performance sehen.
• Der Monolith verschlankt wurde – unnötiger Code und Abhängigkeiten entfernt wurden, statt nur einen neuen Service „daneben zu kleben“.
• Das Team klar weiß, wer Eigentümer des Moduls/Services ist, wie es weiterentwickelt werden soll und wo Probleme gemeldet werden.

Das klingt banal, aber gerade das Fehlen eines solchen „Abschlusses“ führt dazu, dass Migration zu einem nie endenden Projekt wird und technische Ruinen hinterlässt.

Die häufigsten Fallen (und wie man sie vermeidet)

„Wir machen Microservices, weil es alle machen“

Ohne Automatisierung und sinnvolle Observability vervielfachen Microservices nur die Probleme. Statt einem Trend hinterherzulaufen, kehren Sie zu konkreten Eigenschaften und geschäftlichen Anforderungen zurück.

Aufteilung nach technischen Schichten

Dies endet mit einem „Datenbank‑Microservice“ und einem „UI‑Microservice“, also starken Abhängigkeiten und fehlender Autonomie. Teilen Sie das System entlang der Domäne und der Bounded Contexts, nicht entlang der Technologie.

Verteilung der Daten ohne Konsistenzplan

Bevor Sie die Datenbank aufteilen, bereiten Sie Outbox/CDC/Saga‑Mechanismen vor und entwerfen Sie bewusst Fehlerszenarien sowie das Verhalten bei Dateninkonsistenzen.

Fehlender Mechanismus zur Risikosteuerung

Führen Sie DORA‑Metriken sowie SLOs mit Error Budget ein, damit Liefergeschwindigkeit und Systemstabilität in einer gemeinsamen Sprache gemessen werden und Sie Risiken bewusst steuern können.

Praktische „Mini‑Checkliste“ für den Start (zum Kopieren in Jira)

Dies kann ein Abschnitt „Checkliste“ zum Start der Modernisierung sein:

• Basis‑DORA‑Metriken erhoben und konkrete Ziele für die nächsten 3 Monate definiert (z. B. Deployment‑Frequenz, Durchlaufzeit von Änderungen).
• 1–2 SLOs für eine kritische User Journey definiert (z. B. Registrierung, Kauf, Zahlung), um das zu messen, was der Nutzer wirklich erlebt.
• Bounded Contexts und Domänen‑Prioritäten abgebildet – es ist klar, welche Geschäftsbereiche zuerst migriert werden.
• Erster Thin Slice ausgewählt und ein Strangler‑Fig‑Plan vorbereitet (Routing des Traffics zwischen Monolith und neuem Service).
• Funktionierende Feature Flags plus ein Plan zum regelmäßigen Aufräumen alter Flags, um keine Komplexität anzusammeln.
• Observability: verteiltes Tracing für kritische Pfade, Dashboards und Alerts, die an SLOs und nicht nur an Infrastruktur ausgerichtet sind.
• Datenstrategie im Expand‑&‑Contract‑Modell plus Entscheidung, ob Outbox, CDC oder beides verwendet wird.
• Deployment‑Strategie: klar beschriebene Canary‑ und/oder Blue/Green‑Szenarien mitsamt Rollback‑Prozedur, damit jedes Deployment einen sicheren Rückweg hat.

Wo passt in all das ein Technologiepartner?

Ein Technologiepartner ist der fehlende „Verstärker“, der Modernisierung parallel zur Produktentwicklung ermöglicht – ohne das Kernteam zu überlasten.
In der Praxis bedeutet dies in der Regel:

• Einen Architekten / ein Architekturteam, das hilft, Domänengrenzen zu setzen, die Zielarchitektur (Bounded Contexts, Daten, Integrationen) zu entwerfen und einen realistischen Migrationsplan statt eines allgemeinen „wir gehen auf Microservices“ zu erstellen.
• DevOps / Cloud, die dafür sorgen, dass Deployments, Infrastruktur und Observability „langweilig“ werden: automatisierte CI/CD‑Pipelines, IaC, Monitoring, Alerts und Sicherheit in der Cloud.
• Eine Praxis, Änderungen in kleinen Schritten zu liefern – Unterstützung bei Strangler Fig, Feature Flags, Testautomatisierung und Rollouts, damit Änderungen iterativ mit kontrolliertem Risiko statt im „Big‑Bang‑Modus“ eingeführt werden.

Unternehmen wie Altimi beschreiben ein solches Unterstützungsmodell genau in den Bereichen DevOps/CI/CD, Cloud‑Architektur, Managed Services und Modernisierung von Systemen, ohne laufende Prozesse und Produktentwicklung zu stören.