mrclrchtr

Service Mesh - Was ist das?

In einer Microservice Architektur muss man verschiedene Entscheidungen treffen. Wie soll Service Discovery durchgeführt werden? Wie werden die einzelnen Services konfiguriert? Wie werden die Services abgesichert? Wie findet die Kommunikation statt? All diese Fragen versucht ein Service Mesh zu beantworten und in einem einzigen Produkt zu vereinen. Dadurch erhält man aufeinander abgestimmte Lösungen und die Anzahl der einzelnen Produkte im Software-Stack sinkt. Man ist allerdings nicht an den Service Mesh gebunden, sondern kann in den meisten Fällen auch ein anderes Produkt nutzen. So ist es beispielsweise bei Consul nicht zwingend notwendig den KV-Store von Consul zu nutzen, stattdessen könnte man auch etcd einsetzen.

Service-to-Service Kommunikation im Service Mesh

Die Kommunikation zwischen Microservices eine der größten Herausforderungen in einer Microservice Architektur. Es müssen Service Discovery und Load Balancing durchgeführt werden. Außerdem muss die Kommunikation abgesichert und resilient sein. Die gesamte Komplexität des Zusammenspiels dieser Themengebiete und der Services selbst muss vom Betreiber der Microservice Architektur beachtet werden.

Service Mesh Architektur
Abbilding 1: Service-to-Service Kommunikation im Service Mesh

Herkömmliche Technologien müssen oftmals direkt in die einzelnen Services und teilweise sogar in den Sourcecode integriert werden. In dem Fall muss der Entwickler in der Lage sein, alle für den Service genutzten Technologien zu bedienen. Service Meshes wählen einen anderen Ansatz und benötigen keine Integration in den Service. Sie setzen wie in der Abbildung 1 dargestellt, Sidecars ein.

Sidecar

Das Sidecar ist ein leichtgewichtiger Proxy-Server, der neben dem eigentlichen Microservice, aber in einem eigenen Prozess oder Container läuft. Es stellt ein Netzwerk-Interface bereit, mit dem sich der Microservice verbinden kann. Die Hauptaufgabe des Sidecars ist das Routing der gesamten Kommunikation zu und von dem Microservice. Dabei kommuniziert das Sidecar mit anderen Sidecars und wird durch eine zentrale Stelle im Service Mesh kontrolliert. Es stellt dem Microservice somit die Funktionen des Service Meshes zur Verfügung.

Dadurch wird der Microservice von den Eigenschaften des Service Meshes unabhängig und es kann für jede Aufgabe des Microservices die dafür am besten geeignete Lösung bzw. Programmiersprache eingesetzt werden. Außerdem können sich Entwickler unabhängig von der Umgebung auf ihre Kerngebiete innerhalb des Services konzentrieren.

Service Meshes werden wie in Abbildung 1 zu sehen in zwei Bereiche unterteilt, die Data Plane und die Control Plane.

Data Plane

Die Data Plane besteht aus einer Reihe von Sidecars, die die gesamte Netzwerkkommunikation zwischen den Microservice steuert. Sie wendet dazu Informationen aus der Control Plane an.

Control Plane

Die Control Plane konfiguriert und verwaltet die Sidecars. Dazu kann der Betreiber die nötigen Konfigurationen von Load Balancing, Routing, Service Discovery, Resilience, Observability und Policies in dieser vornehmen.

Die Data Plane bzw. das Sidecar übernimmt die gesamte Service-to-Service Kommunikation in der Anwendungsschicht bzw. Schicht 7 im OSI-Modell. Es wird zentral durch die Control Plane konfiguriert. Alle Änderungen, die in der Control Plane gemacht werden, werden an die Sidecars übertragen. Das beinhaltet folgende Bereiche:

Service Discovery / Load Balancing / Routing

Das Sidecar routet den Traffic zu dem Sidecar, dass es von der Control Plane genannt bekommt. Dabei wird meist eine Kombination aus Service Discovery und Client-Side Load Balancing eingesetzt. Der Client bekommt Informationen aus der Registry und entscheidet selbstständig, welche Service-Instanz er anspricht.

Security

Es werden mehrere Bereiche der Security abgedeckt. Zum einen kann die Kommunikation mithilfe der Sidecars verschlüsselt werden. Dafür werden Zertifikate durch die Control Plane verteilt und gewartet.

