Seitenwagen und Servicenetze Die Rolle des Service-Mesh in Microservices-Umgebungen

Autor / Redakteur: Thomas Joos / Ulrike Ostler

Unternehmen, die von monolithischen Anwendungen zu einer Microservices-Infrastruktur wechseln, die über Container zur Verfügung gestellt wird, sollten das zu Grunde legende Service-Mesh optimieren. Autor und Berater Thomas Joos erläutert warum.

Firmen zum Thema

Im Service Mesh tragen die Proxys die Bezeichnung „Sidecars“, da sie parallel zu den Services arbeiten und nicht in den Services selbst.
Im Service Mesh tragen die Proxys die Bezeichnung „Sidecars“, da sie parallel zu den Services arbeiten und nicht in den Services selbst.
(Bild: Maik Steiskal auf Pixabay)

Wenn Unternehmen neue Dienste oder Anwendungen einführen, stellt sich häufig die Frage, ob der Fokus auf monolithischen Anwendungen liegen soll, oder ob der Einsatz von Microservices mit einem Service-Mesh sinnvoll sind. Beide Ansätze haben Vor- und Nachteile. Allerdings wird vor allem bei komplexen Systemen zunehmend auf Microservices gesetzt.

Einfach ausgedrückt bestehen Anwendungsmonolithen aus Diensten und Funktionen, die in einem einzelnen großen Block oder Server zusammengefasst sind. Zudem sind diese eng miteinander verbunden und verwoben. Das führt dazu, dass eine solche Anwendung als Ganzes betrieben, gewartet und aktualisiert werden muss.

Zudem werden häufig proprietäre Schnittstellen verwendet, Ressourcen wie Hardware spielen eine wichtige Rolle, und die einzelnen Teilsysteme und Komponenten werden nicht gegliedert und getrennt voneinander betrieben. In der Vergangenheit wurden solche Systeme meistens auf dedizierten Servern oder Clustern betrieben. Das sorgt dafür, dass die Bereitstellung schnell erfolgt; denn die Komponenten sind aufeinander abgestimmt.

Viele Anwendungen aus der IT-Vergangenheit, etwa ERP-Systeme und Branchenapplikationen aber auch Datenbankanwendungen, wurden auf Basis der monolithischen Struktur erstellt. Entsprechend schwierig gestaltet sich die Eingliederung in Microservices.

Die Zeit der Monolithen ist angezählt

Zu den heutigen Trends gehört es, die monolithischen Infrastrukturen aufzubrechen und die einzelnen Teilkomponenten in Microservices unterteilt sowie Hardware-unabhängig getrennt voneinander zu betreiben. Dabei kommen meistens Container zum Einsatz, in denen die einzelnen Dienste/Services bereitgestellt werden. Dabei besteht auch die Möglichkeit, dass ein Service auf mehreren Containern betrieben wird, zum Beispiel aus Gründen der Skalierung.

Die einzelnen Komponenten/Services lassen sich auf diese Weise getrennt voneinander aktualisieren und warten. Der Effekt: Das gesamte System wird transparenter und wesentlich flexibler.

So lassen sich neue Funktionen in den einzelnen Diensten schneller implementieren. Die Leistung erhöht sich, weil jeder einzelne Dienst getrennt von den anderen skaliert werden kann. Services lassen sich auch durch zusätzliche Container leicht skalieren.

Das Aber: Da die Bereitstellung der einzelnen Microservices über Container getrennt voneinander stattfindet, steigt im Gegenzug zur gewonnenen Flexibilität sowohl der initiale Aufwand für die Bereitstellung als auch die Komplexität der Umgebung.

Service-Mesh beim Einsatz von Microservices

Beim Einsatz von Microservices kommt zwangsläufig auch ein Service-Mesh zum Einsatz. Hier wird definiert, wie die einzelnen Dienste und Teile der kompletten Anwendung und die eingesetzten Container Daten miteinander austauschen und teilen. Bei der Kommunikation zwischen Services und den einzelnen Containern spielen Identity Management, Verschlüsselung, Zertifikate, Access Control und Telemetrie eine wichtige Rolle.

Außerdem muss der Verkehr zwischen den Services verwaltet und der stabile Zustand der Kommunikation sichergestellt sein. Das sind nur einige Beispiele der Aufgaben, die ein Service-Mesh in einer Container-Umgebung mit Microservices erledigen muss.

