Microservices-Migration: Beispiel aus Unternehmen

Ein Microservices-Migration-Beispiel aus einem Unternehmen ist selten die Geschichte eines mutigen Big-Bang-Rewrites. In der Praxis beginnt die Modernisierung meist dort, wo der Druck am höchsten ist: Releases dauern Wochen, einzelne Fehler legen ganze Funktionen lahm oder das Wachstum eines digitalen Produkts lässt sich mit der bestehenden Architektur nicht mehr wirtschaftlich bedienen. Entscheidend ist nicht, möglichst viele Services zu bauen. Entscheidend ist, fachliche Änderungen schneller und mit kalkulierbarem Betriebsrisiko in Produktion zu bringen.

Für mittelständische Unternehmen ist das besonders relevant. Ein gewachsener Monolith ist nicht automatisch ein Problem. Er wird zum Problem, wenn er Teams voneinander abhängig macht, Skalierung unnötig teuer wird oder jede Anpassung einen unverhältnismäßig großen Test- und Freigabeaufwand auslöst. Dann kann eine schrittweise Migration zu Microservices sinnvoll sein - vorausgesetzt, Architektur, Plattformbetrieb und Organisation werden gemeinsam betrachtet.

Microservices-Migration: Beispiel eines typischen Unternehmens

Stellen wir uns einen mittelständischen B2B-Händler mit eigener E-Commerce-Plattform vor. Das Unternehmen verarbeitet Kundenkonten, Preislogiken, Bestellungen, Lagerbestände, Rechnungen und Schnittstellen zum ERP in einer zentralen Anwendung. Das System ist über Jahre gewachsen, fachlich wertvoll und grundsätzlich stabil. Doch ein neues Kundenportal soll individuelle Sortimente, Echtzeit-Verfügbarkeiten und schnellere Angebotsprozesse ermöglichen.

Die Schwierigkeiten treten nicht bei einzelnen Funktionen auf, sondern an den Abhängigkeiten: Eine Änderung am Preisservice betrifft den gesamten Release. Lastspitzen im Produktkatalog beanspruchen dieselben Ressourcen wie der Checkout. Das ERP reagiert zeitweise langsam und blockiert im ungünstigsten Fall Bestellprozesse. Gleichzeitig können nur wenige Entwickler die kritischen Teile der Anwendung zuverlässig ändern.

Die falsche Reaktion wäre, den Monolithen vollständig zu ersetzen und alle Domänen parallel in Container zu überführen. Ein solches Vorhaben bindet Kapital, verlängert die Zeit bis zum ersten Geschäftsnutzen und schafft häufig zwei instabile Systeme statt eines modernisierten. Der bessere Ansatz ist, die Veränderung an einer fachlich klaren und geschäftlich relevanten Stelle zu beginnen.

In diesem Beispiel eignet sich die Verfügbarkeits- und Bestandsauskunft. Sie wird stark genutzt, muss schnell reagieren und hat eine klar abgrenzbare Aufgabe. Ein eigenständiger Service kann Bestände aus dem ERP übernehmen, aufbereiten und für Shop sowie Kundenportal bereitstellen. Der Monolith bleibt zunächst das führende System für Bestellungen und Abrechnung. Die neue Funktion wird über eine API konsumiert, während das bestehende System schrittweise entlastet wird.

Der Weg von der gewachsenen Anwendung zum ersten Service

Am Anfang steht keine Technologieentscheidung, sondern eine belastbare Bestandsaufnahme. Teams müssen wissen, welche fachlichen Prozesse im Monolithen liegen, welche Datenflüsse existieren und wo echte Engpässe entstehen. Besonders wichtig sind die unsichtbaren Abhängigkeiten: gemeinsame Datenbanktabellen, Batch-Jobs, manuelle Betriebsabläufe und Schnittstellen, deren Fehlerverhalten niemand dokumentiert hat.

Danach wird ein erster Service so ausgewählt, dass er drei Bedingungen erfüllt: Er löst ein konkretes Business-Problem, seine fachliche Verantwortung ist verständlich und seine Auskopplung gefährdet nicht den Kernbetrieb. Das kann die Bestandssynchronisation sein, aber auch Benachrichtigungen, Dokumentengenerierung oder eine Suchfunktion. Ein Service für „Kunden“ ist dagegen oft zu breit gedacht, weil Kundendaten in Vertrieb, Abrechnung und Support unterschiedliche Bedeutungen haben können.

Für den Bestandsservice werden eindeutige Verantwortlichkeiten festgelegt. Er liefert verfügbare Mengen und Zeitstempel, aber er erstellt keine Bestellungen und schreibt keine Rechnungen. Der Service erhält seine Daten über Ereignisse oder kontrollierte Schnittstellen aus dem ERP. Fällt das ERP kurzfristig aus, kann er weiterhin den zuletzt bekannten Bestand ausliefern - sichtbar als potenziell nicht aktueller Wert. Diese Entscheidung ist fachlich und technisch zugleich: Für bestimmte Produkte ist eine verzögerte Anzeige akzeptabel, für knappe Ware möglicherweise nicht.

Die Datenbank bleibt beim jeweiligen Service. Das ist einer der anspruchsvollsten Teile einer Microservices-Migration. Eine gemeinsame Datenbank scheint kurzfristig praktisch, führt aber dazu, dass Services weiterhin implizit gekoppelt bleiben. Eigene Datenhaltung bedeutet nicht, Daten zu duplizieren, ohne Regeln zu definieren. Es bedeutet, Datenhoheit, Aktualisierung und Fehlerfälle bewusst zu gestalten.

