Monolith vs. Microservices: Wann der Monolith in der Industrie gewinnt

Problemstellung, nicht Technologie: In regulierten Industrien wie Bahn, Verteidigung, Fertigung oder Vermessungssystemen beginnt die Architekturfrage nicht bei Kubernetes oder Service-Mesh. Sie beginnt bei Deployments, die offline funktionieren müssen, bei Datenhoheit, bei Upgrade-Fenstern von 2 Stunden pro Quartal und bei Systemen, die auch dann laufen, wenn der Partner-VPN ausfällt. In diesem Umfeld ist “Microservices per Default” oft ein teures Missverständnis. Der Monolith gewinnt häufiger als man denkt – aber nur, wenn er bewusst gebaut wird: mit klaren Domänengrenzen, beobachtbar, skalenfähig und mit vorgesehenen Nahtstellen für spätere Zerlegung.

In diesem Beitrag argumentiere ich mit konkreten Trade-offs aus Projekten, die in Produktion laufen: Fleet Intelligence im Bahnsektor, skalierbare Plattformen für Vermessungssysteme, ML-gestützte Qualitätskontrolle in der Fertigung und eine cloudbasierte Trainingsplattform für die Luftfahrt. Keiner dieser Fälle war ein “Greenfield mit 15 crossfunktionalen Teams”. Alle waren getrieben von Souveränität, Betriebssicherheit und langen Lebenszyklen.

Wann der Monolith gewinnt

Es gibt eine Reihe wiederkehrender Situationen, in denen ein Monolith gegenüber Microservices klare operative, ökonomische oder regulatorische Vorteile hat:

1) Air-Gap, On-Prem, DSGVO-strikte Umgebung

  • Betrieb: Keine oder stark eingeschränkte Cloud-Konnektivität, Updates via Offline-Medium, Zertifikatsrotation durch lokale PKI.

  • Operative Komplexität: Jeder zusätzliche Deployable erhöht den Koordinations- und Audit-Aufwand (Change Requests, Freigaben, Prüfprotokolle).

  • Monolith-Vorteil: Ein Release-Artefakt, ein Audit-Trail, ein Rollback-Pfad. Packaging als einzelner OCI-Container oder nativer Service (systemd, MSI) mit reproduzierbarem Build.

2) Kleine bis mittelgroße Teams, klare Domäne, hohe Zuverlässigkeitsanforderung

  • Team-Topologie: 1–3 Teams, gemeinsame Codebasis, geringe On-Call-Kapazität.

  • SLOs: MTTR wichtig, Downtime-Fenster planbar.

  • Monolith-Vorteil: Ein Prozessraum, gemeinsame Transaktionsgrenzen, Debugging ohne verteilte Kausalität. Fehleranalyse und Patching schneller.

3) Datenlokalität und strikte Datenhoheit

  • Datenklassifizierung: Personenbezug, Betriebsgeheimnisse, Exportrestriktionen.

  • Datenflüsse: So wenig Kopien wie möglich, klarer Audit-Pfad.

  • Monolith-Vorteil: Einheitliche Persistenz, transaktionale Integrität ohne verteilte 2PC-Patterns, weniger Daten-Duplikate über Services hinweg.

4) Geringe Domänenvolatilität, hohe Interface-Stabilität

  • Änderungsprofil: Geschäftslogik ändert sich moderat, Schnittstellen sind langlebig.

  • Monolith-Vorteil: Kaum Druck zur Entkopplung per Netzwerkgrenzen. Interne Modulgrenzen reichen, geringere Latenzen.

5) Echtzeitnahe Verarbeitung mit deterministischen Latenzanforderungen

  • Pipeline: Sensorik → Vorverarbeitung → Inferenz → Aktorik.

  • Monolith-Vorteil: Keine Netzwerklatenzen zwischen kritischen Pfaden, geringere Jitter, bessere Kontrolle über Scheduling.

Diese Vorteile sind keine Einladung zum “Big Ball of Mud”. Der Unterschied zwischen produktivem Monolithen und spätem Sanierungsfall liegt in der internen Architektursauberkeit.

Der “gute Monolith”: Architekturmuster

