Was ist ein Service Mesh?

Ein Service Mesh ist essenziell, wenn Microservices zum Einsatz kommen sollen. Hier finden Sie zusammengefasst alles, was Sie wissen müssen. [...]

Unternehmen, die auf den Microservices-Ansatz setzen wollen, fahren besser mit einem Service Mesh. Lesen Sie, warum (c) pixabay.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.

Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

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. 

*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.


Mehr Artikel

Frauen berichten vielfach, dass ihre Schmerzen manchmal jahrelang nicht ernst genommen oder belächelt wurden. Künftig sollen Schmerzen gendersensibel in 3D visualisiert werden (c) mit KI generiert/DALL-E
News

Schmerzforschung und Gendermedizin

Im Projekt „Embodied Perceptions“ unter Leitung des AIT Center for Technology Experience wird das Thema Schmerzen ganzheitlich und gendersensibel betrachtet: Das Projektteam forscht zu Möglichkeiten, subjektives Schmerzempfinden über 3D-Avatare zu visualisieren. […]

News

KI ist das neue Lernfach für uns alle

Die Mystifizierung künstlicher Intelligenz treibt mitunter seltsame Blüten. Dabei ist sie weder der Motor einer schönen neuen Welt, noch eine apokalyptische Gefahr. Sie ist schlicht und einfach eine neue, wenn auch höchst anspruchsvolle Technologie, mit der wir alle lernen müssen, sinnvoll umzugehen. Und dafür sind wir selbst verantwortlich. […]

Case-Study

Erfolgreiche Migration auf SAP S/4HANA

Energieschub für die IT-Infrastruktur von Burgenland Energie: Der Energieversorger hat zusammen mit Tietoevry Austria die erste Phase des Umstieges auf SAP S/4HANA abgeschlossen. Das burgenländische Green-Tech-Unternehmen profitiert nun von optimierten Finanz-, Logistik- und HR-Prozessen und schafft damit die Basis für die zukünftige Entflechtung von Energiebereitstellung und Netzbetrieb. […]

FH-Hon.Prof. Ing. Dipl.-Ing. (FH) Dipl.-Ing. Dr. techn. Michael Georg Grasser, MBA MPA CMC, Leiter FA IT-Infrastruktur der Steiermärkischen Krankenanstaltengesellschaft m.b.H. (KAGes). (c) © FH CAMPUS 02
Interview

Krankenanstalten im Jahr 2030

Um sich schon heute auf die Herausforderungen in fünf Jahren vorbereiten zu können, hat die Steiermärkische Krankenanstaltengesellschaft (KAGes) die Strategie 2030 formuliert. transform! sprach mit Michael Georg Grasser, Leiter der Fachabteilung IT-Infrastruktur. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*