Interview mit Patrick Arnold

Istio: „Ein Service Mesh löst einige große Probleme bei der Verwaltung der Service-to-Service-Kommunikation, aber nicht alle“

Katharina Degenmann

Patrick Arnold

Service Meshes sind derzeit ein sehr populäres Thema in der IT: Microservices-Architekturen wachsen kontinuierlich und damit die Schwierigkeit, die Übersicht zu behalten. Wir sprachen mit Patrick Arnold, IT-Consultant bei der Pentasys AG, über Service Meshes wie Istio, Linkerd und solo.io und Best Practices beim Einsatz solcher.

Wer Patrick Arnold einmal live erleben möchte, der hat auf der diesjährigen DevOps Conference in München Gelegenheit dazu. In seiner Session Service Mesh mit Istio für Einsteiger wird es darum gehen, welche Unterstützung Istio liefert, wenn es darum geht, viele Services zu managen und dabei nicht den eigentlichen Business Value aus dem Auge zu verlieren, und wie das Tool aufgebaut ist.

JAXenter: Eine Frage zur Einführung. Wie würdest Du jemandem, der sich mit dem Thema Service Mesh nicht auskennt, das Konzept in wenigen Worten erklären?

Patrick Arnold: Ein Service Mesh ist eine Infrastrukturkomponente, welche die Service-to-Service-Kommunikation im Netzwerk verwaltet. Dafür wird sie direkt in die Applikation integriert. Die Hauptaufgabe eines Service Mesh ist es also, die Kommunikation zwischen unterschiedlichen Komponenten zu ermöglichen aber auch zu verhindern. Zu den allgemeinen Funktionen eines Service Mesh zählen häufig Load Balancing, Verschlüsselung der Service-to-Service-Kommunikation, Circuit Breaker und die Fault Injection. Dadurch, dass der Service Mesh solch einen guten Einblick in den Traffic der Anwendung hat, werden über ihn häufig auch Schnittstellen für Metrikdaten zur Verfügung gestellt. In einem Service Mesh werden Anfragen zwischen Microservices über Proxys in deren eigener Infrastrukturschicht übertragen. Aus diesem Grund werden einzelne Proxys, die einen Service Mesh ausmachen, manchmal „Sidecars“ genannt, da sie parallel zu jedem Service und nicht darin ausgeführt werden.

JAXenter: Welche Vorteile hat man vom Einsatz eines Service Mesh Tools?

Patrick Arnold: Ein Service Mesh löst einige große Probleme bei der Verwaltung der Service-to-Service-Kommunikation, aber nicht alle. Einige Vorteile eines Service-Netzes sind:

  • Erleichterung der Kommunikation zwischen unterschiedlichen Microservices oder auch Containern.
  • Einfachere Diagnostizierung von Kommunikationsfehlern, da sie auf der eigenen Infrastrukturschicht auftreten und somit auch besser überwacht werden können.
  • Schnellere Entwicklung, Testing und auch Deployment einer Anwendung.
  • Ein Service Mesh bietet uns aus dem Standard heraus einige Sicherheitsfeatures wie Verschlüsselung, Authentifizierung und Autorisierung.
  • Sidecar Container, die neben der eigentlichen Anwendung platziert sind, bieten Einblicke in die Applikation und den Traffic ohne programmatische Anbindungen.
  • Ein Service Mesh bietet die Möglichkeit, moderne Deployment-Strategien ohne großen Aufwand zu nutzen.
DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

JAXenter: Neben den vielen Vorteilen: Erkauft man sich dabei auch einige Nachteile?

Patrick Arnold: Bei allen Pros gibt es selbstverständlich auch immer Contras:

  • Durch die zusätzlichen Sidecar- und Managementkomponenten hat man selbstverständlich mehr Laufzeitartefakte, die ebenfalls Ressourcen benötigen.
  • Ebenso werden es beim Routing des Traffics unter Verwendung eines Service Meshs bei jeder Applikation ein paar Hopps mehr. Grund dafür ist das Sidecar, das bei jedem Applikationsaufruf erst durchlaufen werden muss.
  • Steigerung der Komplexität durch eine weitere Infrasrukturschicht.

