Das Service Mesh – Funktionsweise und Vorteile

Mit einem Service Mesh wie dem Open Source-Projekt Istio lässt sich steuern, wie unterschiedliche Teile einer Anwendung Daten miteinander teilen. Im Gegensatz zu anderen Systemen der Kommunikationsverwaltung ist ein Service Mesh eine dedizierte, direkt in die Anwendung integrierte Infrastrukturschicht. Mit dieser lässt sich dokumentieren, wie gut (oder schlecht) die verschiedenen Komponenten einer Anwendung interagieren. Auf diese Weise können Unternehmen die Kommunikation optimieren und Ausfälle auch dann minimieren, wenn die Anwendung immer größer wird.

Die einzelnen Teile einer Anwendung, auch „Services“ genannt, basieren wiederum auf weiteren Services, die den Nutzenden die gewünschte Funktion bereitstellen. Wenn Nutzende etwa über die Shopping-App eines Einzelhändlers ein Produkt kaufen möchten, möchten sie wissen, ob dieses vorrätig ist. Also muss der Service, der mit der Bestandsdatenbank dieser Firma in Kontakt ist, mit der Produktwebseite und die wiederum mit dem Onlinewarenkorb der Nutzenden kommunizieren. Um den geschäftlichen Mehrwert zu steigern, entwickelt dieser Einzelhändler irgendwann möglicherweise einen Service, der den Nutzenden in der App Produkte empfiehlt. Dieser neue Service kommuniziert für diese Empfehlung mit einer Datenbank aus Produkt-Tags, aber auch mit derselben Bestandsdatenbank, auf die die Produktwebseite zugegriffen hat. Wir haben es also mit einer Vielzahl an wiederverwendbaren beweglichen Teilen zu tun.

Moderne Anwendungen werden oft auf diese Weise aufgeschlüsselt, und zwar als Netzwerk an Services, von denen jeder Service eine spezifische Geschäftsfunktion ausführt. Zur Ausführung seiner Funktion muss ein Service aber möglicherweise Daten von anderen Services anfordern. Was aber passiert, wenn manche dieser Services mit Anfragen überlastet sind, wie etwa die Bestandsdatenbank unseres Einzelhändlers? Hier kommt das Service Mesh ins Spiel, eine Funktion, die Anfragen von einem Service zum nächsten leitet und das Zusammenspiel der veränderlichen Teile optimiert.

Mit einer Microservices-Architektur können Entwicklungsteams Anwendungsservices ändern, ohne sie komplett neu implementieren zu müssen. Im Gegensatz zur Anwendungsentwicklung in anderen Architekturen werden individuelle Microservices von kleinen Teams gebaut, die Tools und Programmiersprachen frei wählen können. Microservices werden grundsätzlich unabhängig entwickelt, kommunizieren miteinander und können einzeln versagen, ohne dass dies zu einem Komplettausfall der jeweiligen Anwendung führt.

Die Grundlage von Microservices ist die Kommunikation zwischen den einzelnen Services. Eine Kommunikationslogik kann auch ohne Service Mesh in die jeweiligen Services programmiert werden, allerdings wird ein Service Mesh mit zunehmender Komplexität der Kommunikation immer sinnvoller. Bei cloudnativen Apps, die in eine Microservices-Architektur integriert sind, kann ein Service Mesh eine große Zahl an getrennten Services zu einer funktionsfähigen Anwendung zusammenfassen.

Ein Service Mesh fügt keine neuen Funktionen zur Runtime-Umgebung einer App hinzu. Für Apps in beliebigen Architekturen wurden zur Übertragung von Anfragen von Punkt A zu Punkt B stets Regeln benötigt. Ein Service Mesh hingegen extrahiert die Logik für die Interservice-Kommunikation aus den einzelnen Services und überträgt sie in eine Infrastrukturschicht.

Hierzu wird das Service Mesh als Array aus Netzwerk-Proxies in eine App integriert. Proxies sind ein bekanntes Konzept aus der Unternehmens-IT. Wenn Sie über einen Arbeits-PC auf diese Website zugreifen, haben Sie wahrscheinlich gerade einen Proxy verwendet:

1. Ihre Anfrage für diese Seite wurde zunächst vom Web-Proxy Ihres Unternehmens empfangen...
2. Sobald die Anfrage die Sicherheitsmaßnahme dieses Proxys bestanden hat, wird sie an den Server gesendet, der diese Seite hostet…
3. Danach wurde diese Seite an den Proxy zurückgeleitet und erneut mit der Sicherheitsmaßnahme geprüft…
4. Zum Schluss wurde die Seite dann vom Proxy an Sie gesendet.

In einem Service Mesh werden Anfragen zwischen Microservices über Proxies in einer eigenen Infrastrukturschicht übertragen. Aus diesem Grund werden einzelne Proxies, die ein Service Mesh ausmachen, manchmal „Sidecars" genannt, da sie parallel zu jedem Service und nicht darin ausgeführt werden. Zusammen bilden diese von jedem Service entkoppelten Sidecar-Proxies ein Mesh-Netzwerk.

