Die ehrliche Antwort · Stand: Juli 2026

Brauche ich ein Service Mesh?

Kurzfassung: wahrscheinlich später, vielleicht jetzt, möglicherweise nie. Ein Service Mesh ist Infrastruktur mit laufenden Kosten in Betrieb und Komplexität. Es lohnt sich genau dann, wenn es ein reales Problem löst, das Bordmittel nicht mehr lösen. Hier ist die Abgrenzung ohne Verkaufsdruck.

Nein, wenn ...

... ihr einen produktiven Cluster betreibt, den ein Team verantwortet, und niemand euch Compliance-Nachweise abverlangt. Gateway API am Ingress, NetworkPolicies als Default-Deny und TLS-Terminierung am Ingress decken dieses Setup sauber ab.
... euer Hauptmotiv Observability ist. Metriken, Logs und Traces bekommt ihr mit OpenTelemetry-Instrumentierung deutlich billiger als mit einer neuen Netzwerkschicht.
... mTLS zwischen Services „irgendwann mal gut wäre", aber weder Audit noch Kunde noch Vertrag es heute verlangen. Ein Wunsch ohne Frist rechtfertigt keine neue Betriebsplattform.
... es kein Platform-Team gibt, das Upgrades, Policies und Incidents dauerhaft verantworten würde. Ein Mesh ohne Owner degradiert zur unbeaufsichtigten Infrastruktur im kritischsten Pfad, den ihr habt.
... ihr das Mesh wollt, weil es „Stand der Technik" ist. Verbreitung ist kein Bedarf. Ein späteres Nachrüsten ist jederzeit möglich und deutlich billiger als ein verfrühter Rollout samt Rückbau.

Ja, wenn ...

... Dienst-zu-Dienst-Verkehr nachweisbar verschlüsselt und authentifiziert sein muss (mTLS als Pflicht aus Audit, Vertrag oder Policy). Das per Hand über alle Services zu bauen und aktuell zu halten ist teurer und brüchiger als jedes Mesh.
... ihr unter harter Regulierung steht (NIS2, DORA, KRITIS, BaFin-Umfeld). Die etablierte Umsetzung der Anforderungen aus BSI APP.4.4 ist mTLS STRICT plus Default-Deny-Policies, und Auditoren erwarten laufende Nachweise statt Architektur-Folien.
... sich mehrere Teams oder Mandanten einen Cluster teilen und Isolation mehr braucht als Namespaces: Workload-Identitäten und feingranulare, zentral durchgesetzte Autorisierung.
... ihr L7-Steuerung als Plattform-Feature braucht: Canary-Releases, Traffic-Shifting und Autorisierung zwischen Services, zentral für viele Teams statt einzeln je Service gebaut.
... ihr eine Cluster-Flotte betreibt und Cluster-übergreifenden Trust, Failover und einheitliche Policies braucht. Ab dieser Größe ist die Frage nicht ob, sondern welches Mesh und mit welcher Architektur.

Die Grauzone

Dazwischen liegt der Normalfall: zwei bis fünf Cluster, mTLS „gewünscht", ein kleines Platform-Team, erste interne Mandanten. Hier entscheidet die Abwägung:

Wächst der Druck oder ist er einmalig? Eine einzelne Kundenanforderung lässt sich oft am Ingress lösen; ein Zertifizierungs-Fahrplan nicht.
Was kostet der Verzicht? Wenn Teams anfangen, mTLS, Retries und AuthZ selbst in Services zu bauen, zahlt ihr das Mesh bereits, nur verteilt und ohne die Vorteile.
Was ist schon da? Läuft Cilium als CNI, ist sidecarloses L4-mTLS ein kleiner Schritt statt eines Plattform-Projekts. Ein vorhandenes, gepflegtes Ingress-Setup senkt den Druck; ein Wildwuchs erhöht ihn.
Kann das Team es tragen? Die ehrlichste aller Fragen. Wenn nein, ist die Antwort nicht „kein Mesh für immer", sondern erst Ownership, dann Mesh.

Für genau diese Abwägung ist der Wizard gebaut: sieben Situationsfragen, eine begründete Empfehlung, inklusive der Option „Kein Service Mesh (heute)".

Die Entscheidung in 7 Fragen

Zum Weiterlesen

Die Substanz hinter den Kriterien steht in der Langform: Die 7 Entscheidungs-Dimensionen. Detail-Duelle der Kandidaten liefert die Schwester-Domain service-mesh-vergleich.de.

Und falls die Antwort „Ja" lautet, dein Setup reguliert oder mandantenfähig ist und die Wahl auf Istio fällt: Für dieses Profil gibt es das Service Mesh Readiness Assessment der spezialisierten Unit istio-consulting.de, mit sichtbarem Festpreis.