Was ist ein Service Mesh?
            

Ausfallzeiten oder lange Antwortzeiten sind für Services-Nutzer inakzeptabel. Daher müssen die Verbindungen zwischen den Services, die in verschiedenen Containern laufen, sicher, belastbar und einsehbar sein. Gefragt sind Stabilität und Geschwindigkeit: Damit Unternehmen innovativ sein können, benötigen sie eine schlüsselfertige Implementierung, die alle Vorteile der Cloud in puncto Skalierbarkeit und Agilität mitbringt. Netzwerkaufgaben werden bei einer solchen Implementierung von einem Service-Mesh ausgeführt , und die Entwickler können sich auf die Geschäftslogik konzentrieren.

Warum gibt es Service Mesh?

Die Entstehung der Service-Meshes ist eng mit der rasanten Verbreitung von Anwendungen verbunden, die auf Microservices basieren.

Bei einer traditionellen Anwendung, die viele Dienste auf einer einzigen Plattform ausführt, werden alle Dienste zentral überwacht, und die Services können sich gegenseitig leicht aufrufen, da ihre Adresse immer lokal ist. Aber: Um auch nur einen Service zu ändern, muss die gesamte Anwendung neu implementiert werden. Die Änderung eines Service kann viele abhängige Services beschädigen. Daher müssen sich die Entwickler eng abstimmen und vor der Freigabe umfangreiche Testreihen durchführen. Außerdem können Entwickler nur bestimmte Tools und Sprachen einsetzen, was das Tempo weiter drosselt. Dieser Mangel an Flexibilität kann Unternehmen einschränken, die schnell neue innovative Produkte entwickeln wollen, um wettbewerbsfähig zu bleiben.

Darüber hinaus sind herkömmliche Anwendungen nur eingeschränkt skalierbar. Die Kapazität eines einzelnen Dienstes lässt sich nicht steigern, ohne die Kapazität der gesamten Anwendung zu steigern. Um für Leistungsspitzen bei saisonalen Schwankungen gewappnet zu sein, bauen Unternehmen oft eine große, teure Infrastruktur auf, die aber de facto nur an fünf Tagen im Jahr voll genutzt wird.
Dies führte zur Entwicklung einer Microservices-Architektur, in der kleine Teams ein Netzwerk aus Services aufbauen, in dem jeder Service eine bestimmte Geschäftsaufgabe ausführt, beispielsweise die Abfrage der Lagerbestands oder die Zahlungsabwicklung. Die Services laufen unabhängig voneinander, aber sie kommunizieren miteinander, um Daten anzufordern und Anwendungslogik zu implementieren. Um einen Kauf abzuschließen muss beispielsweise der Warenkorb-Service mit dem Service kommunizieren, der die Zahlung verarbeitet. Lassen sich die einzelne Teile einer App unabhängig voneinander steuern, können sie auch schneller geändert werden. Benötigt ein Unternehmen eine bessere Suchmaschine, ersetzt es einfach den entsprechenden Microservice und erspart sich einen kompletten Release-Zyklus für die gesamte Anwendung. Im Rahmen einer Microservices-Architektur bedeutet Skalierbarkeit: Ein Service, der mehr Kapazität benötigt, wird repliziert. Die anderen bleiben wie sie sind.

Cloud-native Anwendungen basieren auf diesem Microservices-Modell. Sie nutzen die Hardware, die AWS oder Azure in der Cloud on demand zur Verfügung stellen, um bei Bedarf schnell neue Dienste aufzusetzen.
Wenn eine Anwendung jedoch aus Dutzenden oder Hunderten von Teilen besteht, ist es schwierig, die Kontrolle zu behalten. Die Logik, nach der die Teile miteinander kommunizieren, wird in der Cloud noch viel komplexer. Grund dafür sind die vielen Sicherheitsrisiken und die mögliche Instabilität der Netze. Um Ausfallzeiten und lange Antwortzeiten zu vermeiden, müssen die Verbindungen zwischen den einzelnen Teilen sorgfältig geplant werden, damit die Anwendung widerstandsfähig ist. Eine Sicherheitsebene reicht selten aus, um Hacker abzuwehren und private Daten zu schützen. Wenn neue, stärkere Sicherheitsfunktionen verfügbar sind, wollen Unternehmen diese so schnell wie möglich nutzen. Bei einer schnell wachsenden App ist es alles andere als nachhaltig, wenn immer wieder neuer Code geschrieben werden muss, um dies für jedes einzelne Teil sicherzustellen.

Hier kommt der Service-Mesh ins Spiel: Ein Service-Mesh hilft, indem er diese Basis-Netzwerkfunktionen in eine separate Infrastrukturebene auslagert.

Beispiele für Service Mesh

Mit einer separaten Infrastrukturebene zur Steuerung der vielen Funktionen, die durch Microservices ermöglicht werden, entstehen zahllose neue, interessante Anwendungsfälle, unter anderem:

• Sichere Kommunikation: Im Beispiel unserer Einzelhandelsanwendung würde ein Service Mesh eine sichere Netzwerkkommunikation zwischen dem Einkaufswagenservice und dem Zahlungsservice schaffen und die Transaktion auf ihrem Weg durch das Web schützen, ohne dass in jeden Service komplexer Sicherheitscode geschrieben werden muss.
• Fehlertoleranz: Im Service Mesh könnten Backup-Zahlungsdienste für den Fall bestimmt werden, dass der primäre Zahlungsdienst nicht verfügbar ist, ohne Änderungen am primären Zahlungsdienst.
• Verkehrssteuerung: In Spitzenzeiten während der Urlaubszeit könnte das Service-Netz dazu beitragen, dass die Anfragen bei voller Kapazität bearbeitet werden, ohne dass der Zahlungsserver überlastet wird.
  

