Microservice-Wildwuchs: Die Betriebsrechnung, die niemand budgetiert

Ein Meme macht gerade die Runde: Tony Soprano, zusammengesackt in der Dusche, Cortisol-Anzeige am roten Anschlag — Bildunterschrift „running 700 microservices“. Darunter derselbe Mann, der gelassen eine Zigarre raucht, Cortisol im grünen Bereich: „running 1 big monolith“. Engineers teilen es immer weiter, weil es, wie alle guten Infrastruktur-Memes, ein Postmortem im Kostüm eines Witzes ist. Wir betreiben beide Arten von Systemlandschaft für Kunden — und wir waren es, die von beiden um 3 Uhr nachts alarmiert wurden — hier also die ernsthafte Version: was die 700-Service-Rechnung tatsächlich enthält, warum die Branche still konsolidiert, was das Meme bequemerweise vergisst, und wie Sie Wildwuchs zurückbauen, ohne die Produktion zu zerlegen.

Die Rechnung pro Service, die niemand ins RFC schreibt

Jeder Microservice, den Sie hinzufügen, ist nicht nur Code mit einer API. Er ist eine dauerhafte betriebliche Verbindlichkeit: eine Deploy-Pipeline, ein Dashboard, ein Alert-Set, Log-Routing, IAM-Rollen und Secrets, Dependency-Patching, eine Kostenzeile und ein Platz im Kopf von jemandem im On-Call. Dieser Overhead wächst ungefähr linear mit den Services — die Interaktionen aber nicht. Servicegrenzen sind Netzwerkaufrufe, und Netzwerkaufrufe schlagen fehl, laufen in Timeouts, werden wiederholt und verstärken sich; die Fehlermodi wachsen mit dem Quadrat der Verbindungen, nicht mit der Zahl der Kästchen.

Zuerst spüren Sie es in der Incident Response. In einem Monolithen liefert ein fehlerhafter Request einen Stack Trace. Über 12 Services hinweg ist derselbe Bug eine verteilte Mordermittlung: Request-IDs über Logsysteme hinweg korrelieren, den Hop finden, an dem die Latenz explodiert ist, den Retry-Sturm entdecken, der aus einem Blip einen Ausfall gemacht hat. Ohne ernsthafte Tracing-Disziplin (Metriken, Logs und Traces) skaliert die Mean Time to Resolution mit Ihrer Servicezahl. Das ist das Cortisol im oberen Bild des Memes — gemessen wird es in Schlaf.

Und es gibt auch eine buchstäbliche Rechnung: Compute-Reserve pro Service (jeder Pod für seinen eigenen Peak dimensioniert), Datentransfer zwischen Services und Load-Balancer-Hops, N Kopien jeder Dev-/Staging-Umgebung und das Plattform-Tooling (Service Mesh, Registry, CI-Kapazität), das nur existiert, weil die Teile getrennt sind. In Kostenaudits stellen wir regelmäßig fest, dass die Architektur selbst — nicht irgendeine einzelne Ressource — der größte Posten ist.

Wie Unternehmen bei 700 landen

Fast nie durch Entscheidung; immer durch Default. Microservices wurden zur Prestige-Architektur der Ära 2015-2022 — konferenzgetrieben, lebenslauffreundlich und geadelt durch die Tatsache, dass Netflix und Amazon sie wirklich brauchen. Teams schnitten Services entlang von Entitäten („user-service, order-service, invoice-service…“), nahmen an, die Organisation würde in die Architektur hineinwachsen, und machten aus jedem neuen Feature ein neues Repo, weil das eben das Muster war. Das Ergebnis in mittelgroßen Unternehmen: Servicezahlen eine Größenordnung über der Teamzahl — zwanzig Services pro Engineer sind keine Architektur, sondern ein verteilter Monolith mit Extraschritten und einem Pager-Problem.

Die Korrektur ist real — und öffentlich

Die Branche rudert seit ein paar Jahren zurück, manchmal lautstark: Das bekannteste Beispiel ist Amazons eigenes Prime-Video-Team, das öffentlich beschrieb, wie die Konsolidierung einer verteilten Monitoring-Pipeline in etwas, das faktisch ein Monolith war, die Infrastrukturkosten dieses Workloads um rund 90% senkte. Der „modulare Monolith“ — ein Deployable, streng durchgesetzte interne Modulgrenzen — ist vom Trostpreis zum respektablen Default geworden, genau die Position, die wir in unserem Leitfaden zur Microservices-Einführung vertreten haben: Die meisten Teams sollten dort anfangen und Services erst herauslösen, wenn etwas Konkretes (unabhängige Skalierung, Teamautonomie, eine andere Runtime) die Trennung erzwingt.

Was das Meme falsch versteht

