Ordnung im Service Mesh
Dschungellauf
Kleine und unabhängige Deployment-Einheiten lösen große, monolithische Systeme immer mehr ab. Bei aller Microservices-Euphorie gibt es allerdings einen Haken: Die Vielzahl von Services, die sich gegenseitig aufrufen, wird schnell zu einem unübersichtlichen und dichten Dschungel.
Existierende Services vollständig durch neue zu ersetzen, ist in der Microservices-Theorie problemlos möglich. Entwickler möchten die veralteten Schnittstellen zügig aus dem Service entfernen, um nicht Code warten zu müssen, der sich eigentlich löschen ließe. In der Praxis ist das aber oft nicht möglich, da die aufrufenden Services noch Abhängigkeiten zu diesen alten Schnittstellen haben. Wenn der Serviceaufrufer einem anderen Projekt oder sogar einer anderen Firma zugeordnet ist, existieren in Produktion mehrere Versionen eines Service parallel. Die hohe Anzahl individueller Services zusammen mit dem Parallelbetrieb von unterschiedlichen Versionen eines Service treibt die Zahl der zu pflegenden Microservices und ihrer Abhängigkeiten untereinander in die Höhe. Das dabei entstehende Geflecht wird als Service Mesh bezeichnet. Früher oder später können die Entwickler den Servicedschungel ohne ein geeignetes Werkzeug nicht mehr verwalten.
Werkzeuge für das Service Mesh
Werkzeuge wie Istio und Linkerd sollen helfen, die Komplexität von Service Meshes in den Griff zu kriegen. Sie überwachen und steuern die Kommunikation zwischen den einzelnen Diensten, sorgen für die Durchsetzung von Sicherheitsregeln, erkennen und beheben Fehlfunktionen und liefern Entwicklern Informationen über den Zustand des Service Mesh. Dazu stellen sie jedem Service einen Envoy Proxy zu Seite, über den die Kommunikation von und zu diesem Service abgewickelt wird. Der Datenaustausch zwischen den Proxys und damit den Services erfolgt über die Data Plane. Daneben existiert eine Control Plane, die für die Integration mit der Laufzeitumgebung des Service Mesh sowie für die Konfiguration, die Verwaltung und das Monitoring der Proxys zuständig ist. Die Control Plane besteht aus Komponenten, die zur Integration mit der darunterliegenden Laufzeitumgebung, zum Beispiel Kubernetes, notwendig sind (Abbildung 1). Darüber hinaus enthält die Control Plane Verwaltungs- und Monitoringkomponenten, mit denen das Service Mesh gesteuert und überwacht wird.
Die Data Plane setzt sich aus den selbst implementierten Services und den Sidecars oder Proxys zusammen. Das Verhalten des Proxy und somit dessen Existenz ist für den zugehörigen Service komplett transparent. Zur Steuerung des Service Mesh erhält der Proxy die notwendigen Anweisungen von der Control Plane. Im Gegenzug liefert er Laufzeitinformationen an die Control Plane, damit diese die richtigen Entscheidungen treffen kann, um das Mesh zu steuern und zu überwachen.
Den Proxy als Sidecar zu realisieren, verschafft der Service-Mesh-Architektur einen entscheidenden Vorteil. Änderungen am Verhalten des Service und damit am gesamten Service Mesh betreffen nur den Proxy. Das Service Mesh kann dynamisch, ohne Neustart des Proxy, neue Kommunikationsregeln von der Control Plane empfangen und sofort umsetzen. Außerdem ist es durch die Trennung von Proxy und Service nicht notwendig, für jede mögliche Serviceprogrammiersprache eine Proxy-Implementierung bereitzustellen.
Da jede Form der Kommunikation durch den Proxy geleitet wird, kann sich das negativ auf die Latenz auswirken. Um diesen Nachteil so weit wie möglich zu kompensieren, ist der Proxy, der bei Istio zum Einsatz kommt, in C++ programmiert. Außerdem laufen jede Nacht Performanzmessungen ab, um möglichst schnell schleichende Verschlechterungen zu erkennen. Der zweite gravierende Nachteil ist die zusätzliche an der Kommunikation beteiligte Komponente. Der Ausfall eines Proxy würde den Service unerreichbar machen. Hierbei bekommt der Proxy Hilfe von der Laufzeitumgebung, etwa Kubernetes.