Die Trennung der funktionalen Anforderungen von den Aufgaben der Anwendung erleichtert den Betrieb und die Wartung der Anwendung.

Wie funktioniert ein Service Mesh?

Service-Mesh-Pioniere, beispielsweise Netflix, haben mit lokalisierten, kundenspezifischen Lösungen begonnen. Heute stellen Service-Mesh-Anbieter üblicherweise kleine Proxys bereit, die auch als „Sidecars" bezeichnet werden, weil sie wie ein Motorrad-Beiwagen mit dem Hauptservice mitfahren. Die Proxys laufen Seite an Seite mit jedem Microservice und senden Informationen an eine zentrale Steuerungskonsole. Im Webverkehr zwischen den Services hat jeder Proxy klare Anweisungen für Routing, Drosselung und Sicherheit. Wie Verkehrsschilder und Ampeln gelten diese Anweisungen an bestimmten Stellen, um sicherzustellen, dass die Online-Fahrzeuge ihr Ziel erreichen. Diese schnelle Echtzeit-Steuerung verbessert die Reaktionsfähigkeit der Anwendung.
Der Erfolg microservicesbasierter Anwendungen beruht jedoch nicht nur auf dem Service-Mesh. Weitere Tools und Konzepte sind wesentliche Bestandteile der neuen Landschaft: Docker und OpenShift bündeln Software in einfach handhabbare Pakete, die zusammen mit dem Service-Mesh in Kubernetes-Clustern verwaltet werden. Und ohne DevOps können Anwendungen nicht effizient implementiert werden. Denn die DevOps-Methode vereint die bisher getrennten Teams für Entwicklung und Betrieb zu einem einzigen Team, das den gesamten Lebenszyklus der Anwendung betreut.

Warum sind Service Mesh für Unternehmen wichtig?

• Risikominimierung: Die Cloud ist eine Zero-Trust-Umgebung. Unter dem Aspekt der Netzwerksicherheit ist jeder öffentliche Microservice potenziell das schwächste Glied und kann Kundendaten und den Ruf eines Unternehmens gefährden. Von entscheidender Bedeutung sind deshalb umfassende, zentral gesteuerte und leicht anpassbare Sicherheitsrichtlinien.
• Ressourcen: Die Erstellung cloudnativer Anwendungen erfordert spezielle Kenntnisse bei den Entwicklern. Automatische Retries, Timeouts, Logging und Anwendungsstabilität spielen im Cloud-Betrieb eine große Rolle. Wenn Entwickler sich selbst darum kümmern müssen, können Fehler passieren. Günstiger ist es, diese Aufgaben einem Service Mesh zu überlassen. Außerdem werden Entwicklerressourcen frei, um neue Funktionen für die Nutzer der Anwendung zu erstellen.
  
• Ausfallsicherheit: Die Erwartungen an die Verfügbarkeit mobiler Apps sind groß, werden diese nicht erfüllt, ist es für Verbraucher ein Leichtes, den Anbieter zu wechseln. Lange Antwortzeiten oder Ausfallzeiten werden längst nicht mehr akzeptiert. Deshalb ist eine resiliente, reaktive Methode der Anwendungsentwicklung unerlässlich. Ein Service-Mesh kann Anfragen umleiten und den Datenverkehr drosseln, um den Umsatz zu schützen.

Wo Service Meshes zu kurz greifen

Wenn es um Anwendungen an sich geht, geht Service Mesh nicht weit genug.  Der Schwerpunkt liegt auf der Netzwerkkonnektivität zwischen den Diensten und nicht auf der Anwendung selbst. Wenn sich Anwendungen durchsetzen, müssen sie möglicherweise schnell skaliert und neue Funktionen hinzugefügt werden, um den Geschäftsanforderungen gerecht zu werden. Jede Änderung, die Coding erfordert, verlangsamt Ihren Fortschritt.  Und es kann schwierig sein, Microservices teamübergreifend zu veröffentlichen und wiederzuverwenden, ohne eine Art von zentraler Sichtbarkeit und Governance. 

Es ist klar, dass bei der Weiterentwicklung von Anwendungen die Möglichkeit, Services ohne Code zu personalisieren, zu verbessern und zu steuern, der Weg ist, wie Sie skalieren und schneller entwickeln können.  Statt eines Service Mesh brauchen Sie ein Application Mesh - das WebMethods AppMesh.

AppMesh besteht aus einer Reihe von leichtgewichtigen, leistungsstarken Mikrogateways, die von einer zentralen API Management Platform gesteuert werden. Es gibt Ihnen Einblick in das Verhalten sowohl Ihrer Benutzer als auch Ihrer Microservices auf der Anwendungsebene. Und Sie können diese Microservices genauso einfach wiederverwenden und steuern, wie Sie es mit APIs tun. Es handelt sich um eine ausgeklügelte Service Mesh Architektur, die Ihnen die Möglichkeit gibt, das Verhalten Ihrer Services in Echtzeit zu ändern und erweiterte Richtlinien für die Benutzerautorisierung mit nur einem Knopfdruck anzuwenden.

Und anstatt ein weiteres Tool zu Ihrer Landschaft hinzuzufügen, ist webMethods AppMesh in Ihre API-Verwaltungsschicht eingebettet, so dass Sie nicht nur APIs, sondern auch Microservices und Service Meshes von einer einzigen Stelle aus verwalten können.  Dies ist die Grundlage für die Entwicklung von Cloud-nativen Anwendungen, die Microservices und APIs nutzen.

Machen Sie den nächsten Schritt

• Mehr überAppMesh erfahren 
  
• Service Mesh in unserem Tech-Radar ansehen