Ehrlicherweise muss man das obere Bild ein wenig in Schutz nehmen. Der zigarrenrauchende Monolith-Besitzer ist entspannt bis zum Deploy-Tag: Ein Deployable bedeutet einen Blast Radius, Deploy-Angst, die mit der Teamgröße wächst, Merge-Konflikte zwischen Teams und das Skalieren der ganzen Anwendung, weil ein Hot Path ausgelastet ist. Monolithen verrotten auch auf ihre eigene Art — Modulgrenzen erodieren, bis alles alles importiert, und dann haben Sie das Schlechteste aus beiden Welten, ohne ein Netzwerk, dem Sie die Schuld geben können. Die eigentliche Lektion des Memes ist nicht „ein großer Monolith“; sie lautet: Die Servicezahl ist ein Preis, den Sie in Stress bezahlen, und Sie sollten davon so wenig kaufen, wie Ihre Organisation tatsächlich braucht. Die vertretbare Heuristik: Ihre Servicezahl sollte Ihrer Teamzahl ähneln — jeder Service Ende-zu-Ende im Besitz genau eines Teams — plus die seltenen echten Ausreißer mit unabhängigen Skalierungs- oder Compliance-Anforderungen.

Das Konsolidierungs-Playbook (sicher zurückbauen)

• 1. Inventarisieren und kartieren. Listen Sie jeden Service mit Owner, Request-Rate, Deploy-Frequenz und Infrastrukturkosten auf; dann kartieren Sie den Call Graph aus den Traces. Services, für die niemand einen Owner nennen kann, sind Ihre ersten Kandidaten — und es wird welche geben.
• 2. Merge-Kandidaten nach Symptom auswählen. Die verlässlichen Signale: Services, die immer zusammen deployt werden (ein verteilter Monolith, der gesteht), geschwätzige Paare, deren Traffic größtenteils aus gegenseitigen Aufrufen besteht, winzige Utility-Services mit einem Request pro Minute und Cluster, die ohnehin einem einzigen Team gehören.
• 3. Als Module zusammenführen, nicht als Big Ball of Mud. Bringen Sie den Code in einen modularen Monolithen und behalten Sie die alten Servicegrenzen als Modulgrenzen — dieselben Interfaces, jetzt Funktionsaufrufe statt Netzwerk-Hops. Sie behalten die Designdisziplin und löschen die Fehlermodi (und die Mesh-Konfiguration).
• 4. Behalten, was sich seinen Platz verdient. Wirklich unabhängige Skalierungsprofile, Isolations-/Compliance-Grenzen, andere Runtimes oder harte Anforderungen an Teamautonomie — diese Services bleiben. Konsolidierung ist Beschneiden, nicht Abriss.
• 5. Das Ergebnis messen. On-Call-Alarme pro Woche, Deploy Lead Time, p95-Latenz und die Infrastrukturrechnung, vorher und nachher. In Konsolidierungen, die wir durchgeführt haben, bewegen sich die ersten beiden am schnellsten — was passt, denn das sind die Cortisol-Metriken.

Häufige Fragen

Wie viele Microservices sollten wir haben?
Eine vertretbare Heuristik: in der Größenordnung Ihrer Teamzahl — jeder Service Ende-zu-Ende im Besitz eines Teams — plus seltene Ausreißer mit wirklich unabhängigen Skalierungs-, Isolations- oder Runtime-Anforderungen. Zwanzig Services pro Engineer sind Wildwuchs, keine Architektur.

Sind Microservices 2026 tot?
Nein. Bei echter Größe — viele Teams, unabhängige Skalierungsdomänen — bleiben sie das richtige Werkzeug. Was endet, sind Microservices als Default; der modulare Monolith ist zum respektablen Ausgangspunkt geworden, mit Herauslösen bei nachgewiesenem Bedarf.

Können wir Microservices ohne Downtime zusammenführen?
Ja — es ist das Strangler Pattern rückwärts: Code hinter denselben Interfaces in das konsolidierte Deployable verschieben, Traffic schrittweise umleiten, den alten Service stilllegen, wenn er verstummt. Langweilig und inkrementell ist genau der Punkt.

Setzt Kubernetes Microservices voraus?
Nein. Ein modularer Monolith läuft problemlos auf Kubernetes — oft besser, weil Sie das Mesh und den Großteil des Networkings zwischen Services loswerden. Siehe unseren Leitfaden Kubernetes in der Praxis.

Fazit

Das Meme ist lustig, weil die Rechnung echt ist: Jeder Service, den Sie betreiben, ist Miete, bezahlt in Betrieb, Incidents und Schlaf. Zahlen Sie sie dort, wo sie Ihnen etwas bringt — unabhängige Skalierung, Teamautonomie, Isolation — und konsolidieren Sie den Rest in sauber abgegrenzte Module. Das Ziel waren nie 700 Services oder 1; es war eine Architektur, deren Cortisol-Anzeige zu Ihrem tatsächlichen Bedarf passt.

Vermuten Sie, dass Sie die Wildwuchs-Steuer zahlen? Unser Kostenoptimierungs-Audit (Festpreis €5.000) quantifiziert den architekturbedingten Teil Ihrer Rechnung, und Managed Operations trägt den Pager so oder so. Ein kostenloser Health Scan sagt Ihnen schnell, ob Konsolidierung auf Ihre Roadmap gehört.