Ein wartbarer Monolith ist konkret gestaltet, nicht zufällig gewachsen. Wichtige Muster:

  • Bounded Contexts explizit: Modulgrenzen entlang fachlicher Kontexte. Keine “Cross-Cutting” Utility-Module, die alles referenziert. Abhängigkeiten strikt einseitig.
  • Ports/Adapters: Domäne spricht in Ports, Außenwelt hängt an Adaptern (UI, Persistenz, Feldbus, REST, gRPC). So lassen sich Adapter später isoliert extrahieren.
  • Seams für Extraktion: Interne RPC-Interfaces definieren (z. B. über in-proc Interfaces), die später über IPC/Netzwerk gehoben werden können, ohne die Domäne zu verändern.
  • Transaktionen bewusst setzen: Transaktionale Grenzen an Domänengrenzen, nicht an UI-Events. Keine verteilten Sagas erzwingen, wenn eine lokale ACID-Transaktion ausreicht.
  • Feature-Toggles und Readiness: Verhalten zur Laufzeit schaltbar; so lassen sich riskante Features im Feld deaktivieren, ohne Re-Deploy.
  • Observability in einem Prozessraum: Strukturierte Logs, Metriken mit klaren Namensräumen pro Modul, korrelierte Trace-IDs auch ohne verteiltes Tracing.

Trade-offs gegenüber Microservices

Was gewinnt man nicht, wenn man Services vermeidet?

  • Unabhängige Skalierung: Feingranulare Skalierung pro Domäne fällt weg. Für viele On-Prem-Workloads ist horizontale Gesamt-Skalierung ausreichend (mehr Knoten, gleicher Build).
  • Teamautonomie: Microservices erlauben autonome Deployments. In kleinen Teams ist die Koordination über ein Monorepo oft effizienter als Schnittstellenverhandlungen im Netzwerk.
  • Heterogene Stacks pro Service: Ein Monolith zwingt stärker zur Stack-Disziplin. Dafür sinken Build-/Deploy-Kosten und Sicherheitsoberfläche.

Ökonomik: Betriebs- und Entwicklungskosten

  • CI/CD-Kosten: Ein Artefakt, ein Pipeline-Set. Keine 20 Pipelines mit je eigenem Security-Scannen und Dependency-Management.
  • Sicherheitsoberfläche: Patchen von CVEs in einem Runtime-Image vs. Dutzenden. Weniger Zertifikate, weniger mTLS-Konfiguration.
  • Testbarkeit: Integrierte Integrationstests ohne aufwendige Environments, weniger Flakiness durch Netzwerk.
  • On-Prem-Upgrades: Ein koordinierter Rollout im Wartungsfenster ist einfacher als ein orchestrierter Multi-Service-Upgrade mit Versionsmatrizen.

Einwände, die in der Praxis oft überschätzt werden

  • “Wir brauchen Microservices für Skalierung.” In vielen industriellen Szenarien liegt die Bottleneck im IO (Datenaufnahme) oder in rechenintensiven Modulen (Inferenz). Beides lässt sich im Monolithen über Worker-Pools, Partitionierung und asynchrone Queues skalieren. Man skaliert das ganze Artefakt, aber häufig ist das operativ akzeptabel.
  • “Teams können nicht parallel arbeiten.” Saubere Modulgrenzen, Code-Owner-Regeln und ein Monorepo mit gutem Branching-Modell erlauben parallele Arbeit. Konflikte entstehen eher aus schwammigen Domänengrenzen als aus fehlender Service-Grenze.
  • “Microservices sind moderner.” Operative Reife ist kein Mode-Thema. Wer On-Prem 15 Services mit eigenem State betreibt, baut sich häufig ein hausinternes Cloud-Team – ohne die Ökonomie einer echten Cloud.

Fallvignetten aus Projekten

1) Bahn: Fleet Intelligence
Problem: Erfassung und Verarbeitung von Telemetrie aus Fahrzeugflotten, On-Prem-Auswertung, geringe Wartungsfenster, hohe Verfügbarkeit, Datenhoheit.
Entscheidung: Monolith mit klar getrennten Modulen: Ingestion (Protokoll-Adapter), Normalisierung, Regel-Engine, Persistenz, API/UI. Event-Log intern per Append-Only-Store, asynchrones Processing via internen Queues.
Trade-off: Keine feingranulare unabhängige Skalierung – akzeptabel, da Workload vorhersagbar. Gewonnen: Einfaches Offline-Update, deterministische Latenzen, 1-Audit-Trail.