Komplexe Microservice-Architekturen vereinfachen 7 „Service Mesh“-Lösungen im Überblick

Anbieter zum Thema

EPS Rechenzentrum Infrastruktur GmbH

Die lose Kopplung unabhängiger Microservices birgt Herausforderungen. Daher resultiert die Idee des Service Mesh, um gemeinsame Funktionalitäten von der Anwendungs- in die Infrastrukturschicht auszulagern. Doch wie ist der aktuelle Stand der Technik?

Viele unterschiedliche Anforderungen an eine Microservice-Architektur werden oft in den einzelnen Microservice-Anwendungen implementiert. Dies betrifft unter anderem Security, Logging, Tracing, Circuit Breaking oder Monitoring. Dies geht allerdings zu Lasten der Kommunikation.

Zwar kann man sich hierbei bestimmten Bibliotheken oder Frameworks bedienen. Dennoch schafft es unnötigen Mehraufwand für die Entwickler eines Projekts. Außerdem würde man sich an bestimmte Programmiersprachen oder Technologien binden, was dem eigentlichen Gedanken einer technologieoffenen Microservice-Architektur widerspricht.

Was ist ein Service Mesh?

Hier setzt das Service Mesh an, dessen generelle Architektur aus zwei Teilen oder der wortgetreuen Übersetzung nach aus zwei Ebenen besteht: der Control Plane und der Data Plane.

Die Data Plane besteht aus Proxies, welche ebenso als Reverse-Proxies fungieren. Die gesamte Kommunikation der einzelnen Microservices läuft über diese Proxies, welche z.B. in einem Kubernetes Cluster als Sidecar in einem Docker Container eines Pods „neben“ dem Container des Microservices laufen.

Deshalb wird das Service Mesh auch oft als eine Erweiterung des Sidecar-Patterns bezeichnet. Dabei vermitteln die Proxies die Kommunikation sowohl zwischen den einzelnen Microservices, als auch mit der Control Plane.

Die Control Plane besteht aus unterschiedlichen Managementkomponenten, die sich je nach Service Mesh Implementierung unterscheiden. Diese Komponenten bieten jeweils bestimmte Funktionalitäten wie z.B. Service Discovery an, oder greifen Daten von den Proxies aus der Data Plane ab. Diese Daten werden dann aufbereitet, und dem Anwender über eine API oder GUI zur Verfügung gestellt.

Was sind die Vorteile?

Ein Service Mesh verspricht viele Vorteile, um der Komplexität von Microservice-Architekturen entgegenzuwirken. Somit wird versucht, Komplexität von der Anwendungs- auf die Infrastrukturebene zu verschieben. Insbesondere in folgenden Bereichen werden Verbesserungen bzw. Vereinfachungen erwartet:

• Routing: Service Discovery, Load Balancing, Routing Konfiguration

• Observability: Monitoring, Metriken, Tracing, Logging

• Resilienz: Timeout, Retry, Circuit Breaker

• Security: Verschlüsselung der Kommunikation zwischen den Microservicen mit mTLS, Ausstellung von Zertifikaten mit eigener CA

Die genauen Features eines Service Mesh unterscheiden sich natürlich zwischen den jeweiligen Implementierungen. Auch die Art und Weise, wie die einzelnen Techniken umgesetzt und welche Tools dafür genutzt werden, ist unterschiedlich.

Gibt es auch Nachteile?

Wo viel Licht ist, ist natürlich auch Schatten. Durch den massiven Einsatz von Proxies, wodurch jedem Aufruf zwei Hops auf den Proxies hinzugefügt werden, erhöht sich die Latenz entsprechend bei der Kommunikation zwischen den Microservices. Deshalb ist es entscheidend, dass die Proxies möglichst schnell sind, dabei allerdings auch klein und leichtgewichtig. Denn jeder Proxy und jede Komponente der Control Plane verbrauchen Speicher- und CPU-Ressourcen, was wiederum zusätzliche Kosten verursacht.

Zumindest initial kommt es außerdem zu einem erhöhten Konfigurationsaufwand: Ein Service Mesh einzurichten, zu konfigurieren und das Deployment zu automatisieren, ist in der Regel keine triviale Angelegenheit. Dazu kommt noch der kognitive Lernaufwand, um die neuen Technologien zu beherrschen.

