Service Mesh
Einleitung
Ein Service Mesh ist eine dedizierte Infrastrukturschicht für Service-zu-Service-Kommunikation.
Es übernimmt:
- Security (mTLS)
- Traffic Management
- Observability
- Resilienz
ohne dass Applikationen diese Logik selbst implementieren müssen.
Ein Mesh verändert nicht deine Domänenschnitte.
Es verändert, wie Services miteinander sprechen.
Einordnung
Service Mesh ist:
- kein Architekturstil (wie Microservices)
- kein API-Gateway
- kein Business-Pattern
Es ist ein Plattform-/Infrastruktur-Pattern für verteilte Systeme.
Typisch in:
- Kubernetes-Umgebungen
- großen Microservices-Landschaften
- Compliance-getriebenen Organisationen
Grundprinzip
Kernaussage:
- Jede Service-Instanz erhält einen Sidecar-Proxy
- Kommunikation läuft Proxy-zu-Proxy
- Policies werden zentral gesteuert
Architekturkomponenten
1️⃣ Data Plane
- Sidecar-Proxys (z. B. Envoy)
- mTLS
- Retries, Timeouts
- Traffic Routing
- Telemetrie
2️⃣ Control Plane
- Konfigurationsverteilung
- Policy-Management
- Zertifikatsverwaltung
- Routing-Regeln
- Canary-Strategien
Welche Probleme löst ein Mesh?
Security
- Automatisches mTLS zwischen Services
- Zero-Trust-Kommunikation
- Zertifikatsrotation
Traffic Management
- Canary Releases
- A/B-Tests
- Traffic Shifting
- Fault Injection
Observability
- Distributed Tracing
- Metriken
- Service-Graph
- Request-Level-Telemetrie
Resilienz
- Retries
- Timeouts
- Circuit Breaking
- Rate Limiting
Wichtig:
Das Mesh ersetzt nicht fachliche Resilienz – es ergänzt infrastrukturelle Resilienz.
Vorteile
- Standardisierung von Querschnittsthemen
- Weniger Boilerplate-Code in Services
- Zentrale Policy-Durchsetzung
- Verbesserte Security-by-Default
- Gute Grundlage für Compliance
Risiken / Fallstricke
1️⃣ Komplexität
- Mehr bewegliche Teile
- Zusätzliche Debugging-Ebene
- Abhängigkeit von Plattform-Expertise
2️⃣ Performance-Overhead
- Zusätzlicher Netzwerk-Hop
- Sidecar-Ressourcenverbrauch
- Latenz durch Proxy-Kette
3️⃣ Falsche Erwartung
Mesh löst nicht:
- schlechte Domänenschnitte
- synchrone Call-Chain-Monster
- fehlende Ownership
Ein Service Mesh macht schlechte Architektur nicht gut.
API Gateway vs. Service Mesh
| API Gateway | Service Mesh | |
|---|---|---|
| Ebene | Edge | Intern |
| Ziel | Client-Integration | Service-zu-Service |
| Typische Funktionen | Auth, Routing | mTLS, Retries, Traffic-Shifting |
| Sichtbarkeit | Extern | Intern |
Gateway = Außenkante Mesh = interne Kommunikationsschicht
Eignung 2026
Sinnvoll bei:
-
20 Services
- Strengen Security-Anforderungen
- Zero-Trust-Umgebungen
- Canary- und Traffic-Experimente
- Reifer Plattform-Organisation
Weniger sinnvoll bei:
- 3–5 Services
- Fehlender Plattform-Reife
- Kleinen Teams ohne DevOps-Struktur
- Geringem Compliance-Druck
Mesh ohne Plattform-Team ist riskant.
Organisatorische Implikation
Ein Service Mesh erfordert:
- Plattform-Ownership
- SRE-Know-how
- Monitoring-Reife
- Zertifikats-Management
- Netzwerk-Verständnis
Es ist ein Multiplikator für Reife – oder ein Multiplikator für Chaos.
Fazit
Ein Service Mesh standardisiert die interne Kommunikation verteilter Systeme.
Es ist sinnvoll, wenn:
Komplexität ohnehin vorhanden ist.
Es ist Overkill, wenn:
die Organisation noch nicht verteilt ist.