Ein Service Mesh ist eine dedizierte Infrastrukturschicht für die Kommunikation zwischen Diensten in einer verteilten Anwendung. Es entkoppelt die Querschnittsthemen der Service-zu-Service-Kommunikation — Verschlüsselung, Authentifizierung, Lastverteilung, Retries, Timeouts, Circuit Breaking, Telemetrie — vom Anwendungscode und verschiebt sie in eine Sidecar-Proxy-Schicht (typischerweise Envoy) oder eine kernel-basierte Datenebene (eBPF wie bei Cilium Service Mesh). Die Konfiguration erfolgt über eine zentrale Control Plane, die Policies, Routen und Sicherheitsregeln deklarativ beschreibt und in die Datenebene verteilt.
Eingesetzt wird ein Service Mesh in Kubernetes-basierten Microservice-Landschaften, in Multi-Cluster- und Multi-Cloud-Topologien sowie in Migrationsszenarien zwischen klassischen VMs und containerisierten Workloads. Bekannte Implementierungen sind Istio (Open Source, Federführung früher von Google, IBM und Lyft), Linkerd (Buoyant), Consul Connect (HashiCorp), Cilium Service Mesh (Isovalent) und kommerziell unterstützte Varianten wie OpenShift Service Mesh oder die mit Azure Service Mesh-Add-ons in AKS angebotenen Distributionen.
Der Einsatzzweck und das gelöste Problem liegen in der Vermeidung doppelter Implementierungen quer durch alle Microservices. Ohne Service Mesh schreiben Teams Bibliotheken für TLS-Setup, Retries, Distributed Tracing und Authentifizierung in jeder Sprache neu — ein klassischer ‚Bibliotheksbaukasten' wie Netflix' Hystrix oder Spring Cloud. Ein Service Mesh hebt diese Verantwortung in eine sprachunabhängige Infrastrukturschicht und liefert konsistentes Verhalten unabhängig von Sprache und Framework.
Historisch wurde der Begriff ‚Service Mesh' durch William Morgan und das Linkerd-Projekt 2017 popularisiert. Linkerd 1.x (basierend auf Scala/Twitter Finagle) wurde 2018 durch das in Rust und Go neu geschriebene Linkerd 2.x ersetzt. Istio entstand 2017 aus einer Kooperation zwischen Google, IBM und Lyft, das den Envoy-Proxy in das Projekt einbrachte. Die Service Mesh Interface (SMI) versuchte 2019, eine herstellerneutrale Schnittstelle zu etablieren, wurde aber in der Praxis nicht von allen Mesh-Projekten gleichermaßen aufgegriffen. Mit dem Aufstieg von eBPF haben sich Architekturen wie Cilium Service Mesh etabliert, die ohne klassische Sidecar-Proxies auskommen und Mesh-Funktionen direkt im Kernel umsetzen.
Eingeführt wurde der Begriff durch die Linkerd-Community, prägende Persönlichkeiten sind William Morgan (Buoyant) sowie Louis Ryan und Sven Mawson (Google) für Istio. Istio wurde in seinen frühen Versionen für die hohe operative Komplexität kritisiert — eine eigene Control-Plane mit Pilot, Mixer, Citadel und Galley als separaten Komponenten, lange Reload-Zeiten, schwierige Upgrades. Mit Istio 1.5 (2020) wurden diese Komponenten zu "istiod" konsolidiert; mit Istio 1.22 (2024) wurde mit "Ambient Mesh" eine sidecarlose Architektur als zweite Datenebene eingeführt. Diese Entwicklung gilt in der Cloud-Native-Community als Lehrbeispiel dafür, wie ein zunächst als "zu komplex" empfundenes Projekt durch konsequente Vereinfachung an Akzeptanz gewinnt.