Suchen

Definition: Service-to-Service-Kommunikation via Sidecar Proxys Was ist ein Service Mesh?

| Autor / Redakteur: Dipl.-Ing. (FH) Stefan Luber / Florian Karlstetter

Ein Service Mesh ermöglicht die Verwaltung und Steuerung der Service-to-Service-Kommunikation. Es stellt die Grundlage für Cloud-native Anwendungen bestehend aus vielen einzelnen containerisierten Microservices zur Verfügung. Die Services kommunizieren im Service Mesh über sogenannte Sidecar Proxys. Das Service Mesh verbessert Stabilität, Erweiterbarkeit, Transparenz und Sicherheit der Anwendungen.

Ein Service Mesh dient zur Verwaltung und Steuerung der Service-to-Service-Kommunikation und bildet die Grundlage für cloud-native, auf Microservices basierende Anwendungen.
Ein Service Mesh dient zur Verwaltung und Steuerung der Service-to-Service-Kommunikation und bildet die Grundlage für cloud-native, auf Microservices basierende Anwendungen.
(Bild: gemeinfrei © Gerd Altmann / Pixabay )

Das Service Mesh ist ein Konzept zur Steuerung und Verwaltung der Service-to-Service-Kommunikation. Es stellt eine zusätzliche Infrastrukturschicht zur Verfügung, über die die einzelnen Services sicher und zuverlässig Informationen austauschen. Für cloud-native Anwendungen bestehend aus vielen verschiedenen containerisierten Microservices bildet das Service Mesh eine stabile Grundlage.

Technisch kommen sogenannte Sidecar Proxys zum Einsatz, die den Microservices zugeordnet sind und über die die komplette Kommunikation geführt wird. Sidecar Proxys verwenden standardisierte Protokolle und Schnittstellen für den Austausch der Informationen. Über die Proxys lässt sich die Kommunikation steuern, verwalten und überwachen. Durch die Einführung der zusätzlichen Infrastrukturschicht des Service Meshs ergeben sich zahlreiche Vorteile. Die Microservices interagieren sicher und zuverlässig. Durch die Überwachung der Kommunikation erkennt das Service Mesh Probleme der Service-to-Service-Kommunikation und reagiert automatisiert .

Es kann Anfragen wiederholen oder redundante Verbindungsmöglichkeiten nutzen. Zahlreiche Lösungen zur Realisierung eines Service Meshs sind verfügbar. Die beiden bekanntesten sind Istio und Linkerd. Weitere Lösungen sind Tetrate, Kuma, Consul, Maesh und andere.

Das Service Mesh als Basis für cloud-native Anwendungen bestehend aus Microservices

Klassische Anwendungen wurden in der Vergangenheit als Monolithe realisiert. Moderne cloud-native Anwendungsarchitekturen hingegen bestehen aus vielen einzelnen containerisierten Services. Die einzelnen Microservices lassen sich auf verschiedenen Infrastrukturen On-Premises oder cloud-basiert in einer Public Cloud, Private Cloud oder Hybrid Cloud betreiben. Die Funktionalität einer Anwendung entsteht durch die Verflechtung und Interaktion der Microservices. Anwendungen können aus tausenden verschiedenen Microservices bestehen.

Dieses komplexe Service-Geflecht ist manuell kaum zu steuern und zu kontrollieren. Jeder neu hinzugefügte Service macht das Service-Geflecht komplizierter, erhöht das Ausfallrisiko und erschwert das Management. Je komplexer die Microservice-Architektur ist, desto schwerer lassen sich Probleme finden und Fehler diagnostizieren. Die Integration der Kommunikationslogik in die einzelnen Services ist nur schwer zu realisieren und zu bewältigen. Es wird eine zusätzliche Infrastrukturschicht benötigt, die ein zentral manage-bares Servicesystem schafft, um die verteilten Services komfortabel, sicher, zuverlässig und performant zu vernetzen. Genau diese Funktionsbasis stellt ein Service Mesh zur Verfügung. Es optimiert und regelt das Zusammenspiel der Microservices und führt eine große Zahl separater Dienste zu einer funktionsfähigen Anwendung zusammen.

Grundsätzliche Architektur und Funktionsweise eines Service Meshs

Das Funktionsprinzip eines Service Meshs basiert darauf, die Service-to-Service-Kommunikation aus den einzelnen Services zu extrahieren und die Aufgabe der Verwaltung und Steuerung an eine eigene Infrastrukturschicht zu übertragen. Die Architektur teilt sich in eine Control Plane, eine Data Plane und eine Schicht bestehend aus den verschiedenen Services auf. Jedem Service wird ein sogenannter Sidecar Proxy zur Seite gestellt. Über ihn werden alle Anfragen eines Services geführt. Er wickelt die komplette Kommunikation des Services stellvertretend ab.