Die Zertifikate können anschließend auch für Authentifizierung und Autorisierung genutzt werden. Welche Services welche Berechtigungen haben, wird ebenfalls in der Control Plane verwaltet. Die Sidecars fragen dort nach den nötigen Informationen und wenden diese an.

Policies

In der Control Plane können meist auch Policies wie Quotas oder Rate Limits verwaltet werden. Die Sidecars erhalten und verwenden diese Informationen um z.B. Traffic zu begrenzen.

Observability

Die Sidecars übernehmen einen Teil der Observability. Sie senden Informationen wie Health Status-, Monitoring- und Logging-Informationen an eine Zentrale stelle in der Control Plane, welche dort eingesehen und/oder weiterverarbeitet werden können.

Resilience

Die Sidecars implementieren verschiedene Resilience-Funktionalitäten. Dazu gehören Circuit Breaker, Timeouts, Retries und Rate Limiting.

Multi-Datacenter

Service Meshes sind darauf ausgelegt über mehrere Datacenter hinweg kommunizieren zu können. Die Sidecars bekommen die dafür nötigen Informationen aus der Control Plane.

Deployment

Das Deployment des Service Meshes und dessen Services wird nativ mithilfe von Containern und Produkten wie Docker und Kubernetes unterstützt.

Zusammenfassend kann man aus den genannten Informationen folgende Definition des Service Meshes ableiten:

Service Mesh

Ein Service Mesh besteht aus der Data Plane und der Control Plane. Es stellt mithilfe der Sidecars die Service-to-Service Kommunikation bereit und übernimmt dabei Service Discovery, Load Balancing, Security, Policies, Resilience, Observability und Multi-Datacenter.

Nachteile eines Service Meshes

Trotz der vielen Bereiche, die das Service Mesh abdeckt und der Vorteile, die man dadurch erhält, gibt es auch Nachteile. Man gibt viel Kontrolle ab und die Komplexität steigt stark, da sich die Anzahl der Service-Instanzen enorm erhöht. Im Gegensatz zu einer Microservice Architektur mit kleineren Technologien, kann dadurch die Analyse und das Debugging in Service Meshes erheblich erschwert werden. Wenn Probleme das Service Mesh selbst betreffen, muss im schlimmsten Fall auf ein neues Release gewartet werden, in dem das Problem behoben wurde.

Aufwendige und komplizierte Konfigurationen bergen das Risiko Fehler zu begehen. Durch fehlerhafte Konfigurationen können größere Probleme entstehen, als man durch das Service Mesh löst.

Die Kommunikation findet immer über das Sidecar und damit einem zusätzlichen Hop statt. Dadurch steigt die Latenz und der Netzwerkverkehr in der gesamten Microservice Architektur.

Updates der Software des Service Meshes bieten ebenfalls ein hohes Risiko, da sie alle Bereiche in der Microservice Architektur betreffen. Im Gegensatz dazu kann das Risiko beim Update einzelner Services und deren Technologien besser kalkuliert und ggf. schneller rückgängig gemacht werden. Zusätzlich sind Service Meshes relativ neu und dementsprechend ist das Risiko hoch, dass sie noch nicht ausreichend getestet wurden und damit nicht bereit sind, in der Produktion genutzt und hoch skaliert zu werden.

Außerdem ist das Verwalten des Service Meshes eine große Aufgabe, deren hoher Aufwand sich nicht in jedem Projekt lohnt.

Fazit

Ein Service Mesh kann bei der Implementierung einer Microservice Architektur helfen um verschiedene Aufgaben wie z.B. Service Discovery, Resilience oder Security zu übernehmen. Es muss allerdings für jedes Projekt abgewogen werden, ob sich der Einsatz lohnt. Eine Richtlinie können folgende Aussagen sein:

Wenn eine große Microservice Architektur mit vielen Microservices entwickelt und viele Entwickler als Generalisten eingesetzt werden sollen, kann es sich lohnen, unter Beachtung der Herausforderungen, ein Service Mesh einzusetzen.

Wenn das Projekt dagegen eher klein ist und aus wenigen Spezialisten besteht, ist es wahrscheinlich am sinnvollsten die herkömmlichen Technologien einzusetzen, mit denen sich die Entwickler auskennen und dadurch die Herausforderungen schnell bewältigen können.

Dieser Beitrag basiert auf der Masterarbeit „Analyse und Strukturierung aktueller Microservice Technologien auf Basis von Capabilities“ von Marcel Richter. Diese Arbeit können Sie auf Anfrage erhalten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.