© everythingpossible, 123RF

Wer setzt Service Meshes heute bereits ein? Welche fertigen Produkte gibt es, die ein Service Mesh integrieren? Das Linux-Magazin hat sich unter Providern und Herstellern von Cloud-Lösungen umgehört.

Linux-Magazin: Bieten Sie Lösungen mit einem Service Mesh an und wenn ja, in welcher Form, in welchem Produkt und mit welcher Technologie?

Cloud Foundry: Ja, das haben wir im Programm: Die Cloud Foundry Application Runtime beinhaltet sowohl Istio Pilot als auch Envoy, die beide Service-Mesh-Funktionen innerhalb der Plattform bereitstellen. Unser Fokus liegt allerdings nicht direkt darauf, ein Service Mesh anzubieten. Stattdessen konzentrieren wir uns auf Developer-bezogene Funktionen, mit denen ein Entwickler sich sein Service Mesh konfigurieren kann.

Suse: Suse ist sowohl in den CNCF- als auch in den Open-Source-Arbeitsgruppen aktiv, die sich mit Service-Mesh-Technologien im Kubernetes-Umfeld auseinandersetzen. Aufgrund der relativ geringen Reife verschiedener konkurrierender Lösungen überwacht Suse derzeit dieses Feld genau. Die Planung geht dahin, eine oder mehrere dieser Lösungen in Suses Container-as-a-Service-Platform (CaaSP) zu integrieren, sobald die Projekte ausreichend stabil sind. Das soll dazu beitragen, Fehlschläge zu vermeiden und das Risiko zu verringern, dass Kunden von Suse mit einem verwaisten Service-Netz stranden.

Derzeit ist Istio ein führender Wettbewerber, und das Network Service Mesh Projekt innerhalb der CNCF platziert sich als weiterer ziemlich interessanter Mitspieler. Daneben gibt es einige andere Projekte, die man zumindest im Auge behalten sollte.

Während Suse und vorgeschaltete Communities noch daran arbeiten, die Technologien für ein Service Mesh auf ein stabiles, produktionsreifes Qualitätsniveau zu bringen, können alternative Lösungen wie Policy Management und Enforcement Engines bereits jetzt viele der Anwendungsfälle abdecken, die ein Service Mesh bereithalten will. Suse CaaSP umfasst beispielsweise Cilium, eine extrem benutzerfreundliche und leistungsstarke Policy-Management- und Enforcement-Engine auf Basis der BPF-Technologie. Diese Lösung deckt einen großen Prozentsatz der Anwendungsfälle für komplexe Container-Workloads in heutigen Produktivumgebungen ab. Als überzeugender Vorteil werden Cilium und Istio schließlich zukünftig gut mit CaaSP verzahnt sein, um sowohl die Durchsetzung von Richtlinien als auch einige der komplexeren Service-Mesh-Anwendungsfälle zu unterstützen.

Red**Hat: Red Hat OpenShift Service Mesh ist heute als Funktion für alle OpenShift-Kunden verfügbar. OpenShift Service Mesh (basierend auf Istio) war in Form eines Tech-Previews fast ein Jahr vor der ersten offiziellen Version zugänglich. Dieses für die Allgemeinheit nun freigegebene Release enthält bereits wichtige Rückmeldungen von den ersten Kunden. Zu den Schwerpunkten zählen unter anderem:

• Ein einfacher Einstieg in das Service Mesh ist für Kunden von entscheidender Bedeutung. Deshalb wird OpenShift Service Mesh als sogenannter Operator paketiert und verteilt, was die Installation und Bereitstellung vereinfacht.
• Das Verwalten eines kritischen Bestandteils der Infrastruktur, wie es ein Service Mesh ist, kann namentlich unter Sicherheitsgesichtspunkten eine Herausforderung sein. Der OpenShift Service Mesh Operator ist deshalb in das Operator Lifecycle Management von OpenShift integriert, was die Verwaltung von Upgrades erleichtert.
• Da es sich bei Service Mesh um eine Technologie handelt, die sowohl die Grenzen von Applikationen überschreitet als auch solche der Infrastruktur, des Betriebs oder der Sicherheit, integriert OpenShift eine Reihe zusätzlicher Tools, um spezialisierten Teams die notwendige Transparenz zu bieten. Zu diesen Tools (Abbildung 1) gehören Jaeger (Sichtbarkeit), Kiali (Visualisierung), Prometheus (Überwachung) und Grafana (Dashboards).

