Microservices

Was ist ein Service Mesh?

Mit einem Service Mesh lässt sich kontrollieren, wie unterschiedliche Teile einer Anwendung Daten miteinander teilen. Im Gegensatz zu anderen Systemen der Kommunikationsverwaltung ist ein Service Mesh eine dedizierte, direkt in die App integrierte Infrastrukturschicht. Mit dieser lässt sich dokumentieren, wie gut (oder schlecht) die verschiedenen Komponenten einer App interagieren. Auf diese Weise wird die Kommunikation optimiert, und Ausfälle können minimiert werden, auch wenn die App immer größer wird.

Jeder Teil einer Anwendung, ein „Service“, basiert wiederum auf weiteren Services, die dem Nutzer die gewünschte Funktion bereitstellen. Wenn ein Nutzer z. B. über die Shopping-App eines Einzelhändlers ein Produkt kaufen möchte, möchte er wissen, ob dieses vorrätig ist. Also muss der Service, der mit der Bestandsdatenbank dieser Firma in Kontakt ist, mit der Produkt-Webseite und die wiederum mit dem Online-Warenkorb des Nutzers kommunizieren. Um den geschäftlichen Mehrwert zu steigern, entwickelt dieser Einzelhändler irgendwann möglicherweise einen Service, der dem Nutzer 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 Produkt-Webseite zugegriffen hat. Ergo haben wir es 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 z. B. 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 aller veränderlichen Teile optimiert.


Ist das nicht die Aufgabe von Microservices?

Mit einer Microservice-Architektur können Entwickler App-Services ändern, ohne sie komplett neu implementieren zu müssen. Entgegen der App-Entwicklung 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 App führt.

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


Wie geht das?

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 Inter-Service-Kommunikation aus den einzelnen Services und überträgt sie in eine Infrastrukturschicht.

Hierzu wird das Service Mesh als Array mit Netzwerk-Proxys in eine App integriert. Proxys sind ein aus der Unternehmens-IT bekanntes Konzept. Wenn Sie über einen Arbeits-PC auf diese Website zugreifen, verwenden sie mit großer Wahrscheinlichkeit einen dieser Proxys:

  1. So wird Ihre Anfrage für diese Seite zuerst vom Web-Proxy der jeweiligen Firma angenommen...
  2. Sobald die Anfrage die Sicherheitsmaßnahme dieses Proxys bestanden hat, wird sie an den Server gesendet, der diese Seite hostet…
  3. Danach wird diese Seite an den Proxy zurückgeleitet und erneut mit der Sicherheitsmaßnahme geprüft…
  4. Zum Schluss wird die Anfrage dann vom Proxy an Sie gesendet.

In einem Service Mesh werden Anfragen zwischen Microservices über Proxys in deren eigener Infrastrukturschicht übertragen. Aus diesem Grund werden einzelne Proxys, 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-Proxys ein Mesh-Netzwerk.

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

Ohne Service Mesh müssen alle Microservices mit einer Logik für die Inter-Service-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 Inter-Service-Kommunikation in jedem einzelnen Service verborgen ist.


Wie kann ein Service Mesh die Kommunikation verbessern?

Jeder neu zu einer App hinzugefügte Service oder jede neue Instanz eines vorhandenen Service, der in einem Container ausgeführt wird, macht die Kommunikationsumgebung 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 Inter-Service-Kommunikation auch als Performance-Kennzahlen erfasst. Im Lauf der Zeit können vom Service Mesh sichtbar gemachte Daten auf die Regeln der Inter-Service-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 aggregierten Daten zu den Ausfallzeiten können dann Regeln geschrieben werden, mit denen die optimale Wartezeit bis zu einem erneuten Serviceaufruf ermittelt werden kann. So wird gewährleistet, dass das System nicht durch unnötige Neuversuche überlastet wird.


Planung für die Zukunft

Bei der Entwicklung von Microservices antizipieren Sie vielleicht bestimmte zukünftige Anforderungen sowieso, z. B. eine rasche Skalierung und das schnelle Hinzufügen von Funktionen, um geschäftliche Erfordernisse zu erfüllen. Es ist aber 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 Inter-Service-Kommunikation vielleicht noch ohne größere Betriebsunterbrechungen handhaben. Wenn Sie allerdings das Potenzial von Microservices durch eine höhere Skalierung und noch mehr Funktionen ausreizen, wird dies nicht lange Bestand haben. 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.

Mit einem Service Mesh

  • können sich Entwickler auf den geschäftlichen Mehrwert fokussieren statt auf die Verbindung von Services,
  • bildet die Abfragelogik eine sichtbare Infrastruktur parallel zu den Services, wodurch Probleme einfacher zu erkennen und zu diagnostizieren sind,
  • sind Apps widerstandsfähiger gegen Ausfälle, da das Service Mesh Anfragen an nicht funktionsfähige Services rechtzeitig umleitet und
  • lassen sich mithilfe von Performance-Kennzahlen Möglichkeiten zur Optimierung der Kommunikation in der Runtime-Umgebung entwickeln.

Ein Service Mesh hat noch viel mehr zu bieten