Die Sidecar Proxys sind von den Services entkoppelt und kommunizieren über standardisierte Protokolle und Schnittstellen. Sie bilden in Summe die dezentrale Data Plane des Service Meshs. Die Data Plane vernetzt nicht die Services an sich, sondern ihre Sidecar Proxys. Die Control Plane ist eine zentrale Instanz, die die Data Plane verwaltet. Sie konfiguriert, kontrolliert und überwacht die Sidecar Proxys.

Funktionen und Aufgaben eines Service Meshs

Aufgrund des zentralen Managements der Service Proxys, die die komplette Service-to-Service-Kommunikation übernehmen, kann das Service Mesh alle Datenströme vollständig kontrollieren. Das Service Mesh ist in der Lage, folgende Aufgaben zu übernehmen oder Funktionen auszuführen:

  • Überwachung der Kommunikation,
  • Lastverteilung und Traffic Management,
  • Authentifizierung der Services,
  • Verschlüsselung der übertragenen Daten,
  • Durchsetzung von Sicherheits-Vorgaben,
  • Routing des Datenverkehrs abhängig von definierten Regeln,
  • Versionierung von Services und ihrer Kommunikation beispielsweise für A/B-Testing,
  • Mirroring des Datenverkehrs beispielsweise für Analysezwecke oder Logging,
  • automatische Reaktion bei Netzwerkfehlern oder Ausfällen einzelner Services.

Verfügbare Lösungen zur Realisierung eines Service Meshs

Es existieren zahlreiche verschiedene Lösungen zur Realisierung eines Service Meshs. Die beiden bekanntesten und derzeit am häufigsten genutzten sind Istio und Linkerd.

Service Mesh mit Istio: effizientes Microservice-Management für verteilte Cloud-native-Umgebungen.

Definition: Service Mesh, plattformunabhängig und quelloffen

Was ist Istio?

Istio geht ursprünglich auf ein Projekt der Unternehmen IBM, Lyft und Google zurück. Die erste Version der Software wurde im Jahr 2018 veröffentlicht. Die Software ist ein Open-Source-Projekt und unter Apache License 2.0 frei verfügbar. Die Data Plane in Istio bilden die sogenannten Envoy Proxys. Linkerd erschien erstmalig im Jahr 2016 und ist ein Projekt der Cloud Native Computing Foundation (CNCF). Auch Linkerd steht unter freier Apache License 2.0. Neben Linkerd und Istio sind weitere Software-Lösungen für Service Meshs wie Tetrate, Kuma, Consul, Maesh und andere verfügbar.

Vor- und Nachteile eines Service Meshs

Durch die Schaffung einer zusätzlichen Infrastrukturschicht, über die sämtliche Kommunikation der Microservices geführt wird, bietet das Service Mesh zahlreiche Vorteile. Alle Aspekte der Service-to-Service-Kommunikation lassen sich erfassen, kontrollieren und managen. Effizienz, Sicherheit und die Zuverlässigkeit des Service-Geflechts steigen. Zudem ist eine einfachere und schnellere Skalierung der Services möglich, da die Funktionalität von der Kommunikation entkoppelt ist. Entwickler können sich vollständig auf die Programmierung der Microservices konzentrieren, ohne sich um die Verbindungen der Services kümmern zu müssen.

Probleme sind einfacher zu finden und zu diagnostizieren. Auch die Widerstandsfähigkeit (Resilienz) der cloud-nativen Anwendung steigt, da das Service Mesh dysfunktionale Services erkennt und Anfragen automatisiert umleitet. Es entsteht eine ausfallsichere und fehlertolerante Microservice-Architektur. Die Authentifizierung der Services und das Verschlüsseln und Entschlüsseln der übertragenen Daten durch die Sidecar Proxys schafft zusätzliche Sicherheit im Service-Geflecht. Ein weiterer Vorteil ist, dass sich die Microservices unabhängig von der verwendeten Plattform und vom genutzten Anbieter nahtlos in das Service Mesh integrieren lassen. Verkehrs- und Laststeuerung sind unabhängig von den jeweiligen Cloud- oder IT-Umgebungen möglich.

Als möglicher Nachteil eines Service Meshs lässt sich anführen, dass durch die zusätzliche Instanz der Sidecar Proxys die Performance gegenüber einer direkten Kommunikation der Services beeinträchtigt werden kann. So können unter Umständen Latenzzeiten durch die Verarbeitung der Daten in den Proxys steigen.

(ID:46715042)

Über den Autor