Was ist ein Service Mesh?

27.11.2021
Von  und
Josh Fruhlinger ist freier Autor in Los Angeles.


Lee Doyle ist Principal Analyst bei Doyle Research und schreibt unter anderem für unsere US-Schwesterpublikation Network World.
Ein Service Mesh ist essenziell, wenn Microservices zum Einsatz kommen sollen. Das müssen Sie zum Thema wissen.
Unternehmen, die auf den Microservices-Ansatz setzen wollen, fahren besser mit einem Service Mesh. Lesen Sie, warum.
Unternehmen, die auf den Microservices-Ansatz setzen wollen, fahren besser mit einem Service Mesh. Lesen Sie, warum.
Foto: Pykhtik - shutterstock.com

Unternehmen, die auf den Microservices-Ansatz setzen wollen, brauchen eine schnelle und zuverlässige Netzwerk-Infrastruktur. Ein Service Mesh ist diesbezüglich ein wirkungsvoller Enabler.

Service Mesh - Definition

Im weitesten Sinne - und nach Meinung von Red Hat - lässt sich ein Service Mesh als ein Weg definieren, um den Datenaustausch zwischen verschiedenen Teilen einer Applikation zu kontrollieren.

Im engeren Sinn ist ein Service Mesh eine Infrastruktursoftware, die die schnelle und verlässliche Kommunikation zwischen Microservices sicherstellt. Zu den Networking-Funktionalitäten gehören beispielsweise:

  • Application Identification

  • Load Balancing

  • Authentifizierung

  • Verschlüsselung

Anfragen über das Netzwerk werden zwischen den Microservces über parallellaufende Proxies abgehandelt. Diese bilden ein Mesh-Netzwerk, um die individuellen Microservices miteinander zu verbinden. Ein zentraler Controller sorgt für Zugangskontrolle sowie Netzwerk- und Performance-Management.

Ein Service Mesh abstrahiert die Komplexität des Netzwerk-Routings und der Security-Anforderungen für Microservices-Applikationen. Diese Abstraktion ermöglicht ein schnelles und flexibles Ausrollen der Microservices - ohne konstante Eingriffe durch das Networking-Team.

Service Mesh - Booster für Microservices

Applikationen, die auf dem Microservices-Ansatz aufsetzen, unterscheiden sich hinsichtlich ihrer Architektur von klassischen, Hypervisor-basierten Apps: Diverse Services laufen in individuellen Containern, auf unterschiedlichen Servern oder Rechenknoten. Die Transaktionsfrequenz zwischen diesen Microservices innerhalb einer Applikation kann besonders niedrige Latenzzeiten erfordern und signifikante Bandbreitenanforderungen aufwerfen. Dazu kommt, dass unter Umständen mehrere Applikationen auf die gleichen Microservices zugreifen.

Container-basierte Microservices können ihre Verortung verändern und von einem Server zu einem anderen wandern. Dabei stellen sie jedoch nur in begrenztem Maße Daten über ihren "Umzug" und ihren derzeitigen Status zur Verfügung. Das macht es für IT-Spezialisten schwer, sie zu finden und eventuelle Performance-Probleme auf Applikationsebene zu beheben. Gerade DevOps-Teams kommt die Abstraktion durch ein Service Mesh entgegen, schließlich wollen diese besonders schnell entwickeln und anpassen.

Die wesentlichen Voraussetzungen für die Vernetzung von Microservices sind:

  • eine skalierbare Netzwerk-Performance

  • eine einfache Provisionierung von Netzwerk-, Rechen- und Storage-Ressourcen

  • die Fähigkeit, die Bandbreite je nach Applikation schnell zu skalieren

  • die Möglichkeit, Workloads zwischen internen Rechenzentren und der Public Cloud zu migrieren

  • eine Applikations-Isolierung, um das Security-Niveau zu heben und Multi-Tenancy zu gewährleisten

Um diesen Anforderungen gerecht zu werden, muss die IT-Abteilung eine Automatisierung per Service Mesh in ein übergreifendes Datacenter Networking Management System integrieren - speziell vor dem Hintergrund, dass sowohl die Zahl der Container-Deployments als auch deren Komplexität und strategische Bedeutung steigt. Um sich darauf vorzubereiten, empfiehlt es sich, alle verfügbaren Service-Mesh-Optionen zu evaluieren.

Service Mesh - Anbieter

Der Großteil der Service-Mesh-Möglichkeiten basiert auf Open Source - zu den populärsten Projekten zählen:

Darüber hinaus haben auch die großen IaaS-Anbieter eigene Service-Mesh-Angebote in petto. (fm)

Dieser Artikel basiert auf Beiträgen unserer US-Schwesterpublikationen Infoworld & Networkworld.