Von Usability und Features – Service Meshes im Vergleich

In den letzten Jahren rückt die Infrastruktur stärker in den Fokus der Softwareentwicklung. Auslöser ist der Trend hin zu Microservices: die Unterteilung von Anwendungen in kleine, voneinander unabhängig ausrollbare Einheiten. Dieses Vorgehen bringt eine Menge Vorteile: Einzelne Services sind übersichtlicher und lassen sich daher schneller entwickeln. Die Aufteilung auf mehrere Teams gelingt besser. Die Stabilität des Systems steigt, weil der Ausfall eines einzelnen Service nicht den Ausfall des gesamten Systems bedeutet.

Damit entstehen aber verteilte Anwendungen, die mit neuen Herausforderungen kämpfen müssen: Netzwerke sind instabil, Server fallen aus oder einzelne Teile einer Anwendung sind zeitweilig nicht erreichbar. Daher werden Rollouts erheblich komplexer. Diese Aspekte direkt in den Services zu lösen, führt zu einem überraschend hohen Aufwand. Zudem machen gemeinsame Abhängigkeiten von Bibliotheken viele Vorteile unabhängiger Micro­services wieder zunichte.

Service Meshes versuchen, die Infrastrukturprobleme von Microservices zu beheben, indem sie den Diensten Komponenten zur Seite stellen, die sich um die angesprochenen Herausforderungen kümmern – ohne dass der Service selbst etwas davon wissen muss. Das geschieht normalerweise über Proxys, die den Netzwerkverkehr zwischen den Services steuern. Diesen Teil eines Service Mesh nennt man die Data Plane. Da dadurch sehr viele Proxys installiert werden, wird es notwendig, diese zentral zu konfigurieren. Das übernimmt die Control Plane. Sie ist außerdem dazu in der Lage, Metriken von den einzelnen Services zu sammeln und zentral bereitzustellen. Die Control Plane fragt den aktuellen Zustand der Microservice-­Anwendung regelmäßig über die APIs der zugrunde liegenden Infrastruktur wie Kubernetes, Consul oder Cloud-Provider wie AWS ab. Außerdem kann sie für alle Microservice-Instanzen automatisch Proxys hinzufügen, was die komplexe Architektur handhabbar macht.

Die Idee von Service Meshes ist deswegen so verlockend, weil sie diese He­rausforderungen von Microservices auf der Ebene der Infrastruktur lösen, die weitgehend unabhängig von der Anwendungslogik ist. Entsprechend viele Implementierungen sind in den vergangenen Jahren entstanden. 2019 erschienen neue Projekte teilweise im Monatsrhythmus.

Aktuelle Service-Mesh-Implementierungen

Nicht alle gestarteten Kandidaten existieren noch, dennoch ist die Liste ziemlich lang. Zu den aktuell aktiven Projekten zählen:

• Linkerd 2
• Istio
• AWS App Mesh
• HashiCorp Consul Connect
• Maesh
• Kuma

Linkerd 2 und sein Vorgänger Linkerd werden von Buoyant entwickelt, einer Firma von ehemaligen Twitter-Entwicklern. Motivation für die Entwicklung waren vor allem die Erfahrungen mit Microservices und dem bei Twitter entwickelten RPC-Frame­work Finagle. Während die erste Version von Linkerd noch völlig unab­hängig von der Containerinfrastruktur entstand, setzt die zweite Version konsequent auf Kubernetes als Unterbau.

Istio ist die Fusion zweier Projekte bei Google und IBM (siehe ix.de/ztys). Ähnlich wie bei Kubernetes sollten die internen Erfahrungen in ein Open-Source-­Projekt übergehen. Beim Service-Proxy fiel die Wahl auf Envoy von der Firma Lyft. Erst der Hype um Istio hat wohl zu der Entwicklung vieler anderer Service ­Meshes geführt. Das Projekt befindet sich momentan im Umbruch. Ziel ist eine deutliche Vereinfachung sowohl der Architektur als auch der Konfiguration.

AWS App Mesh ist Amazons Antwort auf Istio. Es setzt ebenfalls auf Envoy in der Data Plane und integriert sich AWS-­typisch in die Landschaft der Cloud-Dienste von Amazon. Dabei setzt es Kubernetes nicht voraus, lässt sich aber auch innerhalb eines solchen Clusters nutzen.

Beim Thema Service Discovery ist Hashi­Corp Consul seit Jahren ein etabliertes Produkt. Insofern war es ein logischer Schritt, diese Infrastruktur um Funktionen eines Service Mesh zu erweitern. HashiCorp nennt das entstandene Produkt Consul Connect. Auch hier kommt typischerweise Envoy zum Einsatz, jedoch lassen sich bei Bedarf andere Proxys integrieren. Auch Consul muss nicht zwangsläufig innerhalb von Kubernetes laufen.

Die Service Meshes Kuma und Maesh stammen von Firmen, die API-Gateways beziehungsweise Reverse-Proxys entwickeln. Da diese ähnliche Probleme lösen, ist die Erfahrung leicht auf Service Meshes übertragbar. Dass Istio wiederum auch einige Funktionen eines API-Gateway übernimmt, kann ebenfalls eine Moti­vation für die Entwickler*innen von API-Gateways sein, selbst in diesem Markt aktiv zu werden. Beide Produkte sind noch recht neu auf dem Markt. Ob sie ihren Platz neben den etablierten Playern finden, bleibt abzuwarten.

Große Unterschiede beim Aufbau

Je nach Blickwinkel unterscheiden sich Service Meshes in Bezug auf Architektur und Umsetzung, beispielsweise bei der Wahl des Proxys. Die meisten Service ­Meshes setzen Envoy ein. Darin sind bereits viele typische Funktionen eines Service-­Mesh-Proxys implementiert und durch eine umfangreiche API konfigurierbar. Andere Proxys werden aus verschiedenen Motivationen genutzt. So setzt Linkerd 2 auf eine Rust-basierte Eigenentwicklung. Hier stehen Performance und Sicherheit im Vordergrund. Maesh setzt selbstverständlich auf Traefik, weil es ein wichtiges Produkt des Anbieters ist.

Die Gruppierung nach der Abhängigkeit von Kubernetes wurde oben bereits erwähnt. Hier setzt ein Teil der Meshes konsequent auf Kubernetes als Basisplattform, was das Implementieren des Service Mesh deutlich vereinfacht. Andere versuchen sich hingegen dadurch zu positionieren, dass diese Abhängigkeit nicht besteht.

Auch das Verhältnis zwischen Microservice und dem Mesh-Proxy unterscheidet sich zwischen den Implementierungen. Viele Service Meshes ergänzen einen Proxy pro Serviceinstanz, den sie bei Kubernetes im gleichen Pod platzieren.

Bei anderen Implementierungen wie Maesh existiert hingegen nur ein Proxy pro Host im Cluster. Dieser dient dann potenziell den Instanzen verschiedener Micro­services. Das führt zwar zu geringerem Ressourcenverbrauch, beherrscht aber das weiter unten erläuterte Feature mTLS nicht.

Ein umgekehrtes Extrem stellt Istio dar, das sogar die Kontrolle über in den Cluster eingehende – und optional ausgehende – Verbindungen übernimmt. Dies bietet mehr Features, schränkt aber die Kompatibilität zu vorhandenen Paketen/Komponenten ein. Abbildung 2 verdeutlicht diese Unterschiede.