Service Mesh – Wieder nur ein neuer Hype im Buzzword-Bingo?

Microservices haben viele Vorteile. Doch das Monitoring und die Wartung sind bei komplexen Microservice-Architekturen aufwendig. Das sogenannte Service Mesh kann Abhilfe schaffen. Wie das genau funktioniert und welche Vor- und Nachteile das bietet, schildert Stephan Wies in diesem Beitrag.

Microservices kommen immer öfter zum Einsatz – in neuen Softwaresystemen oder bei der Ablösung veralteter Architekturen. Mit dem Microservices-Ansatz wird eine lose Kopplung von Modulen erreicht und die Geschwindigkeit und Flexibilität der Bereitstellung von Software erheblich verbessert. Auf der Gegenseite werden jedoch auch die Kommunikation und betriebliche Komplexität stark erhöht. In jedem Service müssen Funktionen wie Monitoring oder Resilienz gelöst werden. Es wandern mehr Aufgaben, die in monolithischen Architekturansätzen beim Betrieb verortet sind in die Entwicklungsteams, welche sich dadurch weniger der Entwicklung der eigentlichen Fachlichkeit widmen können.

Welche Lösung gibt es für dieses Problem? Frameworks könnten diese Aufgabe innerhalb eines Microservices übernehmen. Ein prominentes Beispiel aus der Java-Welt ist Spring Cloud. Das Framework bringt viele Funktionen für Standardprobleme mit, etwa für Service Discovery oder Circuit Breaking. Da die Implementierung dieses Frameworks selbst aber auch in Java erfolgt, verliert man jedoch wieder den Vorteil der Technologieunabhängigkeit, den Microservices mitbringen. Ist für die Lösung eines speziellen Problems eine andere Technologie die bessere, ist man trotzdem durch das Framework beschränkt oder muss, wenn vorhanden, ein zusätzliches Framework verwenden.

Dieser anhaltende Trend zu Microservices und die Nachteile der technologieabhängigen Frameworks haben zur Entstehung des sogenannten „Service Meshs“ geführt, ein vielversprechender Ansatz zur Minderung der genannten Probleme durch Einführung einer dedizierten Infrastrukturschicht, die diese Aufgaben übernimmt.

Was ist ein Service Mesh?

Ein Service Mesh besteht aus zwei wichtigen Architekturkomponenten, einer „Data-Plane“ und einer „Control-Plane“. Die nachfolgende Abbildung 1 zeigt den genauen Aufbau und eine Gegenüberstellung zur direkten Kommunikation ohne Service Mesh.

Die Data-Plane besteht aus einer Reihe von Service Proxys, die jeweils neben jedem Fachdienst bereitgestellt werden. Das Pattern wird auch als „Sidecar“ bezeichnet. Funktionen, die jeder Dienst benötigt, werden dabei in einen zusätzlichen Container (das „Sidecar“) extrahiert.

Die Konfiguration der Service Proxys erfolgt über die zweite Schicht, die sogenannten Control-Plane. Jede vom Entwickelnden konfigurierte Änderung des Verhaltens des Service Meshs wird auf die Control-Plane angewendet und automatisch an die Service Proxys verteilt. Eine weitere Aufgabe ist die Verarbeitung von Telemetriedaten, die von den Service Proxys erfasst und an die Control-Plane weitergeleitet werden.

Funktionen des Service Meshs: Monitoring, Resilienz und Routing

Wie einleitend bereits erwähnt, haben in einer verteilten Microservice-Architektur Monitoring, Resilienz oder auch Routing eine besonders große Relevanz. Wie kann hierbei ein Service Mesh helfen?

Monitoring

Jedes auf Microservices basierende System sollte ein zentrales Monitoring besitzen, welches Informationen von allen Services sammelt und zentral bereitstellt. Anhand der gesammelten Daten können beispielsweise Alarmierungsfunktionen implementiert werden, die in Fehlerfällen automatisch auf die Probleme aufmerksam machen. Die Service Proxys innerhalb der Data-Plane eines Meshs messen dafür grundlegende Informationen wie beispielsweise die Latenz und den Durchsatz, aber auch spezifischere Daten, die in etwa die Kommunikationsprotokolle betreffen. Bei der Kommunikation über HTTP können beispielsweise die Status Codes verarbeitet und analysiert werden, um basierend darauf Fehlerraten oder andere Kennzahlen darzustellen.

Dadurch, dass das Service Mesh diese Funktion übernimmt, bleibt der Code der Fachdienste unberührt und jeder Service liefert unabhängig der gewählten Technologie die gleichen Daten.

Es gibt jedoch auch Limitierungen. Für den Mesh ist der eigentliche Service eine Blackbox. Er kann zwar Metriken bezüglich der ein- und ausgehenden Requests liefern – interne Infos, etwa über Threads oder Datenbankverbindungen, kennt jedoch nur der Service selbst.

