Service-Mesh-Overhead: Was wir falsch gemacht haben
Wir führten Istio vor allem wegen der Observability ein. Requests wurden spürbar langsamer, wir maßen rund 15ms zusätzliche Latenz pro Hop, und wir rissen das Mesh wieder heraus. Die Hälfte dieser Entscheidung war richtig. Die Messung, die sie ausgelöst hat, war es nicht.
Was wir gemessen haben und was es bedeutete
Ein angemessen mit Ressourcen ausgestatteter Sidecar fügt pro Hop wenige Millisekunden im niedrigen einstelligen Bereich hinzu — Istios eigene veröffentlichte Benchmarks zeigen das seit Jahren. Fünfzehn Millisekunden pro Hop sind nicht der Preis eines Service Mesh; sie sind das Symptom eines ausgehungerten. Unseres war ausgehungert: Wir hatten per Copy-Paste so niedrige CPU-Limits für die Proxys gesetzt, dass die Sidecars unter Last ständig gedrosselt wurden. Wir haben unsere Fehlkonfiguration gebenchmarkt und die Rechnung dafür der Technologie zugeschoben.
Unsere Architektur verstärkte den Effekt. Der Checkout-Pfad reihte ein Dutzend sequenzielle interne Aufrufe aneinander — für sich genommen schon ein Architektur-Smell. Bei realistischen ~2ms pro Hop sind das rund 25ms Mesh-Overhead: spürbar, diskutabel. Bei unseren gedrosselten 15ms waren es ~180ms bei einem Latenzbudget von 200ms, und so wurde „Istio entfernen“ zu einem Vorschlag, der sich leicht verkaufen ließ.
Was wir tatsächlich brauchten
- Distributed Tracing: OpenTelemetry-SDKs in-process — kein Proxy nötig
- Circuit Breaker und Retries: bibliotheksbasiert (Resilience4j)
- Traffic Management: einfache Kubernetes Services reichten bei unserer Größe aus
- mTLS: die einzige echte Mesh-Fähigkeit auf unserer Liste. Wir haben sie bewusst zurückgestellt, mit dokumentierter Entscheidung und einem Termin zur Wiedervorlage — nicht, weil die Verschlüsselung des Service-zu-Service-Traffics „nicht in unserem Threat Model“ gewesen wäre. Zero Trust für internen Traffic ist 2026 Grundvoraussetzung; Aufschub ist akzeptabel, dauerhaftes Abtun nicht.
Die Landschaft von 2026, die wir zunächst ignoriert haben
Die Sidecar-Steuer pro Hop ist nicht mehr das einzige Angebot auf dem Tisch. Istios Ambient Mode — GA seit 2024 — kommt ganz ohne Sidecars aus und erledigt L4 mit einem gemeinsamen ztunnel zu Kosten unterhalb einer Millisekunde, und eBPF-basierte Optionen wie das Mesh von Cilium leisten Ähnliches im Kernel. Wenn Sie mTLS und Traffic Policy brauchen, liefern Sidecar-lose Meshes das zu einem Bruchteil des klassischen Overheads. Prüfen Sie sie, bevor Sie die Kategorie abschreiben — vor allem, sobald Sie Kubernetes in Produktion in nennenswerter Größe betreiben.
Wo wir gelandet sind
- Sidecar-Mesh entfernt; OTel-Tracing und Resilienz per Bibliothek ergänzt — die Latenz kehrte auf die Baseline zurück und der Ressourcenverbrauch des Clusters sank um rund 40%
- Die Wiedervorlage von mTLS ist terminiert, mit Ambient Mode als aussichtsreichstem Kandidaten
Lektion: Führen Sie kein Mesh allein wegen der Observability ein — und lehnen Sie keines auf Basis von Zahlen ab, deren Ursache Sie nicht nachverfolgt haben. Benchmarken Sie ein korrekt konfiguriertes Deployment, beziffern Sie den Overhead ehrlich, und entscheiden Sie dann.
Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers auf dem Pager — damit Geschichten wie diese im Archiv bleiben.