Kaum eine Architekturfrage wird so reflexhaft beantwortet wie diese: Ein gewachsener Monolith bremst die Entwicklung, also müssen Microservices her. In der Praxis ist die Antwort differenzierter. Microservices lösen bestimmte Probleme sehr gut — und schaffen andere, die vorher nicht existierten. Dieser Beitrag ordnet ein, wann der Umbau wirtschaftlich sinnvoll ist, wie er risikoarm gelingt und warum ein modularer Monolith oft die bessere Zwischenstation ist.
Das eigentliche Problem: Kopplung, nicht Größe
Der typische Leidensdruck sieht so aus: Jedes Release erfordert einen kompletten Regressionstest, weil eine Änderung an der Rechnungslogik unerwartet die Auftragserfassung bricht. Deployments finden nur noch quartalsweise statt, neue Entwickler brauchen Monate, bis sie produktiv sind. Die Ursache ist aber selten die Tatsache, dass alles in einem System läuft — sondern dass innerhalb dieses Systems alles mit allem verwoben ist: geteilte Datenbanktabellen, direkte Aufrufe quer durch alle Module, keine klaren Zuständigkeitsgrenzen. Wer diese Kopplung nicht versteht und auflöst, verteilt sie mit Microservices nur über das Netzwerk — und erhält einen verteilten Monolithen, das teuerste aller Ergebnisse.
Wann Microservices die richtige Antwort sind
Drei Kriterien sprechen belastbar für den Schnitt in eigenständige Services. Erstens unterschiedliche Änderungsgeschwindigkeit: Ein Webshop-Frontend, das wöchentlich angepasst wird, und eine Lagerlogik, die sich zweimal im Jahr ändert, profitieren von getrennten Release-Zyklen. Zweitens unterschiedliche Lastprofile: Wenn die Preisberechnung zur Saisonspitze das Zwanzigfache der Grundlast verarbeiten muss, lohnt sich unabhängige Skalierung. Drittens mehrere Teams: Ab etwa drei Entwicklungsteams behindern sich Teams in einer gemeinsamen Codebasis messbar. Trifft keines dieser Kriterien zu — was bei vielen mittelständischen Systemen mit einem Team von fünf bis zehn Entwicklern der Fall ist — fehlt dem Umbau die wirtschaftliche Grundlage.
Der risikoarme Weg: das Strangler-Pattern
Wenn der Umbau sinnvoll ist, warnen wir dringend vor dem Big-Bang-Rewrite: Eine Neuentwicklung parallel zum Altsystem bindet über Jahre Kapazität und scheitert häufig an der unterschätzten Fachlogik im Bestand. Bewährt hat sich stattdessen das Strangler-Pattern: Einzelne, fachlich abgegrenzte Funktionen werden nacheinander aus dem Monolithen herausgelöst, als eigenständiger Service neu gebaut und über eine Fassade in Betrieb genommen — das Altsystem schrumpft schrittweise. Die Reihenfolge richtet sich nach Nutzen und Risiko: Zuerst kommt ein Bereich mit hohem Änderungsdruck und überschaubaren Abhängigkeiten, nicht das Herzstück der Buchhaltung.
Ein Beispiel aus der Praxis
Bei einem Logistikdienstleister mit einer über zwölf Jahre gewachsenen Kernanwendung begannen wir mit der Sendungsverfolgung: hoher Änderungsdruck durch Kundenanforderungen, klar abgrenzbare Daten, hohe Leselast. Der neue Service ging nach vier Monaten produktiv; die Antwortzeiten sanken von durchschnittlich 3,2 auf unter 0,4 Sekunden, und das Team konnte Kundenwünsche erstmals innerhalb einer Woche ausliefern statt im Quartalsrelease. Erst nach diesem belegten Erfolg folgten zwei weitere Services. Der verbleibende Monolith läuft weiter — bewusst, denn die Buchhaltungslogik ist stabil und ändert sich selten. Genau diese selektive Modernisierung unterscheidet ein wirtschaftliches Vorhaben von einem ideologischen.
Die unterschätzte Alternative: der modulare Monolith
Für viele Teams ist der erste richtige Schritt kein verteiltes System, sondern Ordnung im bestehenden: klare Modulgrenzen innerhalb der Codebasis, getrennte Datenzugriffe je Fachbereich, definierte Schnittstellen zwischen den Modulen. Ein solcher modularer Monolith beseitigt den größten Schmerz — die unkontrollierte Kopplung — ohne die Betriebskomplexität verteilter Systeme: kein Service-Discovery, keine verteilten Transaktionen, kein Monitoring über Dutzende Instanzen. Und falls später doch einzelne Services nötig werden, sind die Schnittstellen bereits gezogen. Wie wir Architektur-Reviews und Modernisierungen methodisch angehen, beschreibt unsere Seite Dienstleistungen.
Fazit: Architektur folgt dem Geschäftsmodell
Die Frage lautet nicht „Monolith oder Microservices?“, sondern: Welche Teile Ihres Systems müssen sich wie schnell ändern, wie unabhängig skalieren, von wie vielen Teams entwickelt werden? Aus den Antworten ergibt sich der Zuschnitt — manchmal drei Services, manchmal ein aufgeräumter Monolith. Wenn Sie eine nüchterne Einschätzung Ihrer Systemlandschaft wünschen, führen wir gern ein Architektur-Review durch — nehmen Sie Kontakt auf.