Resilienz

Unter Resilienz versteht man in einer Microservice-Architektur die Fähigkeit des Gesamtsystems, auch bei Ausfall oder Nichtverfügbarkeit einzelner Services weiter zu funktionieren oder zumindest strukturiert mit dem Problem umgehen zu können. Wird eine Architektur mit asynchronen Kommunikationsmustern wie beim Datenaustausch per Messaging entworfen, übernimmt die Messagingplattform große Teile dieser Aufgabe, da sie quasi als Puffer zwischen den Services dient und Nachrichten, bis zur erneuten Verfügbarkeit eines Zielservices, vorhält.

Im Falle eines synchronen Nachrichtenaustauschs über REST-APIs mittels HTTP kommen hierfür meist sogenannte Circuit Breaker zum Einsatz. Steht ein Zielservice aktuell unter sehr hoher Last, wird die Kommunikation für eine konfigurierte Zeit unterbrochen und nach Ablauf dieser werden in bestimmten Zyklen Retries durchgeführt. Da die Kommunikation in einem Service Mesh immer über den Service Proxy, beziehungsweise das Sidecar, läuft, kann dieser die Aufgabe übernehmen, ohne Anpassungen im Fachservicecode vornehmen zu müssen. Vor allem im Falle unterschiedlicher Technologien müssen keine verschiedenen Frameworks eingesetzt werden.

Routing

In einem Service Mesh können Routingregeln, also Definitionen, welche Services auf zum Beispiel HTTP-Metadaten angesprochen werden sollen, zentral über die Control Plane an die Service Proxys verteilt werden. Bei einer großen Anzahl von Services und einem regelmäßigen Deployen in die Produktionsumgebung, wie dies etwa in agilen Vorgehensmodellen angestrebt wird, kann dies bei sogenannten Canary Releases helfen. Dabei wird ein neu deployter Dienst oder eine neue Version zunächst nur mit einem Bruchteil von Requests angesprochen. Stellt sich heraus, dass dieser stabil läuft und die gewünschte Funktionalität wie erwartet bereitstellt, wird der Traffic sukzessive erhöht, bis ausschließlich der neue Service im Einsatz ist.

Kurzer Marktüberblick: Service Mesh Lösungen

Wirft man einen Blick auf Lösungen, die zur Realisierung eines Service Meshs eingesetzt werden können, findet man zwei prominente Kandidaten: Istio und Linkerd.

• Hinter dem Projekt Linkerd steckt das, vermutlich eher weniger bekannte, Unternehmen Buoyant. Beide Gründer sind ehemalige Mitarbeiter von Twitter. Linkerd war das erste Produkt, welches einen Service Mesh implementierte und somit den Begriff definiert hat.
• Istio entstand 2018 aus einer Kooperation von Lyft, Google und IBM. Es ist eine der beliebtesten und vollständigsten Lösungen, die für alle Unternehmensgrößen und Softwarelandschaften geeignet ist.

Beide Frameworks haben Vor- und Nachteile. Istio bietet den größeren Funktionsumfang und eine höhere Konfigurierbarkeit, benötigt allerdings mehr Ressourcen, was sich auf die Performance auswirkt. Durch den Einsatz von Linkerd ist man auf Kubernetes als Orchestrierungs-Plattform beschränkt, Istio bietet an dieser Stelle mehr Möglichkeiten.

Am Ende muss je nach Projektkontext, vorhandener Systemlandschaft und Funktionalität, die der Mesh abdecken soll, entschieden werden.

Ist der Service Mesh nun ein Hype?

Nach einem Überblick über die Funktionen und Möglichkeiten, die der Einsatz eines Service Meshs bietet, bleibt die Frage danach, ob dies wieder nur ein neuer Hype ist oder ob der Einsatz wirklich sinnvoll ist.

In Architekturen mit vielen Services, unter Umständen sogar mit unterschiedlichen Technologien und viel synchroner Kommunikation, kann der Mehrwert den Aufwand für das initiale Setup durchaus überwiegen. Besonders bei höheren Aufruftiefen, also wenn an einer fachlichen Aktion mehrere Services beteiligt sind und es ohnehin ungelöste Probleme in Bezug auf etwa Monitoring und Resilienz gibt, kann der Einsatz dem Team die Fehlersuche erheblich erleichtern.

Dem gegenüber steht klar das initiale Setup und die Ressourcen, vor allem auch in Form von Mitarbeitenden. Auf keinen Fall darf auch die Beschaffung des nötigen Know-hows unterschätzt werden, eine neue Technologie ist immer auch eine mentale Hürde. Ist die Performance des Systems zudem einer der ausschlaggebenden Faktoren, muss dies sehr detailliert betrachtet werden, da der Einsatz immer zu höheren Latenzen führt.