Plattformbetrieb entscheidet über den Nutzen

Ein einzelner entkoppelter Service bringt wenig, wenn sein Betrieb mehr manuellen Aufwand erzeugt als der Monolith. Deshalb gehört die Zielplattform vom ersten produktiven Service an zum Migrationsumfang. Containerisierung allein reicht nicht aus. Teams benötigen reproduzierbare Umgebungen, automatisierte Deployments, nachvollziehbare Konfigurationen und eine Sicherheitsbasis, die nicht bei jedem Release neu geprüft werden muss.

In der Praxis umfasst das eine CI/CD-Pipeline mit automatisierten Tests, Sicherheitsprüfungen und nachvollziehbaren Artefakten. Infrastructure as Code stellt sicher, dass Entwicklungs-, Test- und Produktionsumgebungen nicht auseinanderlaufen. Kubernetes kann für Skalierung und standardisierten Betrieb sinnvoll sein, ist aber kein Pflichtprogramm für jedes Unternehmen. Bei wenigen Services und überschaubarer Last kann ein schlankerer Managed-Ansatz wirtschaftlicher sein. Die Plattform muss zur Komplexität des Produkts und zum verfügbaren Betriebsmodell passen.

Ebenso früh braucht der neue Service Observability. Metriken zeigen etwa Antwortzeiten, Fehlerraten und die Verzögerung bei der ERP-Synchronisation. Zentrale Logs helfen, einen fehlgeschlagenen Aufruf über mehrere Komponenten nachzuvollziehen. Traces werden relevant, sobald eine Nutzeranfrage mehrere Services durchläuft. Ohne diese Transparenz verlagert die Migration Fehler lediglich in eine schwerer zu diagnostizierende Landschaft.

Für den B2B-Händler könnte eine produktive Kennzahl lauten: Der Bestandsservice muss 99,9 Prozent seiner Anfragen innerhalb einer definierten Antwortzeit bedienen. Ergänzend wird überwacht, wie alt die Bestandsdaten sind. So erkennt das Betriebsteam nicht nur einen technischen Ausfall, sondern auch eine fachlich kritische Verzögerung in der Datenversorgung.

Was sich nach dem ersten produktiven Schritt verändert

Ist der Bestandsservice stabil im Einsatz, profitiert das Unternehmen unmittelbar. Das Kundenportal kann Verfügbarkeiten anzeigen, ohne den Monolithen bei jeder Anfrage zu belasten. Die Funktion lässt sich unabhängig skalieren. Anpassungen an Caching, Anzeigeformaten oder Synchronisationsintervallen können in einem kleineren Release-Zyklus ausgeliefert werden.

Gleichzeitig entstehen neue Pflichten. Teams müssen Versionen von APIs sauber führen, Verantwortlichkeiten für Störungen klären und Betriebswissen dokumentieren. Ein Fehler in einer verteilten Architektur zeigt sich nicht immer als eindeutiger Ausfall. Er kann als verzögerte Nachricht, doppelt verarbeitete Bestellung oder widersprüchlicher Datenstand auftreten. Deshalb brauchen fachliche Prozesse Mechanismen für Wiederholungen, idempotente Verarbeitung und kontrollierte Kompensation.

Erst wenn der erste Service technisch und organisatorisch funktioniert, folgt die nächste Domäne. Im Beispiel könnten Produktdaten oder die Suche folgen, weil diese Funktionen ebenfalls hohe Last verursachen und sich unabhängig weiterentwickeln lassen. Die Bestellabwicklung bleibt möglicherweise länger im Monolithen, weil sie viele kritische Geschäftsregeln bündelt. Das ist kein Zeichen einer unvollständigen Migration, sondern eine bewusste Priorisierung nach Risiko und Nutzen.

Wann Microservices die falsche Antwort sind

Microservices sind kein Qualitätsmerkmal. Wenn eine Anwendung überschaubar ist, ein Team sie gut beherrscht und Releases zuverlässig laufen, kann ein modular strukturierter Monolith die bessere Lösung sein. Er ist einfacher zu testen, leichter zu betreiben und benötigt weniger verteilte Infrastruktur.

Auch bei einer Migration unter hohem Zeitdruck ist Vorsicht geboten. Wenn ein Unternehmen zunächst Stabilitätsprobleme, unklare Zuständigkeiten oder fehlende Release-Automatisierung lösen muss, sollte es diese Grundlagen priorisieren. Ein Monolith mit sauberer CI/CD-Pipeline, Monitoring und klaren Modulgrenzen kann bereits deutlich schnellere Releases ermöglichen. Microservices verstärken gute Engineering-Praktiken, ersetzen sie aber nicht.

Die Kostenfrage gehört ebenfalls auf den Tisch. Mehr Services bedeuten mehr Pipelines, mehr Laufzeitkomponenten, mehr Monitoring und mehr Sicherheitsfläche. Eine tragfähige Architektur berücksichtigt deshalb FinOps von Beginn an: Ressourcen werden passend dimensioniert, Kosten transparent zugeordnet und Skalierungsregeln regelmäßig mit der tatsächlichen Nutzung abgeglichen.

Eine gelungene Migration erkennt man nicht an der Anzahl der Container, sondern daran, dass fachlich wichtige Änderungen wieder planbar werden. Wer mit einer klar abgegrenzten Domäne startet, den produktiven Betrieb konsequent automatisiert und jede weitere Auskopplung am Geschäftsnutzen misst, modernisiert ohne die Stabilität des laufenden Geschäfts zu verspielen.