Brauchen asynchrone Microservices und Self-Contained Systems ein Service-Mesh?

Seite 5: Fazit

Inhaltsverzeichnis

Eine asynchrone Kommunikation zwischen Microservices macht einige Funktionen von Service-Meshes wie Tracing obsolet. Von Features wie Routing und Resilienz können sie weniger profitieren als klassische Microservices. Doch allein das automatische, flächendeckende Monitoring und beidseitig authentifizierte Verbindungen können gute Gründe für ein Service-Mesh sein.

SCS profitieren sogar noch darüber hinaus von einem Service-Mesh, da Entwickler Clientanfragen an die Frontends der SCS feingranular steuern können. Routing-Regeln können Canary Releases steuern und Circuit Breaker vermeiden, dass Anfragen bei überlasteten oder fehlerhaften Endpunkten laden. Besonders wenn ein SCS in Microservices aufgeteilt ist, kann ein Service-Mesh wertvolle Kontroll- und Observierungsmöglichkeiten bieten.

Es gibt gute Argumente für ein Service-Mesh in asynchronen Microservices und in Self-contained Systems. Bleibt noch die Auswahl eines Service-Meshes. Die aktuell besten Kandidaten sind Istio, das den größten Funktionsumfang, aber auch die größte Komplexität hat, und Linkerd, das zwar weniger Features, aber dafür eine bessere Developer Experience bietet und leichtgewichtiger ist.

Hanna Prinz
hat bei INNOQ ihre Masterarbeit über Service-Meshes geschrieben. Davor hat sie an der HTW Berlin Seminare zum Einstieg ins Programmieren gegeben und als Full-Stack-Developer an Apps, Front- und Backends entwickelt - bis sie den Herausforderungen des Betriebs begegnete und nicht widerstehen konnte. Seitdem beschäftigt sie sich mit allen Themen im Bereich Automatisierung und DevOps wie Kubernetes, CI/CD und Service-Meshes.
(bbo)