JAXenter: Was sind die wesentlichen Schritte für das Arbeiten mit Istio bzw. welche Best Practices haben sich für Dich herauskristallisiert?

Patrick Arnold: Speziell für Istio würde ich da gar nichts als Best Practices ausweisen. Denn eigentlich sollte man als Feature-Team, außer bei der Routing-Definition und dem Deployment von Istio, gar nicht so viel wahrnehmen. Dennoch gibt es ein paar Punkte, die helfen können, einen Service Mesh Layer auf seinen Microservices zu etablieren:

  • Nutzung der Autoinjizierung der Sidecar-Proxys – bei manchen Service Meshes wie zum Beispiel Istio steht diese Möglichkeit zur Verfügung. Sollte sie das nicht tun, so würde ich dennoch empfehlen die Injizierung zu automatisieren, anstatt sie manuell vorzunehmen.
  • Fokusierung auf Automatisierung – Hier sollte man sich auf jeden Fall mit dem Thema Infrastructure as Service auseinandersetzen. Sollte es nämlich mal zu einem Ausfall oder einer Störung im Control Plane kommen, kann man dieses in kürzester Zeit neu aufsetzen.
  • Monitoring und Tracing über jegliche Services – durch die starke Verteilung der Applikation sollte man unbedingt auf die Service-Mesh-Schnittstellen zurückgreifen, um ein umfängliches Monitoring und Tracing aufzubauen. Nur dann muss nichts Spezielles dafür innerhalb der Applikation implementiert werden, denn es wird alles vom Sidecar übernommen.
  • Für den Anfang ein kleiner Namespace & Feature by Feature – wie bei den meisten Einführungen von neuen Technologien sollte man zuerst mit einem relativ kleinen Namespace beginnen, um Erfahrungen zu sammeln. Das volle Featureset am Anfang zu nutzen, kann einen auch vor die ein oder andere Herausforderung stellen, deswegen Feature für Feature nutzen.

JAXenter: Istio ist nicht der einzige Service Mesh auf weiter Flur – inwieweit sind Linkerd und solo.io gefährliche Konkurrenten?

Patrick Arnold: Also rein technologisch ist Linkerd definitiv ein gefährlicher Konkurrent für Istio. Leider ist jedoch die Community deutlich kleiner und es gibt auch weniger Contributer. Außerdem stehen hinter Istio mit IBM und Google zwei riesige IT-Firmen, welche natürlich ihr Open-Source-Projekt vorantreiben möchten. solo.io verfolgt da einen anderen spannenden Ansatz. Nach der Veröffentlichung der „Service Mesh Interface“-Initative von Microsoft habe ich das erste Mal von solo.io gehört. Ihr Service Mesh Hub ermöglicht es, unterschiedliche Service Meshes zu provisionieren und zu betreiben. Ich glaube hierüber wird man in den nächsten Wochen und Monaten definitiv noch die ein oder andere spannende Nachricht hören.

JAXenter: 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?

Patrick Arnold: Definitiv, ich glaube Istio erfreut sich aktuell an der größten Verbreitung unter den Service Meshes. Meist ist es auch auf Konferenzen so, dass sobald es um das Thema Service Mesh geht, meist von Istio die Sprache ist. Istio wird mittlerweile auf fast jeder Kuberentes-Plattform supported. Für mich ist es aktuell bereits der „quasi“ Standard.

Patrick Arnold ist IT-Consultant bei der Pentasys AG. Für ihn ist Technologie wie Spielzeug für kleine Kinder, er ist süchtig nach Neuem. Nach einer Oldschool-Ausbildung im Mainframebereich wechselte er in die dezentrale Welt. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze sowie Cloud, API-Management, Continuous Delivery, DevOps und Microservices.
Geschrieben von
Katharina Degenmann
Katharina Degenmann
Katharina Degenmann hat Politikwissenschaft und Philosophie studiert. Seit Februar 2018 arbeitet sie als Redakteurin bei der Software & Support Media GmbH und ist nebenbei als freie Journalistin tätig.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: