Die Stärke einer Microservices-Architektur ist die lose Kopplung der Module. Und gleichzeitig ist diese auch ein großer Nachteil, denn in jedem Microservice müssen Funktionen wie Monitoring, Tracing und Circuit Breaking erneut gelöst werden. Ein Service Mesh verspricht, viele der Funktionen in die Infrastruktur zu ziehen. So wird es endlich kinderleicht, Microservices zu entwickeln und zu bändigen – oder vielleicht doch nicht?

Microservices bedeuten Unabhängigkeit [1]-[4]. Also legen die Teams los und es entstehen viele Microservices. Nach dem ersten Problem in Produktion wird klar: Alle Microservices brauchen Logging, Monitoring und Tracing. Um Angriffen vorzubeugen, muss die Kommunikation außerdem authentifiziert und verschlüsselt werden. Eine weitere Herausforderung ist es, die Services vor den Effekten von jederzeit möglichen Netzwerk- oder Service-Ausfällen zu schützen.

Bitte keine Microservices Frameworks

Was tun? Für Entwickler liegt es nahe, technische Probleme mit einem Framework zu lösen. Ein Microservices Framework hat jedoch den Nachteil, dass es nur eine bestimmte Programmiersprache unterstützt. Das schränkt die Auswahl der Implementierungstechnologien für die Microservices ein. Damit gibt das Team eine große Stärke der Microservices auf, nämlich die Technologiefreiheit. Diese Freiheit erlaubt es, für jeden Microservice die beste Technologie zu wählen. Wenn ein anderer Technologiestack oder eine Programmiersprache für ein Detailproblem in einem System besser geeignet ist, kann man diese Technologie einfach in dem betreffenden Microservice für diese Detailprobleme einführen. Wenn die Microservices-Bibliothek mit der neuen Programmiersprache oder dem neuen Technologiestack inkompatibel ist, ist dieser Weg leider unmöglich.

Auch für einen einheitlichen Technologiestack ergibt die Technologiefreiheit Vorteile. Jeder Stack veraltet früher oder später. Durch die Technologiefreiheit kann ein Update auf eine neue Version des Technologiestacks oder einer Bibliothek zunächst in einem einzigen Microservice umgesetzt werden, was das Risiko minimiert. So helfen Microservices dabei, ein System risikoarm modern zu halten. Wenn nun das Microservices Framework mit der neuen Version des Technologiestacks oder der Bibliothek inkompatibel ist, wird das Update entweder erschwert oder ist völlig unmöglich.

Unabhängig davon, ob die technischen Herausforderungen mit Microservices Frameworks oder anders gelöst werden, hat die Entscheidung erhebliche Konsequenzen. Der Netflix-Stack enthält beispielsweise die Java-Bibliothek Hystrix [5], mit der die Kommunikation zwischen Microservices bei Ausfällen einzelner Microservices abgesichert werden kann. Leider pflegt Netflix diese Bibliothek aber mittlerweile nicht mehr. So wird Code, der diese Bibliothek noch nutzt, plötzlich zu veraltetem Code, der nun so umgeschrieben werden muss, dass er die Bibliothek nicht mehr nutzt.

Was ist ein Service Mesh?

Microservices, die ein Service Mesh nutzen, können auf viele Bibliotheken verzichten. Dazu gehören insbesondere Monitoring-, Tracing- und Circuit-Breaking-Bibliotheken, die bisher von allen Microservices benötigt wurden. Ein Service Mesh hebt diese und weitere Funktionen von der Anwendungs- auf die Infrastrukturebene. Das ist bei weitem nicht das erste Konzept mit diesem Ziel, aber das erste, das dem dezentralen Ansatz einer Microservices-Architektur folgt. Während andere Lösungen wie API-Gateways auf zentralen Komponenten basieren, stellt ein Service Mesh jeder Instanz eines Microservice eine zusätzliche Anwendung zur Seite, in der beispielsweise Monitoring und Circuit Breaking implementiert sind. Die Microservice-Instanz und diese Anwendung können über den localhost miteinander kommunizieren. Dieses Pattern wird Sidecar (Beiwagen) genannt. Jegliche eingehende und ausgehende Kommunikation der Microservice-Anwendung verläuft über die als Sidecar bereitgestellte Anwendung, die deshalb auch als Service Proxy bezeichnet wird. Um den Verkehr automatisch an die Service Proxies zu lenken, können Netzwerkkonfigurationen vorgenommen werden, sodass die Microservices völlig unverändert bleiben.

Ein Service Mesh besteht, wie Abbildung 1 zeigt, aus zwei Ebenen,...