Abbildung 1: Kiali visualisiert das Service Mesh. So sind die Zusammenhänge leichter verständlich. Quelle: Red Hat

• OpenShift Service Mesh bietet auch Integrationen mit dem Red Hat 3scale API Gateway, um den Nord-Süd-Verkehrsfluss zwischen Anwendungsendpunkten und dem Service-Backend zu vereinfachen.

Alles in allem vereinfacht Red Hat OpenShift Service Mesh die Service-zu-Service-Kommunikation von Kubernetes-Anwendungen auf Red Hat OpenShift 4. Durch die native Integration des Service Mesh in die OpenShift-Kubernetes-Plattform können Entwickler ihre Implementierung von Microservice-Architekturen verbessern.

Google: Zum einen gibt es Traffic Director (Abbildung 2), eine von Google Cloud Platform (GCP) vollständig verwaltete Steuerungsebene für Service Mesh. Mit Traffic Director können Anwender ganz einfach das globale Load-Balancing für Cluster und VM-Instanzen in mehreren Regionen bereitstellen, die Systemdiagnose von Dienst-Proxys übertragen und präzise Richtlinien für die Steuerung des Traffics konfigurieren. Traffic Director funktioniert als offene Schnittstelle und kann in jedes System implementiert werden, ohne Anbieterbindung.

Abbildung 2: Googles Traffic Director ermöglicht unter anderem globales Load Balancing. Quelle: Google

Für umfangreiche Mikrodienst-Architekturen bieten wir Google Cloud Service Mesh (GCSM) an – im Englischen sprechen wir von “Anthos Service Mesh” –, ein ebenfalls vollständig von GCP verwaltetes Service Mesh. Zusätzlich zur Traffic-Verwaltung kann durch Funktionen wie Tracing oder Monitoring die Leistung des Service Mesh optimiert werden. Außerdem lässt sich die GCSM mit einem Zero-Trust-Sicherheitsmodell absichern.

Für containerbasierte Anwendungen mit Kubernetes Engine (GKE) ist das Istio Service Mesh verfügbar, entweder als Open-Service-Version, die in GKE installiert werden kann, oder als Addon. Letzteres befindet sich noch in der Betaversion und stellt für das Istio Service Mesh alle Komponenten bereit, die dann automatisch in GKE installiert werden. Das Addon liefert dazu ein vorkonfiguriertes Control Panel.

AWS: AWS App Mesh ist ein Service Mesh, das Netzwerke auf Anwendungsebene bereitstellt, um es Services zu erleichtern, über mehrere Typen von Computer-Infrastrukturen hinweg miteinander zu kommunizieren (Abbildung 3). App Mesh standardisiert die Kommunikation der Services, bietet durchgehende Transparenz und trägt dazu bei, die Hochverfügbarkeit von Anwendungen zu gewährleisten. Der Dienst unterstützt Microservice-Anwendungen, die für ihre Komponenten die Service Discovery verwenden. Um App Mesh verwenden zu können, muss bereits eine Anwendung existieren, die auf AWS Fargate, Amazon ECS, Amazon EKS, Kubernetes auf AWS oder Amazon EC2 läuft. Als Proxy-Komponente nutzt der Service die Open-Source-Software Envoy.

Abbildung 3: AWS App Mesh konfiguriert die Kommunikation und Überwachung für alle Services. Quelle: AWS

Wem es nützt

Linux-Magazin: Wer zieht aus Ihrer Sicht die größten Vorteile aus der Nutzung eines Service Mesh: der Endanwender, der Entwickler oder der Admin?

Cloud Foundry: Service Mesh-Technologien haben aus unserer Sicht zwei Schlüsselanwender: Entwickler und Betreiber. Für Entwickler offenbart sich die Leistungsfähigkeit eines Service Mesh vor allem durch eine vereinfachte zielorientierte Anwendungserfahrung. Unser Fokus auf die Erfahrung der Entwickler bedeutet, dass die zugrunde liegenden Service-Mesh-Funktionen in entwicklerfreundliche Plattformfunktionen einfließen.

Für Betreiber ermöglicht der Einsatz von Istio als einer Service-Mesh-Technologie innerhalb der Cloud-Foundry-Plattform verschiedene Szenarien für das Bereitstellen und Integrieren von Infrastrukturen, die Cloud-Umgebungen und Rechenzentrumsressourcen umfassen können. Es wird auch möglich, Mesh-weite Richtlinien zu implementieren, die dann alle eingesetzten Anwendungen in der Umgebung übernehmen. Die Kombination aus der Erfahrung einfacher Anwendbarkeit durch den Entwickler und voller Kontrolle für den Bediener bietet die richtige Mischung aus Benutzerfreundlichkeit und Konfigurierbarkeit.