Ein Sidecar-Proxy befindet sich neben einem Microservice und leitet Anfragen an andere Proxies weiter. Zusammen bilden diese Sidecars ein Mesh-Netzwerk.

Ohne Service Mesh müssen alle Microservices mit einer Logik für die Interservice-Kommunikation programmiert werden, was den Entwickler-Fokus auf geschäftliche Ziele beeinträchtigt. Es bedeutet auch, dass Kommunikationsfehler schwerer zu diagnostizieren sind, weil die Logik für die Interservice-Kommunikation in jedem einzelnen Service verborgen ist.

Jeder neu hinzugefügte Service oder jede neue Instanz eines vorhandenen Service, der in einem Container ausgeführt wird, macht die Kommunikationsumgebung einer App komplizierter und stellt ein weiteres Ausfallrisiko dar. In einer komplexen Microservice-Architektur kann es fast unmöglich werden, Problemursachen ohne Service Mesh zu diagnostizieren.

Denn in einem Service Mesh werden alle Aspekte der Interservice-Kommunikation sowie Performance-Kennzahlen erfasst. Im Lauf der Zeit können vom Service Mesh sichtbar gemachte Daten auf die Regeln der Interservice-Kommunikation angewandt und so die Effizienz und Zuverlässigkeit von Serviceanfragen verbessert werden.

Beispielsweise kann ein Service Mesh beim Ausfall eines bestimmten Service Daten darüber sammeln, wie lange es bis zu einem erfolgreichen Neuversuch gedauert hat. Basierend auf den gesammelten Daten zu den Ausfallzeiten können dann Regeln geschrieben werden, die die optimale Wartezeit bis zu einem erneuten Serviceaufruf festlegen und sicherstellen, dass das System nicht durch unnötige Neuversuche überlastet wird.

Bei der Entwicklung von Microservices antizipieren Sie wahrscheinlich bestimmte zukünftige Anforderungen, z. B. ein rasches Skalieren oder Hinzufügen von Funktionen, die Ihre geschäftlichen Erfordernisse erfüllen. Es ist gut möglich, dass eine Microservice-Architektur ein Jahr nach der Entwicklung völlig anders aussieht. Zu Beginn können die in Microservices integrierten Bibliotheken die Interservice-Kommunikation vielleicht noch ohne größere Betriebsunterbrechungen handhaben. Wenn Sie allerdings das Potenzial der Microservices durch einen größeren Umfang und noch mehr Funktionen ausreizen, kann dies bald anders aussehen. Im Laufe der Zeit können Probleme entstehen, weil Services mit Anfragen überlastet werden und Entwickler immer mehr Zeit mit der Codierung der Abfragelogik für jeden Service verbringen.

Ein Service Mesh bietet folgende Vorteile:

• Entwickler müssen sich nicht auf die Verbindung von Services konzentrieren, sondern können sich dem geschäftlichen Mehrwert widmen.
• Verteiltes Tracing der Anfragen durch Jaeger bietet eine sichtbare Infrastrukturschicht parallel zu den Services, wodurch Probleme einfacher zu erkennen und zu diagnostizieren sind.
• Apps sind ausfallsicherer, da das Service Mesh Anfragen an nicht funktionsfähige Services rechtzeitig umleitet.
• Performance-Kennzahlen zeigen Möglichkeiten zur Optimierung der Kommunikation in der Runtime-Umgebung auf.

Beginnen Sie, für die Zukunft zu planen, und testen Sie ein Service Mesh mit Red Hat® OpenShift® Service Mesh. Erleben Sie eine einheitliche Art, mit der sie microservice-basierte Anwendungen verbinden, verwalten und beobachten können. Zusätzlich erhalten Sie Insights zur Nutzung und Kontrolle über die Netzwerk-Microservices in Ihrem Service Mesh. OpenShift Service Mesh ist für Red Hat OpenShift kostenlos erhältlich.

Das Automatisierungs-Mesh der Red Hat Ansible Automation Platform bietet ein einfaches und zuverlässiges Service-Mesh-Framework für die Skalierung der Automatisierung. Mit einer flexiblen, multidirektionalen Kommunikationsschicht verbessert das Automatisierungs-Mesh die Fähigkeit eines Unternehmens, auf globaler Ebene zu operieren. Dank der geringeren Anfälligkeit für Latenz und Verbindungsunterbrechungen sowie der nativen Peering-Funktionen können Sie im Vergleich zu allen anderen Automatisierungsplattformen auf dem Markt eine größere Reichweite und mehr Zuverlässigkeit erzielen. Mithilfe von Sicherheitsfunktionen wie TLS-Authentifizierung und -Verschlüsselung sowie zusätzlichen Zugriffskontrollen können Sie sich darauf verlassen, dass die Red Hat Ansible Automation Platform die Möglichkeiten für Ihre gesamte Unternehmens-IT erweitert.

Mehr über die Features der Red Hat Ansible Automation Platform erfahren