Ein Service Mesh ist eine eigene Infrastruktur-Ebene, die die gesamte Kommunikation zwischen Microservices kontrolliert: Routing, Lastverteilung, Verschlüsselung, Ausfallsicherheit und Beobachtbarkeit werden nicht mehr in jede Anwendung eingebaut, sondern zentral zur Verfügung gestellt. Damit wird das Netzwerk zur Plattform — bekannt geworden durch Projekte wie Istio, Linkerd und Consul.
Das Problem, das Service Mesh löst
In einer Microservice-Architektur muss jeder Dienst eigentlich selbst wissen, wie er andere Dienste findet (Service Discovery), wie er Last verteilt, wie er mit Containern, die ständig kommen und gehen, umgeht und wie er TLS-Verschlüsselung und Zugriffskontrolle umsetzt. Diese Querschnittsaufgaben in jedem Dienst zu duplizieren führt zu teurem, inkonsistentem Code. Ein Service Mesh zieht diese Logik aus den Anwendungen heraus und in eine gemeinsame Datenebene.
Sidecar-Prinzip und zwei Ebenen
Ein Service Mesh besteht aus zwei Teilen:
- Datenebene: Neben jedem Dienst läuft ein kleiner Proxy als „Sidecar" (zum Beispiel Envoy). Er fängt den gesamten ein- und ausgehenden Datenverkehr des Dienstes ab und übernimmt die Netzwerk-Funktionen im Hintergrund.
- Kontrollebene: Eine zentrale Komponente verwaltet die Konfiguration aller Proxys, verteilt Zertifikate und sammelt Metriken. Istio und Linkerd sind typische Vertreter.
Die Anwendung selbst merkt davon kaum etwas — sie spricht weiterhin ganz normal mit anderen Diensten, nur eben durch einen intelligenten Tunnel hindurch.
Was ein Service Mesh bietet
Über die zentrale Konfiguration lassen sich ohne Code-Änderung erreichen:
- Traffic Management: gewichtete Verteilung, Canary- und Blue-Green-Deployments, Timeouts und Retries.
- Resilience: Circuit Breaker, Last-Begrenzung und automatische Wiederholung bei Flüchtigkeitsfehlern.
- Security: gegenseitige TLS-Authentifizierung (mTLS) zwischen allen Diensten, Zugriffspolitiken und Schlüsselrotation.
- Observability: Metriken, Logs und verteilte Traces für jede einzelne Service-to-Service-Verbindung — essenziell für Observability in komplexen Systemen.
Service Mesh, Kubernetes und der richtige Einsatz
Service Meshes sind eng mit Kubernetes und Cloud-native-Architekturen verwachsen, weil Container-Plattformen die nötige Automatik (Pod-Injection, Service Discovery) bereits mitbringen. Ein Load Balancer oder Reverse Proxy bleibt weiterhin wichtig für den Zugang von außen — das Mesh konzentriert sich auf den Verkehr zwischen den Diensten.
Für kleine Monolithen oder wenige Dienste ist ein Service Mesh meist überdimensioniert; ab einer gewissen Zahl von Microservices mit hohen Sicherheits- und Observability-Anforderungen zahlt sich die Investition jedoch schnell aus. Verwandte Grundlagen: Container, Docker, Skalierung und Monitoring.