Je größer und verflechteter eine Microservice-Architektur wird, desto unübersichtlicher wird es. In der Entwickler-Welt kommt hier oftmals ein "Service Mesh" zum Einsatz. Während Istio lange als Platzhirsch unter den Service Mesh Tools galt, machen ihm Mitbewerber wie MicroProfile und Linkerd den Platz streitig. Doch worin liegen eigentlich die Unterschiede und welches ist das passende Services Mesh Tool für meine Anwendung? Diesen Fragen widmet sich Michael Hofmann in seinem Talk auf der W-JAX 2019.

Wer Michael Hofmann einmal live erleben möchte, der hat bei der diesjährigen W-JAX 2019 in München wieder Gelegenheit dazu. Dort wird er mit gleich zwei Talks vertreten sein. Michael wird dort zum einen eine Session zum Thema, „Service Mesh mit Istio und MicroProfile“ halten und zeigen, wie diese beiden Welten in einer Cloud-native-Anwendung am besten miteinander kombiniert werden können.

Wie Service Mesh Tools dabei helfen können, die Komplexität von Services Meshes in den Griff zu bekommen, vermittelt der zweite Vortrag von Michael zum Thema “Service Mesh — Kilometer 30 im Microservices-Marathon“.

Redaktion: Hallo Michael und danke, dass du dir die Zeit für das Interview genommen hast. In deinen Sessions auf der W-JAX 2019 sprichst unter anderem über Microservices. Haben Microservices eigentlich tatsächlich einen Vorteil gegenüber großen Monolithen?

Michael Hofmann: Will man im Projekt eine höhere Release-Frequenz erreichen, so bieten die Microservices durch ihre Größe einen klaren Vorteil. Es werden wiederholt nur kleine Teile des gesamten Systems in Produktion genommen, was mit einem Monolithen nur schwer möglich ist. Auch der Wechsel auf einen neuen Technologie-Stack ist in den einzelnen Microservices einfacher zu realisieren, da jeder Service für sich allein, ohne große Auswirkungen auf andere Services, auf den neuen Stack umgestellt werden kann.

Redaktion: Istio ist relativ neu, aber gewinnt zunehmend an Aufwind. Was ist der Grund für das Wachstum?

Hinter Istio steht mit Google und IBM eine mächtige Open-Source-Community, was Nachhaltigkeit und Fortschritt zugleich verspricht.

Michael Hofmann: Zum einen steht hinter Istio mit Google und IBM eine mächtige Open-Source-Community (ca. 430 Contributors laut CNCF Landscape) was Nachhaltigkeit und Fortschritt zugleich verspricht. Damit werden mehr Features pro Release veröffentlicht aber auch die Reaktion der Istio-Community auf Bugs erfolgt sehr zeitnah. Darüber hinaus beginnen nun verschiedene Hersteller oder Cloud-Betreiber, Istio teilweise oder sogar komplett in Ihre Produkte zu integrieren. Das Spektrum reicht von CloudFoundry, über Google und IBM bis hin zu OpenShift. Weitere Cloud-Betreiber (wie beispielsweise Azure) beschreiben zumindest sehr ausführlich, wie Istio in ihre Cloud-Umgebungen integriert werden kann.

Redaktion: Wo von Istio die Rede ist, ist Kubernetes meist nicht weit: Hat Istio das Zeug dazu, der de facto Service Mesh für Kubernetes zu werden?

Michael Hofmann: Fairerweise muss man sagen, dass es auch noch weitere Mitbewerber im Service-Mesh-Markt gibt. Von daher ist es schwer zu sagen, wer am Ende das Rennen machen wird. Bei Istio sind meiner Meinung nach viele Vorraussetzungen gegeben, die dazu notwendig sind, um im Markt einen gewichtigen Anteil zu erreichen. Zur Zeit sehe ich neben Istio und Linkerd auch noch kleinere Mitbewerber, die eine Alternative bieten. Dies erfolgt jedoch meist mit einem reduzierten und somit spezialisierteren Funktionsumfang.

Redaktion: Was ist Dein Lieblingsfeature in Istio?

Michael Hofmann: Das ist schwer zu sagen, da Istio eine Menge nützlicher Features bietet. Aktuell bin ich davon begeistert, wie einfach es ist, mit Istio die Resilienz in der Service-Kommunkikation zu testen. Die Simulierung einer verzögerten Antwortzeit oder der sporadische Ausfall von Kommunikations-Partnern ist ohne Istio, nur sehr schwer zu automatisieren. Meist sind Code-Anpassungen in den Services notwendig, was aber in meinen Augen unbedingt vermieden werden sollte. Mit Istio habe ich hierfür eine sehr elegante Möglichkeit: Durch Aktivieren einer entsprechenden Istio-Regel kann ich jedes beliebige Fehlerverhalten hervorrufen, ohne irgendeine Zeile Code im Service zu ändern. Nach dem Test kann diese Istio-Regel einfach wieder gelöscht werden.

Redaktion: Wie spielen Istio und MicroProfile zusammen?

Michael Hofmann: Grundsätzlich ist Istio mit seiner Architektur technologie-neutral und somit unabhängig von der eingesetzten Programmiersprache der Services. Aber wie so oft liegt der Teufel im Detail. Es gibt mehrere Anforderungen, wie zum Beispiel Tracing oder Resilienz, wo Istio und die Services eng miteinander verzahnt sind. Auch durch die Laufzeit-Umgebung, in welcher Istio eingesetzt wird, wie beispielsweise Kubernetes, ergeben sich Anforderungen an die Services, die ein Entwickler beachten muss. Anfängliche Abstimmungs-Probleme wurden von der MicroProfile-Community erkannt und nach und nach in den jeweiligen Spezifikationen behoben.

Die derzeitige Skepsis, “jetzt schon” Istio zu verwenden, wird durch den Druck der Notwendigkeit verschwinden.

Redaktion: Wie sieht, Deiner Meinung nach, die Zukunft des Service Meshs aus bzw. in welche Richtung wird sich das ganze entwickeln?

Michael Hofmann: Meiner Meinung nach wird jedes größere Projekt ohne ein passendes Service-Mesh-Werkzeug das Geflecht an Services nicht mehr beherrschen und somit betreiben können. Die derzeitige Skepsis, “jetzt schon” Istio zu verwenden, wird durch den Druck der Notwendigkeit verschwinden. Erste Projekte in meinem Umfeld beginnen damit, Teile von Istio zu verwenden und ich denke, der eingesetzte Funktionsumfang wird sich stetig erweitern. Von seitens der Tool-Hersteller wird intensiv daran gearbeitet, die Komplexität, welche in den Tools selbst steckt, zu reduzieren. Auch die Fehlermöglichkeiten, welche durch den falschen Einsatz der Service Mesh Tools entstehen können, wird werkzeug-gestützt verringert. Damit wird insgesamt die Einstiegshürde für die Projekte reduziert.

Redaktion: Vielen Dank für das Interview!