Ein Service-Mesh hat die Aufgabe alle Services in einer Microservices-Infrastruktur miteinander zu koordinieren, den Datenaustausch zu steuern und vor allem die Zusammenarbeit zu optimieren. Nur ein optimiertes Service-Mesh kann sicherstellen, dass die einzelnen Microservices ihre Funktionen so zur Verfügung stellen, dass der komplette Dienst auch problemlos funktioniert. Je komplexer eine Microservices-Infrastruktur ist, desto sinnvoller ist der Einsatz eines Service-Mesh, um die Kommunikation im Griff zu behalten und Fehler schneller diagnostizieren zu können.

Auf der Basis von Regeln

Eine Microservices-Infrastruktur wird durch jeden Container und jeden Service umfassender und damit komplizierter. Vor allem bei Fehlern und Leistungseinbrüchen kann ein Service-Mesh wesentlich schneller und leichter eine Lösung aufzeigen, wie eine manuelle Konfiguration der Datenverbindungen einzelner Services. Durch die Erfassung der wichtigsten Kennzahlen für die Leistung im Service-Mesh, können Regeln ständig angepasst und dadurch optimiert werden.

Microservices werden getrennt voneinander entwickelt und sind so unabhängig, dass der Ausfall eines einzelnen Service nicht den Ausfall der kompletten zugrundeliegenden App bedeutet. Damit zum Beispiel ein Shop-System, das auf Microservices aufbaut, funktioniert, muss definiert werden, welche einzelne Dienste in der Struktur Zugriff auf die verschiedenen Daten und Funktionen im Unternehmen und auf andere Services hat.

Sucht ein Kunde ein Produkt, dann muss der Service, der dafür zur Verfügung steht, Zugriff auf die Datenbank erhalten, in der die Produkte gespeichert sind. Dieser Service muss wiederum mit dem Service kommunizieren, der den Warenkorb im Shop-System darstellt.

Werden Kunden auch Produkte empfohlen, die auf der Auswahl bereits gekaufter Produkte aufbauen, ist eine Kommunikation mit der Datenbank der Produkte notwendig und anderer Daten, auf deren Basis Produkte empfohlen werden. Wenn ein Service in einer solchen Infrastruktur überlastet ist, betrifft das entsprechend auch die anderen Bereiche, da der Endanwender schlicht und ergreifend durch einen Flaschenhals ausgebremst wird.

Vorsicht Steinschlag! Die Monolithen brökeln.
Vorsicht Steinschlag! Die Monolithen brökeln.
(Bild: Clker-Free-Vector-Images auf Pixabay)

Ein solches Netzwerk aus Services, das nur zusammen eine Funktion zur Verfügung stellt, die Anwender benötigen, zum Beispiel einen Webshop, sollte also ständig optimiert und skaliert werden. Nur dann können Microservices ihre kompletten Vorteile ausspielen.

Häufig erfordert es eine solche Infrastruktur auch, dass einzelne Services Daten von anderen Services abrufen. Auch hier muss definiert werden, wie das erreicht werden soll, ohne die Abhängigkeiten zu groß zu machen, wie bei monolithischen Anwendungen. Auch dazu wird ein Service-Mesh genutzt.

Sidecars im Service-Mesh

Die Übertragung von Daten in einer Microservices-Infrastruktur wird mit Regeln gesteuert. Diese Regeln werden vom Service-Mesh genutzt, um die Logik der Kommunikation zwischen Services in die Infrastrukturschicht zu extrahieren. Das Service-Mesh wird dazu als ein Array aus Proxys in die Anwendung integriert, die durch die Microservices-Infrastruktur bereitgestellt wird.

Die Funktion entspricht der eines Webproxy im Unternehmen, bei denen Anfragen der Anwender entgegengenommen und geprüft werden. Danach wird die aufgerufene Webseite auf den Proxy umgeleitet, der diese prüft und an den Anwender weitergibt. Der Proxy steht also als Schnittstelle zwischen Anwendern und Diensten.

Im Service-Mesh werden die Anfragen der einzelnen Services über Proxys in einer eigenen Schicht übertragen. Die Proxys tragen die Bezeichnung „Sidecars“, da sie parallel zu den Services arbeiten, nicht in den Services selbst. Die Verbindungen der einzelnen Proxys bilden das Mesh-Netzwerk. Diese Komponenten gilt es in Einklang zu bringen und miteinander zu verknüpfen.

(ID:47021568)

Über den Autor

 Thomas Joos

Thomas Joos

Freiberuflicher Autor und Journalist