Suse: Wir sind der Meinung, dass sowohl der Entwickler als auch der Administrator wesentlich von der Funktionalität profitieren werden. In einer idealen Welt sollte dagegen der Endbenutzer eines Kubernetes-Clusters gar nicht mitbekommen, ob der Cluster ein Service Mesh verwendet oder nicht.

Red**Hat: Wir sind fest davon überzeugt, dass der Entwickler am meisten profitiert. Mit OpenShift Service Mesh sollen die Entwicklung, Bereitstellung und das laufende Management von Anwendungen unter OpenShift vereinfacht werden.

Niemand kennt eine Codebasis so gut wie diejenigen, die sie geschaffen haben. Idealerweise sind diese Leute gleichzeitig die Administratoren und können auch aus dieser Perspektive wertvolles Feedback zur Verbesserung der Applikation geben. Allerdings stehen manchmal existierende IT-Systeme diesem Ziel im Weg. Indem man die Entwickler mit den richtigen Werkzeugen zur Kontrolle des Datenflusses in ihren Applikationen ausstattet, versetzt man sie in die Lage, den Code kontinuierlich und in Echtzeit zu verbessern. Das ist günstiger, als wenn sie den Code wieder an ein anderes Team abgeben müssten.

Google: Entwickler und Administratoren werden am meisten davon profitieren – die Entwickler, da sie die Service-Mesh-Funktionen nicht mehr selbst implementieren müssen, und die Administratoren, da sie nun über ein standardisiertes Toolset verfügen, um sicherheits- und systemverwaltungsbedingte Aufgaben ausführen zu können.

Service Mesh bietet darüber hinaus eine Reihe von Features, die jedem Nutzer zugute kommen: Der Endverbraucher profitiert von der hohen Sicherheit des Netzwerks durch die beidseitige TLS-Verschlüsselung des Service Mesh. Entwickler können über die erweiterten Funktionen wie Traffic-Verwaltung einfacher ihre Anwendungen erstellen und Blue-Green-Deployments testen. Administratoren können mit den Überwachungsmetriken in L7 den reibungslosen Ablauf ihrer Anwendungen sicherstellen.

AWS: Von der Einführung eines Service Mesh profitieren sowohl der Endbenutzer als auch der Entwickler der Anwendung und der Administrator. Dass AWS App Mesh in naher Zukunft transparente TLS-Verschlüsselung mit Zertifikaten aus dem AWS Certificate Manager unterstützen wird, macht es deutlich einfacher, eine vollständige Verschlüsselung zwischen den einzelnen verteilten Anwendungskomponenten zu implementieren, was potenziell die Sicherheit für den Endkunden erhöht.

Es ist nicht einfach, Service Discovery in verteilten Systemen effizient und hochverfügbar zu implementieren. Daher bieten Service Meshes auch für Entwickler große Vorteile, da sie diesen Aspekt auf Infrastrukturebene abbilden. Die höhere Transparenz bei der Service-Kommunikation ist sowohl für den Entwickler als auch für den Administrator ein deutlicher Vorteil gegenüber alternativen Lösungen: Metriken, Logs und Traces der Kommunikation zwischen den Services können einfach erfasst und zentral ausgewertet werden.

Wie viel Mühe es kostet

Linux-Magazin: Welchen Aufwand halten Sie für gerechtfertigt, um herkömmliche Lösungen in solche auf Basis eines Service Mesh zu transformieren? Gibt es Ihrer Meinung nach Unter- oder Obergrenzen, etwa für die Anzahl der User oder der Services?

Cloud Foundry: Für uns ist es kein eigenständiges Ziel, dass Unternehmen ihre IT-Architektur in ein Service-Mesh-basiertes Design umwandeln. Wir sehen das Ziel der Cloud-Foundry-Plattform darin, dass Entwickler schneller in die Produktion einsteigen können. Das ist die oberste Direktive unserer Gemeinschaft. Die Integration eines Service Mesh in unsere Architektur hilft dabei.

