Transkript
Jörg Müller: Herzlich Willkommen zum INNOQ-Podcast. Heute wollen wir über das Thema Service Meshes reden. Dazu habe ich mir zwei Gäste eingeladen. Zum einen Hanna, hallo Hanna.
Hanna Prinz: Hallo, Jörg.
Jörg Müller: Und Eberhard.
Eberhard Wolff: Hi, Jörg.
Jörg Müller: Könnt ihr vielleicht kurz etwas dazu sagen, was ihr bei uns macht und wer ihr seid?
Hanna Prinz: Ich bin Hanna; ich schreibe bei INNOQ gerade meine Masterarbeit zum Thema Service Meshes und freue mich sehr, dass wir jetzt darüber sprechen.
Eberhard Wolff: Mein Name ist Eberhard Wolff; ich bin Fellow. Ich mache Consulting Training, Beratung und Vorträge zu verschiedenen Themen und ich habe Bücher geschrieben, u.a. zwei zum Thema Microservices.
Jörg Müller: Bevor wir direkt in das Thema einsteigen, vielleicht eine Bemerkung auf der Metaebene: Wir haben bei der Vorbereitung gemerkt, dass das Thema sehr, sehr tief geht, deswegen wird das vermutlich ein Podcast aus zwei Teilen werden. Wir werden uns im ersten Teil damit beschäftigen, was ein Service Mesh eigentlich ist und wie das Ganze funktioniert, und im zweiten Teil darauf eingehen, wie das zu aktuellen Architekturen passt, wie sinnvoll das ist und was alternative Vorgehensweisen sind. Fangen wir mit dem ersten Teil an: Was sind eigentlich die Herausforderungen von Microservices und wie könnten Service Meshes dabei helfen?
Eberhard Wolff: Für mich sind Microservices im Wesentlichen Module eines Systems und Modularisierung machen wir schon super lange. Der Unterschied zu anderen Modularisierungsansätzen ist, dass Microservices typischerweise als Docker Container ausgeführt werden, also getrennte Prozesse sind mit eigenem Dateisystem, mit eigenen IP-Adressen. Dadurch habe ich die Möglichkeit, jedes Modul getrennt zu deployen. Wenn ich also sage, ich habe eine Änderung im Bestellprozess, dann kann ich das Modul für den Bestellprozess als Microservice getrennt deployen von allen anderen. Und das führt noch zu weiteren technischen Entkopplungen: Ich kann die zum Beispiel auch getrennt skalieren oder ich habe Sicherheitsvorteile, weil ich zwischen diese Systeme Firewalls einfügen kann usw. Das wären für mich erst mal Microservices. Das führt offensichtlich zu technischen Herausforderungen. Das ist eben ein verteiltes System, die Microservices müssen dann übers Netz miteinander sprechen. Das bedeutet, ich habe mehr deploybare Artefakte, ich habe die ganzen Schwierigkeiten, die ich mit dem Netzwerk habe, unzuverlässiges Netzwerk, solche Geschichten. Und bestimmte Dinge gehen nicht mehr so einfach. Ich kann nicht sagen, ich nehme das Log-File des Systems, sondern ich habe ganz viele Log-Files auf verschiedenen Systemen herumliegen, die ich alle gemeinsam anschauen muss.
Jörg Müller: Davon gab es sicherlich in der Vergangenheit auch verschiedene andere Ansätze. Was macht denn das Thema Service Meshes dabei so interessant? Wie sind diese Service Meshes aufgebaut?
Hanna Prinz: Ein Service Mesh ist erst einmal eine zusätzliche Infrastrukturebene. Sie ist dezentral, das heißt, jeder Microservice bekommt einen weiteren Prozess an die Seite, der getrennt ist, der sich aber, wenn man jetzt im Kubernetesumfeld ist, im gleichen Pod befindet. Und dieser weitere Prozess ist ein Proxy. Und dieser Proxy, der kann sozusagen allen Netzwerkverkehr mitschneiden und zwar den eingehenden und den ausgehenden. Was bei dem Service Mesh eine Data Plane genannt wird, ist die gesamte Anzahl aller dieser Proxys, die mehr oder weniger auch dem Sidecar-Pattern entsprechen. Also dass man einen weiteren Prozess neben eine Anwendung legt, ist mehr oder weniger das Sidecar-Pattern und das Service Mesh definiert eine Ebene, die aus diesen ganzen Sidecars besteht. Diese Ebene kann von einer zweiten Ebene gesteuert werden und genutzt werden und das ist die Control Plane.
Jörg Müller: Okay. Ich kann mich von früher noch daran erinnern, dass wir so etwas hatten wie aspektorientierte Programmierung. Ist das jetzt so etwas wie aspektorientierte Programmierung mit Infrastruktur?
Eberhard Wolff: Ich finde das nicht abwegig, ja. Es ist eben so, dass man sich bei aspektorientierter Programmierung, bei AOP, in jeden Methodenaufruf irgendwie hineingehängt hat, das ist hier analog. Hier sind es die Aufrufe über das Netzwerk.
Jörg Müller: Hanna, du hast das Thema Kubernetes an der Stelle erwähnt, ist denn Kubernetes eine zwingende Voraussetzung dafür, dass ich Service Meshes verwende?
Hanna Prinz: Das kommt darauf an, welche Implementierung von dem Service Mesh man nutzt. Es gibt Implementierungen, die Kubernetes voraussetzen, aber wir werden heute vorrangig über Istio sprechen. Istio ist ein Projekt, das von Google und IBM und von Lyft weitgehend getragen wird. Das ist ein Open Source Projekt, das es, glaube ich, seit ungefähr zwei Jahren gibt. Das ist ähnlich wie Kubernetes ein Produkt, das aus einer internen Entwicklung von Google entstand, auch wie Kubernetes, zum Beispiel, das sie dann der Open Source Community zur Verfügung gestellt haben. Bei Istio ist es so, dass es sich in Kubernetes am wohlsten fühlt. Aber man kann es auch in andere Umgebungen einbinden.
Jörg Müller: Was sind denn jetzt die Dinge, die ich durch ein solches Service Mesh gewinne?
Eberhard Wolff: Wie Hanna schon sagte, man hängt sich über einen Proxy in den Netzwerkverkehr rein. Und daraus kann man erstaunlich viele Dinge ableiten: Man kann herausfinden, wie lange ein Aufruf läuft. Man kann auch herausfinden, welcher HTTP-Statuscode zurückgegeben wird. Das heißt, man kann auf dieser Ebene Monitoring machen. Man kann Tracing machen, das heißt, ich kann sehen, welcher Aufruf welchen anderen Aufruf verursacht hat und schauen, wie das durch die Microservices durchläuft. Man kann von dort aus auch Logging machen, auf der Ebene von diesen Access-Logs, die man früher auch bei den Webservern hatte. Und man kann Fault-Injection machen, also dafür sorgen, dass sich Services plötzlich so verhalten, als hätten sie einen Fehler. Man kann versuchen, so etwas wie Resilience einzubauen, dass man eine höhere Widerstandsfähigkeit macht, indem man dort sagt, man hat ein Time-out, sodass ein Aufruf nicht blockiert, sondern nach einem Time-out abgebrochen wird. Es gibt Security-Features, ich kann den Netzwerkverkehr verschlüsseln, ich kann Zertifikate verteilen. Ich glaube, das war es so weit.
Hanna Prinz: Noch eine Sache, die ein Service Mesh auch lösen kann, sind Routing-Angelegenheiten. Also man kann zum Beispiel Client Side Load Balancing machen. Man kann Canary Releases zum Beispiel durch Istio abbilden, was mit Kubernetes eine kompliziertere Angelegenheit ist. Also bei Canary Releases ist es so, man hat eine neue Version, von einer Software zum Beispiel, bei der man noch nicht genau weiß, wie die sich tatsächlich verhält, wenn man sie deployt. Und bei einem Canary Release rollt man sie ganz langsam und teilweise nur für bestimmte Benutzergruppen oder in bestimmten Teilen der Welt aus, vielleicht mit einem Prozent. Dann schaut man sich die Metriken an und kann dann entscheiden, wie man damit weitermacht. Und das ist mit Mitteln, die bei Kubernetes on board sind, aktuell nicht so einfach möglich.
Jörg Müller: Und wie funktioniert dann ein solches Routing in Istio jetzt gerade aktuell?
Hanna Prinz: In Istio gibt es Regeln, die man definiert. Man kann definieren, immer wenn in der URL der und der String steht, dann leitet man an den und den Service weiter. Man kann von diesen einfachen Regeln bis zu sehr komplexe Regeln definieren, zum Beispiel aufgrund von HTTP-Headern. Und diese Regeln kennen alle von diesen Proxys. Man hat auch zentrale Komponenten, aber durch diese verteilten Proxys geht das Ganze ein bisschen effizienter.
Jörg Müller: Wie lernen diese Proxys dann, dass ich diese Regeln definiert habe? Also wie funktionieren diese zentralen Komponenten?
Hanna Prinz: Es gibt zwei unterschiedliche Dinge. Es gibt Regeln, die für ausgehenden Verkehr sind. Zum Beispiel - was Eberhard gerade schon gesagt hat - wenn man den Verkehr verschlüsseln möchte: Wenn man so eine Regel anwendet, wenn wir als DevOps-Team oder Entwicklungsteam sagen, wir möchten jetzt jeglichen Verkehr verschlüsseln, dann gibt es eine Komponente, die diese Konfiguration synchron an alle diese Proxys verteilt, wenn wir jetzt von Istio sprechen.
Jörg Müller: Die heißt Mixer, glaube ich?
Hanna Prinz: Das ist der Pilot.
Jörg Müller: Das ist der Pilot, okay. Spielen diese Komponenten dann auch beim Thema Monitoring eine Rolle? Wie funktioniert das in dem Bereich? Wie monitort mein Service Mesh meine Microservices?
Eberhard Wolff: Im Wesentlichen, indem die Requests durch die Proxys laufen, was bedeutet, dass man so etwas wie Latenzzeiten, Durchsatz etc. daraus relativ einfach ermitteln kann. Und dadurch, dass bekannt ist, dass es das HTTP-Protokoll ist, bekomme ich auch heraus, ob bestimmte Dinge erfolgreich sind oder nicht. Dafür gibt es ja die HTTP-Statuscodes und es sollte eben so sein, dass ein 500er dann passiert, wenn ein Fehler da ist, und ein 200er, wenn alles gut ist. Und darüber kann ich jetzt Monitoring machen. Ich kann herausfinden, wieviele Requests durchgegangen sind, an welche URL, mit welchem Statuscode usw. Das ist meinem Empfinden nach etwas, was eine ganze Menge an Herausforderungen schon beantwortet, weil es in einer Microservices-Umgebung, finde ich, wichtig ist zu sehen, wie sich das System gegenüber dem Benutzer verhält. Und diese Information bringt mir dafür schon eine ganze Menge an Information, also Latenzzeiten und solche Geschichten. Was ich logischerweise nicht sehe, ist, was innerhalb des Services vor sich geht. Das ist also dann für das Monitoring eine Blackbox. Ich kann natürlich ein paar zusätzliche Informationen herausbekommen. CPU-Auslastung oder so etwas sind ja grundsätzliche Systemmetriken, die ich dann sowieso zusätzlich bekommen kann. Und konkret ist es dann so, dass bei Istio sozusagen in der Lösungsbox gleich noch ein Prometheus dabei ist, in dem ich diese Metriken erfassen kann. Das Prometheus ist ein System, das sich gerade im Kubernetes-Umfeld einiger Beliebtheit erfreut und multidimensional ist, sodass ich einzelne Metriken aufschlüsseln kann nach dem Handler, der das bearbeitet hat, nach der URL oder nach dem Statuscode, sodass ich Fragen beantworten kann, wie lange denn nun der 500er üblicherweise gedauert hat, im Gegensatz zu 200ern, oder so etwas. Oder wie lange dieser Service gebraucht hat im Gegensatz zu denen usw. Dass ich das aufteilen kann.
Und dazu kommt dann noch ein Grafana. Das ist im wesentlichen etwas, wo ich dann Dashboards und grafische Auswertungsmöglichkeiten habe. Das ist in Istio dann auch enthalten, sodass ich eigentlich an der Stelle mindestens sozusagen ein Blackbox-Monitoring inklusive Datenspeicherung, inklusive Auswertung aus dem Istio einfach herausbekomme, ohne dass ich irgendetwas tun muss. Ich lasse einfach den Microservice da hineinfallen und dann läuft das alles schon von sich aus. Und das ist an der Stelle, glaube ich, ein deutlicher Vorteil oder ein sehr nettes Feature.
Jörg Müller: Das klingt jetzt natürlich auch ganz schön viel und auch relativ komplex, wie gestaltet sich denn die Installation von einem solchen Service Mesh im Moment?
Hanna Prinz: Das, was Eberhard gerade gesagt hat, die Features, die man so bekommt, die bekommt man, wenn man zum Beispiel Istio nimmt, sehr einfach bei den Setups, die wir uns hier angeschaut haben. Es gibt sicherlich auch Umgebungen, die ein bisschen spezieller sind. Aber Istio ist ja auch mittlerweile hinter der 1.0. Das heißt, sie empfehlen sich selbst auch für eine Produktionsumgebung und sie haben auch sehr viel in Dokumentation und Erleichterung von dem Setup investiert. Man kann das mit ganz normalen Kubernetes-YAML-Dateien machen. Es gibt auch mittlerweile von Google Cloud einen nativen Support von Istio. Das heißt, man kann theoretisch auch einfach einen Knopf drücken und dann bekommt man Istio dazu.
Jörg Müller: In einem Cluster in der Google Cloud?
Hanna Prinz: In einem Kubernetes-Cluster in einer Google Cloud, genau. Aber auch, wenn man das von Hand macht, ist das eigentlich eine ziemlich einfache Angelegenheit. Was man aber bei den Metriken dazu sagen muss, ist, dass man natürlich nur Metriken „geschenkt bekommt“, die jeder Service von sich selbst einfach so sammeln kann. Also es geht hier nicht um Businessmetriken, es geht nicht um individuelle Fehlercodes, die in irgendeinem JSON, in einem Body mitgeschickt werden, sondern es geht um ganz allgemeine Metriken wie Latenzzeiten, wohin geht die Anfrage, woher kommt sie, solche Sachen. Die bekommt man, ohne irgendetwas zu tun. Und, auch ganz wichtig, ohne diese Anwendung, die diese Metriken produziert, indirekt, ohne da einen Finger zu rühren. Das ist eigentlich das Tolle an einem Service Mesh.
Jörg Müller: Okay, das klingt spannend. Jetzt gibt es neben Monitoring und Routing, was wir schon behandelt haben, noch so ein paar andere Dinge, die Eberhard am Anfang schon genannt hatte, zum Beispiel das gesamte Thema Resilience. Wenn Microservices miteinander kommunizieren, dann muss man auch darauf achten, dass sie eben verteilt sind und auch einmal zeitweise ausfallen können. Wie wird dieses Thema durch das Service Mesh unterstützt?
Hanna Prinz: Wenn man jetzt mit anderen Lösungen eine Widerstandsfähigkeit, was ja eine Resilience eigentlich ist, implementiert, dann geht man meistens hin und nimmt eine Library. Da war vor einiger Zeit Hystrix eine ganz spannende Angelegenheit, was aber mittlerweile auch nicht mehr maintained wird. Und dann hat man in seinem Anwendungscode eine Library importiert. Immer wenn man in seinem Code eine Anfrage abgeschickt hat, hat man irgendetwas darum herum gebaut. Man musste diese Library instrumentalisieren. Mit Istio ist das einfach eine Konfiguration. Ich schreibe eine YAML-Datei und wenn ich zum Beispiel einen Circuit Breaker implementieren möchte, muss ich zum Beispiel keinen Java-Code schreiben, sondern ich konfiguriere, dass ich, immer wenn ein bestimmter Service angefragt wird, sage, wenn dieser mir innerhalb von fünf Minuten zehn Mal einen Fehler gibt, dann frage ich den erst mal für weitere zehn Minuten nicht an, damit er sich erholen kann. Das ist ja die Aufgabe von dem Circuit Breaker, einen fehlschlagenden Service nicht weiter in die Knie zu zwingen, indem man Anfragen wiederholt oder indem sich so ein Stau vor dem Service ergibt, sondern man versucht, ihn so ein bisschen in Ruhe zu lassen. Und das ist etwas, was man mit Istio durch eine Konfiguration macht. Was das auch bedeutet, ist, ich kann meinen Circuit Breaker zu einem Zeitpunkt ändern und muss meine Anwendung nicht anfassen. Ich muss meine Anwendung nicht neu deployen, so wie das früher war. Heute ist das anders.
Jörg Müller: Man kann da ja sogar noch andere Sachen machen, habe ich gehört, wie zum Beispiel direkt Fehler einbringen in das System, um zu testen, wie meine Anwendung eigentlich darauf reagiert, wenn das Netz einmal nicht so perfekt funktioniert.
Eberhard Wolff: Vielleicht sollten wir kurz noch einmal bei dem Thema mit dem Circuit Breaker stehen bleiben. Was ich erst vor einiger Zeit verstanden habe, ist, wie Hanna ja schon sagte, dass der Circuit Breaker eigentlich dazu da ist, um den Empfänger der Nachrichten oder den Server sozusagen zu schützen. Das heißt, ich baue dort eben eine Request-Pipeline ein und schaue nach, dass dort nicht zu viele Requests warten, dass er an der Stelle, an der er ein Problem hat, herausgenommen wird. Auf der anderen Seite ist es auf der Senderebene möglich, Retrys einzubauen, also dass ich sage, es wird eben noch einmal aufgerufen. Und das sind Funktionalitäten, die sonst üblicherweise eher noch in den Circuit Breaker hereingehen, dass man sagt, dass eben auch der Client dort noch gewinnen soll und geschützt werden soll. Und bei Istio oder dem Envoy-Proxy ist es eben so, dass das ein bisschen aufgeteilt wird, also zu den Client-Funktionalitäten und zu den Server-Funktionalitäten. Dass da eben eigentlich zwei Mechanismen sind, die dafür sorgen, dass Resilience entsprechend erhöht wird an der Stelle.
Jörg Müller: Okay, alles klar.
Hanna Prinz: Eberhard hat gerade das Wort „Envoy“ genannt, das haben wir noch gar nicht erwähnt. Istio ist ein Service Mesh, was ja bedeutet, dass das aus einer Control Plane und einer Data Plane besteht und die Data Plane aus verschiedenen Proxys und Istio hat sich gesagt, wir schreiben den Proxy nicht neu, denn es gibt einen guten. Der ist von Lyft, das ist eine Firma, die hier in Deutschland nicht so bekannt ist, aber in den USA.
Jörg Müller: Das ist eine Alternative zu Uber, glaube ich?
Hanna Prinz: Ja, genau. Es ist so eine ride-hailing Firma. Und die haben schon einen Proxy entwickelt, das ist auch ein CNCF-Projekt, also Cloud Native Computing Foundation-Projekt, und Istio benutzt diesen Proxy. Die haben ihn so ein bisschen geändert, aber der läuft im Hintergrund. Nur mal so als Einwurf.
Jörg Müller: Okay. Und der kann auch Fehler hineinpacken.
Hanna Prinz: Genau.
Jörg Müller: Diesen Punkt noch mal dazu. Aber gut, wahrscheinlich ist das gar nicht so spannend. Ein anderer interessanter Aspekt ist das Thema Security zwischen Microservices. Was bietet mir ein Service Mesh an der Stelle noch zusätzlich?
Hanna Prinz: Da gibt es verschiedene Dinge. Zum einen kann ich mit einem Service Mesh kontrollieren, welcher Service welchen anderen anfragen darf. Immer wenn man solche Sachen tut, muss man sich ziemlich sicher sein, dass man die Services identifizieren kann. Ich kann ja keine Regel festlegen, wenn ich nicht überprüfen kann, ob ein Service wirklich der Service ist, der er behauptet zu sein. Deswegen integriert auch Istio das Konzept von Identität. Es gibt ein Verfahren, dass, immer wenn ein neuer Pod startet, sichergestellt wird, dass dieser Pod derjenige ist, der er angibt zu sein. Dafür gibt es Zertifikate und das ist nämlich die dritte Komponente von der Istio-Control Plane. Wir haben ja schon kurz über den Pilot und den Mixer gesprochen und es gibt eine dritte Komponente, das ist die Citadel und die ist eine Certificate Authority. Das heißt, sie signiert Zertifikate, die jeder Pod bekommt, sobald er startet. Und dadurch, dass man diese Zertifikate hat, kann man auch sehr leicht die Verbindungen innerhalb des Service Mesh mit mTLS verschlüsseln und authentifizieren.
Jörg Müller: TLS kenne ich; was ist der Unterschied zwischen TLS und mTLS?
Eberhard Wolff: Es ist mutual, dass sich Sender und Empfänger gegenseitig zusichern, dass sie die sind, die sie vorgeben zu sein. Und wie Hanna schon sagte, dass ist etwas, was ich über Zertifikate erreichen kann. Und das ist eigentlich ein Sicherheitsplus, weil es bedeutet, dass mein interner Attacker, der versucht, sich da hinein zu schmuggeln, es hinbekommen müsste, dass er ein Zertifikat in seinem Service hat und sich darüber dann an der Kommunikation zwischen den Services beteiligt. Und da ist eben die Hoffnung, dass das nicht so einfach möglich ist, während an der Stelle, an der jemand sozusagen legal so ein System startet, so ein Zertifikat irgendwie da hineingetan wird. Und dadurch, dass ich eben typischerweise so etwas wie Kubernetes habe, bei dem ich meine Microservices starte, kann ich dann eben beim Start gleich so ein Zertifikat mitgeben und dafür sorgen, dass das funktioniert.
Jörg Müller: Sodass dann die Services nicht nur verschlüsselt miteinander kommunizieren, sondern auch wissen, dass sie auch wirklich mit der richtigen Komponente kommunizieren. Ja, das verstehe ich, das ergibt Sinn. Jetzt haben wir die ganze Zeit vor allem über Istio geredet. Das klingt ja jetzt fast so, als wäre das die einzige Lösung und Möglichkeit, ein Service Mesh abzubilden. Was gibt es denn da draußen noch für Alternativen zu Istio?
Hanna Prinz: Das klingt tatsächlich so und das klingt auch so, wenn man Service Mesh in der Suchmaschine eingibt. Istio ist gerade sehr populär. Es ist aber tatsächlich auch nicht das erste Service Mesh, sondern das erste Service Mesh ist Linkerd. Das ist auch ein CNCF-Projekt im Gegensatz zu Istio, was sich wahrscheinlich in Zukunft auch noch ändern wird. Linkerd ist schon länger auf dem Markt, hatte aber lange das Problem, dass es zu kompliziert zu konfigurieren war. Es gibt die Funktionen schon ein bisschen länger, aber Linkerd war einfach überkomplex. Vor einiger Zeit haben sie ein neues Produkt geschrieben mit geeigneteren Programmiersprachen, das haben sie in RUST und in Go geschrieben und haben auch einen eigenen Proxy geschrieben. Sie haben zumindest die Möglichkeit, diesen besser zu optimieren für ein Service Mesh. Die haben also eine 2.0, das ist dieses neu implementierte Service Mesh. Die spielen aktuell noch keine so große Rolle, einfach, weil sie noch nicht so viele Features haben wie Istio. Aber man kann gespannt sein, was da passiert. In Istio fließt gerade sehr viel Energie und auch die Open Source-Community ist da sehr aktiv, aber auch Linkerd 2 ist ein Open Source-Projekt und es könnte durchaus sein, dass da noch sehr viel Interessantes von ihnen kommt.
Jörg Müller: Gibt es noch weitere Alternativen, die man vielleicht erwähnen sollte?
Hanna Prinz: Ja, es gibt tatsächlich sehr viel, was sich in dem Bereich tut. Es gibt einige API-Gateways, die ein bisschen umsatteln oder die – sagen wir mal – einen Service Mesh-Modus anbieten. Kong ist da ein Beispiel, es gibt auch von Consul einen Service Mesh-Modus. Es gibt auch Service Meshes, die auf Istio aufsetzen, die das noch ein bisschen dekorieren, könnte man sagen. Das ist zum Beispiel Aspen Mesh. Und dann gibt es das von den Cloud-Anbietern direkt; zum Beispiel AWS hat ein eigenes Service Mesh. Man kann eigentlich von allen Service Meshes sagen, dass sie in einem sehr jungen Status sind, auch was die Features angeht. Da ist Istio schon die Ausnahme, obwohl auch Istio viele Features in Alpha- und Beta-Status hat. Da muss man immer auf die Webseite schauen und sich anschauen, welches Feature man in Produktion benutzen möchte. Neben AWS gibt es auch noch Azure, die haben auch ein eigenes Service Mesh-Angebot.
Jörg Müller: Das heißt, alle großen Cloud-Anbieter, API-Gateway-Anbieter, die meisten springen gerade auf den Zug der Service Meshes auf? Jetzt haben wir ungefähr einen groben Überblick darüber, wie Service Meshes funktionieren. Das klingt ja alles danach, als wäre so ein Service Mesh wirklich so ein magisches Ding, bei dem man in seiner eigenen Anwendung gar nichts mehr selbst machen muss. Gibt es denn auch Aspekte, bei denen man seine eigene Anwendung auf so ein Service Mesh anpassen muss?
Hanna Prinz: Es gibt nicht so etwas, dass man irgendwie so eine Istio-Library oder so etwas hat, die man irgendwie in seine Anwendung hineinziehen muss. Aber es gibt eine Sache, die ein Service Mesh nicht alleine hinbekommt, da muss man ihm ein bisschen helfen. Und das ist das Thema Tracing. Wenn man Microservices hat, dann möchte man im Idealfall genau wissen, wo eine Anfrage, wenn sie hineingeht, landet. Also wie setzt sich die Latenz zusammen, wo genau ist der Fehler, wenn ich einen Fehler zurückbekomme? Und deshalb möchte man gerne für jede Anfrage, die hineinkommt, genau wissen, welche Services diese Anfrage durchläuft. Istio bietet Features an, um dieses End-zu-End-Tracing durchzuführen. Allerdings, nehmen wir jetzt einmal an, wir haben zwei Services und beim einen gehen zwei Anfragen kurz nacheinander hinein und eine geht hinaus. Dann kann dieser Proxy nicht unterscheiden, zu welcher von diesen eingehenden Anfragen oder vielleicht auch zu beiden diese ausgehende Anfrage gehört. Diese Verbindung kann der Proxy nicht herstellen. Und an dem Punkt müssen wir dem Service Mesh helfen. Wir müssen in unsere Anwendung hineingehen und sobald wir eine neue Anfrage herausschicken, müssen wir die Header von der Anfrage, auf die sie quasi reagiert, kopieren. Das sind Open-Tracing-Header. Das sind so Standard-Header, die man auch kennt, wenn man mit anderen Systemen arbeitet. Auch da braucht man keine Library, sondern man muss es einfach tun. Es gibt auch Libraries, die einem dabei helfen, aber man braucht sie theoretisch nicht. Und das ist so ein Beispiel für einen Fall, bei dem man seine Anwendung schon so ein bisschen anpassen muss. Aber es ist halt eine technische Einschränkung.
Jörg Müller: Das heißt, beim Tracing muss ich in meiner Anwendung ein bisschen was tun. Und wie ist das eigentlich, habe ich irgendeine Möglichkeit, mir einen Überblick darüber zu verschaffen, wie mein ganzes Service Mesh überhaupt aussieht? Gibt mir das da auch etwas an die Hand?
Hanna Prinz: Wir hatten schon über Metriken gesprochen. Und eine andere Möglichkeit sind auch noch die Logs. Vielleicht kann Eberhard dazu etwas sagen?
Eberhard Wolff: Also eine Möglichkeit, sich einen Überblick zu verschaffen über das System, ist natürlich erst einmal das Tracing. Das heißt, aus dem Tracing bekomme ich heraus, wer grundsätzlich erst einmal mit wem spricht. Und innerhalb von Istio ist eben Jaeger integriert und Jaeger hat solch schöne Dependency-Graphen, die einem sagen, wer mit wem an welcher Stelle spricht. Und das ist neben der Möglichkeit, herauszufinden, wie eigentlich die Performance verteilt ist, noch eine andere Möglichkeit, dort zu schauen, wie diese Systeme miteinander interagieren. Das ist natürlich nur begrenzt hilfreich, denn wenn die Systeme nur einmal im Jahr miteinander interagieren, bekomme ich da möglicherweise nichts heraus. Und es gibt dort außerdem Kiali, was man auch in Istio integrieren kann und was eigentlich speziell für den Überblick über das Service Mesh gedacht ist.
Hanna Prinz: Genau, Kiali ist ein Dashboard, das extra für Istio entwickelt wurde. Das kommt auch mit der aktuellen Istio-Version mit, wenn man das konfiguriert. Man kann sagen, man möchte Istio mit Kiali installieren. Kiali visualisiert einige Features von dem Service Mesh. Man kann sich zum Beispiel in Kiali auch diesen Graphen anschauen; man kann sich anschauen, welcher Service mit wem redet. Oder zum Beispiel auch, wenn man einen A/B-Test oder so macht, sehen, welcher Service mit welcher Version von welchem Service redet. Das ist eine graphische Funktion, aber man kann sich zum Beispiel auch Konfigurationen validieren lassen. Man kann schauen, ob man irgendwelchen Quatsch konfiguriert hat. Das funktioniert noch nicht für alles, aber für einen Teil schon. Man sieht auch, an welcher Stelle man einen Circuit Breaker hat, wo man zum Beispiel eine verschlüsselte Verbindung hat. Das ist ein Dashboard, das optimiert ist für Istio. Und das macht die Arbeit mit Istio sehr viel einfacher. Denn diese Konfiguration zu schreiben, ist überschaubar. Man muss sich ein bisschen an die API und so gewöhnen, aber Kiali hilft einem wahnsinnig dabei, herauszufinden, ob das funktioniert hat, was man da gerade wollte, oder auch Fehler zu finden.
Jörg Müller: Okay, gut. Sehr schön, vielen Dank. Ich denke, ich habe für mich und auch für die Hörer da draußen, einen recht guten Überblick erlangt, was so ein Service Mesh eigentlich ist und wie das Ganze funktioniert. Was wir natürlich noch nicht beantwortet haben, ist, ob so ein Service Mesh jetzt eigentlich in jeder Situation nutzbringend ist oder ob es auch Situationen gibt, bei denen sich das nicht lohnt etc. Aber das ist genau das, was wir im nächsten Teil besprechen wollen. Für heute sage ich erst einmal, vielen Dank fürs Zuhören und bis zum nächsten Mal.
Eberhard Wolff: Ja, danke.
Hanna Prinz: Tschüss.