Welche Implementierungen gibt es?

Der Markt für Service-Mesh-Implementierungen wird zunehmend unübersichtlicher. Aufgrund der gestiegenen Popularität und des Potenzials, das in Service Meshes liegt, versuchen immer mehr große Firmen eigene Lösungen zu entwickeln oder beteiligen sich an der Definition von Schnittstellen.

Istio

Istio ist das wohl bekannteste und am weitesten verbreitete Service Mesh. Von Google, IBM und Lyft als Open Source Projekt entwickelt, wird es vor allem von Google stark beworben. Istio kann in einem Kubernetes Cluster verwendet werden, ist aber nicht darauf beschränkt.

Als Proxy in der Data Plane kommt eine weiterentwickelte Version von Envoy zum Einsatz, was viele Features ermöglicht:

• Dynamic Service Discovery

• Load Balancing

• TLS termination

• HTTP/2 und gRPC Proxies

• Circuit Breaking

• Health Checks

• Fault Injection

• Metriken

In der Data Plane wird Istiod verwendet, welches die Proxies konfiguriert und die Kommunikation zwischen ihnen steuert. Istiod unterstützt unterschiedliche Service Discovery Umgebungen wie Kubernetes, Consul oder einzelne VMs. Darüber hinaus bringt Istiod sein eigenes Identity Management mit, wodurch sich eine Lösung für die Authentifizierung und Autorisierung umsetzen lässt.

Über eine Zertifizierungsstelle können auch eigene Zertifikate erstellt werden, wodurch sich eine komplett verschlüsselte mTLS Kommunikation zwischen den einzelnen Microservices erreichen lässt. Grafana Dashboards, Monitoring mit Prometheus und Jaeger als Tracing-Lösung runden die sehr umfangreichen Features ab.

Linkerd

Linkerd gilt als das erste zur Verfügung stehende Service Mesh und wird von der Cloud Native Computing Foundation (CNCF) als Open-Source-Projekt bereitgestellt. Ab der Version 2 wurde Linkerd komplett für Kubernetes optimiert und kann nur noch zusammen mit Kubernetes betrieben werden.

Es umfasst eine Proxy-Eigenentwicklung in der Programmiersprache Rust, welche eine höhere Geschwindigkeit verspricht als Envoy-basierte Proxies. Auch wenn Linkerd bewusst leichtgewichtig und auf Performanz ausgelegt entwickelt wurde, ist die Featureliste lang und braucht sich kaum noch vor Istio verstecken:

• HTTP, HTTP/2 und gRPC Proxying

• Retries und Timeouts

• Automatisches mTLS

• Telemetrie und Monitoring

• Load Balancing

• Automatische Proxy Injection

• Fault Injection

• Distributed Tracing

• Traffic Split (canaries, blue/green deploys)

• Dashboard und Grafana

Zusätzlich zu Grafana Dashboards bietet Linkerd auch ein eigenes Dashboard zum Überwachen der Metriken an. Außerdem unterstützt es jetzt auch Distributed Tracing, wofür allerdings Änderungen am Code nötig wären.

Consul Connect

Ursprünglich als Service-Discovery-Lösung entwickelt, bezeichnet sich Consul von HashiCorp mittlerweile als kompletten Service Mesh. Dabei bringt Consul Connect zwar seine eigene Proxy-Implementierung mit, diese ist aber vergleichsweise einfach gehalten und unterstützt nur Layer 4 TCP Verbindungen. Allerdings ist es auch möglich, z.B. Envoy oder andere Lösungen als Proxy zu verwenden, da die Data Plane bei Consul austauschbar ist. Consul umfasst u.a. folgende Features:

• Service Discovery

• Health Checking

• Key Value Store

• Secure Service Communication (mTLS)

• Multi Datacenter

Auch wenn sich Consul Connect als vollwertiges Service Mesh versteht, fehlen hier doch einige wichtige Features, vor allem was Resilienz betrifft. Observability-Features lassen sich z.B. mit Envoy Proxies und Prometheus nachrüsten.

Kuma