Suse: Aufgrund der schon erwähnten noch ungenügenden Marktreife von Service-Mesh-Lösungen vollzieht sich die meiste Arbeit mit Service Meshes derzeit auf experimentellem Niveau. Auf dem Markt gibt es Alpha- oder Tech-Preview-Versionen (Beta). Produktive Anwender von groß angelegten Service-Mesh-Implementierungen sind uns noch nicht begegnet.

Gleichwohl haben wir Kunden, die darum bitten, dass Suse sie beim Einsatz von Service-Mesh-Technologien unterstützt, und Suse konzentriert sich gewissenhaft darauf, ihnen dabei zu helfen, erfolgreich in diesen Bereich zu vorzudringen.

Red**Hat: Da gibt es definitiv einen kritischen Punkt im Applikationsdesign. Ebenso wie es ein Vorteil eines Service Mesh ist, ohne Eingriff in den Code zu steuern, wie Traffic in eine Applikation hinein und aus ihr heraus fließt, gibt es auch Entwurfsüberlegungen für den Fall, dass ein Benutzer bestehende Dienste umrüstet.

Mein wichtigster Rat wäre zu versuchen, das Problem zu verstehen, das man lösen will. Sobald es gilt, eine Anwendung in ein Service Mesh oder ein serverloses Modell zu überführen, neigen einige Entwickler dazu, die Funktionalität in kleinste Teile zu zerlegen. Stellt es das Ziel dar, die Flexibilität jeder Komponente zu maximieren (durch Auswahl der Sprache, der Bibliotheken und so weiter), wird es auf diese Weise erreicht – allerdings möglicherweise um den Preis einer guten Performance.

Unserer Meinung nach gilt eine der wichtigsten Überlegungen der Tiefe der Aufrufkette bei einem Request. Wer das im Hinterkopf behält, kann den Drang ausbalancieren, größere Dienste zu zerlegen, und die Auswirkungen der Latenzen zwischen den einzelnen Diensten auf die Performance berücksichtigen. Wie bei den meisten Computerherausforderungen ist das nicht neu: Das war ein Grund, warum DSR (Direct Server Return) beim Load Balancing eingeführt wurde: um nicht benötigte TCP-Hops zu entfernen. Wer diese historischen Überlegungen im Kopf behält, dem geben sie auch beim modernen Anwendungsdesign eine Orientierung.

Google:Service Mesh funktioniert mit containerisierten und traditionellen (also VM-basierten) Lösungen, sodass der Aufwand beim Wechsel ins Service Mesh vergleichsweise gering ausfällt. Was die Obergrenze des Service Mesh angeht, kann man Dienste wie Lyft oder Google als Vergleich heranziehen, denn daraus sind Service Mesh und als Teil davon auch der Envoy-Proxy entstanden. Mit der Open-Service-Version von Istio wurden bereits ausführliche Performance-Tests vorgenommen [1].

AWS: Um Anwendungen mit AWS App Mesh nutzen zu können, müssen diese bereits auf AWS Fargate, Amazon ECS, Amazon EKS, Kubernetes auf AWS oder Amazon EC2 laufen. Somit werden im Idealfall bereits entsprechende Microservices-Patterns verwendet, was die Implementierungszeit für AWS App Mesh deutlich reduziert. Am Applikationscode selbst muss keine Änderung vorgenommen werden.

Die Schritte zum Einrichten eines Service Mesh sind dabei folgende: Zuerst erstellt man das eigentliche Mesh, also einen Namensraum, der die Microservices gruppiert, die untereinander kommunizieren möchten. Als Nächstes definiert der Anwender virtuelle Knoten, um Dienste im Mesh abzubilden. Ein virtueller Knoten repräsentiert dabei eine bestimmte Microservices-Version. Dann werden die Dienste mit dem notwendigen Envoy-Proxy ausgerollt, was jeden Dienst einem Knoten im Mesh zuweist.

App Mesh macht es einfach, Transparenz und Kontrolle über die Kommunikation zwischen Diensten zu erlangen, ohne neuen Code zu schreiben oder zusätzliche AWS-Infrastrukturen zu nutzen. Mit der Mesh-Implementierung lässt sich die Kommunikation zwischen Diensten standardisieren, und man kann Regeln für die Kommunikation zwischen Diensten implementieren und Metriken, Logs und Traces direkt in AWS-Diensten und Tools von Drittanbietern erfassen. Das vereinfacht viele Aspekte für den robusten Betrieb einer verteilten Anwendung deutlich. AWS App Mesh bietet somit für jede nicht-triviale Architektur Vorteile.