Seite 4: Sind Self-contained Systems meshbar?

Inhaltsverzeichnis

Die gerade beschriebenen Konsequenzen von asynchroner Kommunikation gelten ebenfalls für SCS, die klassischerweise untereinander asynchron kommunizieren. Da jedes SCS allerdings eine eigene Frontend-Komponente mitbringt, profitieren SCS von den komplexen Routing-Regeln eines Service-Mesh, die Canary Releasing und A/B-Tests ermöglichen. Eine Clientanfrage, die den Server erreicht, vermitteln die Service-Mesh-Proxys an ihr Ziel, sodass Routing-Regeln und Resilienz-Maßnahmen feingranularer als bei klassischen Microservices möglich sind (siehe Abb. 5).

Wenn alle SCS nur aus einer Web-App bestehen (wie SCS A), ist die Situation die gleiche wie bei asynchronen Microservices. Jede Instanz jedes SCS bekommt einen Service-Proxy, der Mesh kann sie folglich überwachen und steuern. Sobald ein SCS allerdings in mehrere Microservices aufgeteilt ist, sind zwei Ansätze denkbar:

1. Ein Service-Proxy pro SCS (Service-Mesh zwischen SCS, Mitte in Abb. 5)
2. Ein Service-Proxy pro Microservice (Service-Mesh zwischen Microservices, rechts in Abb. 5)

Ein Service-Proxy pro SCS ist sinnvoll, wenn man alle Microservices eines SCS als Einheit betrachtet und nur zusammen (beispielsweise in einem Kubernetes Pod) deployt und skaliert. Zwischen SCS gilt in dem Fall alles, was für asynchron kommunizierende Microservices stimmt: Monitoring- und mTLS-Funktionen eines Service-Mesh können sinnvoll zum Einsatz kommen.

Bestehen SCS allerdings aus mehreren klassischen Microservices, die über das Netzwerk kommunizieren (z.B. SCS B), ist ein Service-Proxy pro Microservice-Instanz (Abb. 6 rechts) die bessere Wahl. Denn so können die Microservices von der gesamten Funktionspalette eines Service-Mesh, also Observability, Routing, Resilienz und Sicherheit, profitieren. Um SCS-übergreifende Aufrufe zu beschränken, können Entwickler mit einem Service-Mesh beispielsweise Autorisierungsregeln formulieren und umsetzen.

Es ist kompliziert: Service-Mesh-Implementierungen

Ein Service-Mesh kann in Microservice-Architekturen und SCS sinnvoll sein, um grundlegende, konsistente Transparenz, Sicherheit und eventuell Routing und Resilienz ohne Codeänderungen zu erreichen. Allerdings sind Service-Mesh-Implementierungen noch sehr unterschiedlich, was ihre Features, Reife und Benutzbarkeit angeht. Die beiden wichtigsten sind die Open-Source-Projekte Istio, das Google und IBM entwickelt haben sowie das CNCF-Projekt (Cloud Native Computing Foundation) Linkerd.

Istio beeindruckt durch die Vielzahl an Features und die Flexibilität der Konfiguration. Das ist auch der Nachteil: Die Konfigurationsoptionen von Istio zu durchschauen ist eine echte Herausforderung, auch wenn die Community mit jedem Release nachbessert. Immerhin ist die Dokumentation jedoch ausführlich. Sie versucht nicht zu verbergen, dass das Projekt in erster Linie auf Kubernetes zugeschnitten ist. Allerdings möchte sich Istio in kommenden Releases weiter für andere Umgebungen wie Nomad und Consul öffnen.

Linkerd unterstützt die asynchrone Kommunikation relevanter Kernfunktionen wie Basis-Monitoring und mTLS sowie die Anwendung von Routing-Regeln, Timeout und Retry. Features wie Tracing und Circuit Breaking, die man abhängig von der Architektur sinnvoll einsetzen kann, sind mit Linkerd noch nicht umsetzbar (siehe Abb. 6). Dafür ist die Konfigurations-API gut durchdacht und einfach zu nutzen. Viele Tests (z. B. 1, 2 und //github.com/kinvolk/Service-Mesh-benchmark 3) bescheinigen Linkerd außerdem einen geringeren Ressourcenverbrauch und eine geringere Beeinträchtigung der Antwortzeit. Linkerd ist nur für Kubernetes verfügbar.

Abbildung 6 zeigt eine detaillierte Gegenüberstellung der Features von Istio 1.2 und Linkerd 2.4.

Beide Projekte sind offiziell reif für den Produktionsbetrieb. Wie bei allen Infrastrukturkomponenten ist es allerdings empfehlenswert, erste Erfahrungen in einem Testsystem zu sammeln. Da an beiden Projekten intensiv entwickelt wird, lohnt es sich, neue Releases und Blogbeiträge zu verfolgen.