Kuma ist noch ein relativ junges Open Source Sandbox-Projekt der CNCF und wurde ursprünglich von der Kong Inc. ins Leben gerufen. Es kann in Kubernetes, VMs oder Bare Metal Umgebungen eingesetzt werden. Kuma benutzt auch Envoy Proxies, implementiert aber eine eigene Control Plane mit einer selbst entwickelten graphischen Oberfläche.

Kuma bietet folgende Features:

Security: Identity, Encryption, Compliance

• Mesh / Multi-Mesh

• mTLS

• Traffic Permissions

Traffic Control: Routing, Ingress Failover

• Traffic Route

• Health Check

• Circuit Breaker

• Fault Injection

• Kong Gateway

Observability: Metrics, Logs, Traces

• Traffic Metrics

• Traffic Trace

• Traffic Log

Kuma ist auch im Kong Mesh 1.0 als Teil der Kong Enterprise Distribution enthalten.

OpenShift Service Mesh

Red Hat bietet unter dem Namen Red Hat OpenShift Service Mesh eine Erweiterung von Istio an. Zusätzlich zu den Features von Istio kommen hier folgende Eigenschaften hinzu:

• Eine Mehrmandanten-Kontrollschicht wird standardmäßig installiert

• Die Role Base Access Control wird erweitert

• BoringSSl wird durch OpenSSL ersetzt

• Kiali und Jaeger sind standardmäßig aktiviert

AWS App Mesh

Auch Amazon bietet mit dem AWS App Mesh eine Service Mesh Lösung an, die sich mit einer Vielzahl an AWS-Services integrieren lässt. Dabei setzt auch Amazon auf Envoy in der Data Plane, lässt sich also auch mit kompatiblen Tools wie Prometheus, Grafana oder Zipkin kombinieren.

Service Mesh Interface (SMI)

Ein weiteres Sandbox-Projekt der CNCF ist das „Service Mesh Interface“. Dabei handelt es sich nicht um eine Service-Mesh-Implementierung an sich, sondern um eine offene API-Spezifikation für Service-Mesh-Implementierungen auf Kubernetes. Es soll eine bessere Interoperabilität zwischen verschiedenen Service-Mesh-Technologien wie Istio, Linkerd und Consul Connect sicherstellen. Der Fokus liegt auf der Definition von APIs für die häufigsten Anwendungsszenarien von Service Meshes:

• Traffic Policy

• Traffic Telemetry

• Traffic Management

Fazit

Ein Service Mesh ergibt in vielerlei Hinsicht Sinn. Die Vorteile durch die erhöhte Transparenz und Kontrolle über eine Microservice-Architektur sind unbestritten und lassen sich auch in bereits bestehende Systeme integrieren. Die Entkopplung der operativen Funktionen von der Anwendung reduziert den Overhead bei der Microservice-Entwicklung, wodurch man sich in den Microservices auf die Businesslogik konzentrieren kann.

Man sollte allerdings auch die Nachteile wie die erhöhte Latenz und den erhöhten Hardwareverbrauch nicht außer Acht lassen. Zudem bedeutet ein reduzierter Aufwand auf der Entwicklerseite in diesem Fall auch ein erhöhter Aufwand für den Betrieb und die Konfiguration.

Schließlich muss man abwägen, für welche der zur Verfügung stehenden Service Mesh Implementierungen man sich entscheidet. Die meisten Implementierungen lassen sich sicherlich auch in Produktion bedenkenlos einsetzen, der Reifegrad vor allem der bekannteren Exemplare spielt zunehmend kaum noch eine Rolle. So kann man sich bei der Auswahl auf die wichtigsten Features beschränken, die die Anforderungen der jeweiligen Architektur erfüllen.

Aus dem anfänglichen Hype scheint also mittlerweile Realität zu werden. Der nächste Schritt nach der Containerisierung von Anwendungen mit Docker und ihrer Orchestrierung mit Kubernetes, scheint mit einem Service Mesh gemacht zu werden.

* Nico Westerheide arbeitet als Senior Full Stack Developer bei Ultra Tendency. Nach seinem Informatikstudium in Paderborn hat er sich auf den Entwurf und die Entwicklung von Microservice-Architekturen auf Basis von Java-Technologien spezialisiert. Er verfügt über langjährige Projekterfahrung im internationalen Umfeld und beschäftigt sich gerne mit Technologien rund um das Thema Microservices.

(ID:46835298)