Interview mit Raymond Austin, Director of Product Marketing HashiCorp

Consul 1.8 goes Service Mesh: „Es geht um mehr als nur Kubernetes“

Dominik Mohilo

Raymond Austin

Mit Consul 1.8 ist eine neue Version des Service-Discovery-Werkzeugs erschienen, das eine wichtige Änderung mit sich bringt: Consul beherrscht nun Features zur Orchestrierung von Microservices, die bisher von spezialisierten Service Mesh Tools wie Istio oder Linkerd abgedeckt wurden. Wir haben uns mit Raymond Austin, Director of Product Marketing bei HashiCorp, über das neue Consul-Service-Mesh unterhalten. Was leistet Consul 1.8? Ab wann lohnen sich Microservices? Wohin steuert die Disziplin der Softare-Architektur in den nächsten Jahren?

Service Mesh – wann braucht man das?

Entwickler: Hallo Raymond und danke, dass du dir Zeit für dieses Interview genommen hast. Service Meshes gibt es ja mittlerweile einige, Linkerd und Istio etwa, um nur einige zu nennen. Wie unterscheidet sich Consul von den Service-Mesh-Lösungen?

Ein Service Mesh sollte global und einfach zu erweitern sein.

Raymond Austin: In Consul betrachten wir den gesamten Prozess hinsichtlich Application Service Networking – und verstehen, dass es um mehr als nur Kubernetes geht. Unternehmen suchen nach Möglichkeiten, Microservices in ihr bereits bestehendes IT-Umfeld zu integrieren, das vorhandene Workloads auf virtuellen Maschinen und Cloud-Plattformen umfasst.

Wir haben eine flexible Control Plane, die auf Kubernetes oder virtuellen Maschinen läuft. Darüber hinaus untersuchen wir, wie wir das Application Service Network für Workloads außerhalb des Service Mesh verbessern können, indem wir eine dynamische Discovery-Funktion (über Standard-Kubernetes hinaus) sowie die Möglichkeit der automatischen Aktualisierung von Load Balancern bereitstellen. Wir konzentrieren uns auch darauf, wie wir eine erstklassige Multi-Cluster-Erfahrung gewährleisten. Unternehmen möchten nicht, dass die Umgebungen, für die sie ein Service Mesh nutzen, zu Inseln werden. Ein Service Mesh sollte global und einfach zu erweitern sein, um mehrere Umgebungen einzuschließen.

Entwickler: Wann ist der Einsatz eines Service Mesh unumgänglich, welche Use Cases sind hierfür prädestiniert?

Raymond Austin: Weil Service Mesh heute zu einer Art Modewort geworden ist, wird es ab und an schlechtgeredet. Dabei erfüllt es die Anforderungen einer progressiven Bereitstellung und entkoppelt Anwendungen von der Komplexität des Netzwerks. Will man schrittweise ein Roll-out/Roll-back einer neuen Anwendung durchführen, sowie Skalierbarkeit berücksichtigen, dann ist ein Service Mesh erforderlich.

Die schrittweise Einführung eines neuen Dienstes, die Erstellung von Failover-Szenarien zwischen Rechenzentren und die Verbesserung der typischen Kommunikationsmuster für Anwendungen (Anwendungs-Routing, Health Check, Sicherheitsthemen wie mTLS-Verschlüsselung, Zero Trust Networking) sind die Kennzeichen eines Service-Mesh-Ansatzes – und müssen in der Regel out-of-band (OOB) von mehreren Plattformen bedient werden. Auch ist es notwendig, das Monitoring von Anwendungen zu gewährleisten, da diese in feingranulare Microservices zerlegt werden. Die Rolle eines Service-Mesh besteht darin, Entwicklern eine granulare Möglichkeit zu bieten, ein Problem auf Basis umfassender, aufschlussreicher Informationen zum Service zu debuggen.

Microservices vs. Monolith

Entwickler: Gibt es auch Anwendungen, die besonders von einem monolithischen Ansatz profitieren?

Man sollte sich ansehen, wie die aktuelle Anwendungs-Architektur die Workflows beeinflusst.

Raymond Austin: Die Frage ist sehr stark an ein Credo angelehnt, das wir in unserem Tao von HashiCorp verwenden: „Workflows not Technologies“. Man sollte sich ansehen, wie die aktuelle Anwendungs-Architektur die Workflows beeinflusst, wenn man nachvollziehen will, ob ein monolithischer oder ein Microservice-Ansatz sinnvoll ist.

Normalerweise empfehlen wir Anwendungen als Microservices zu konzipieren, wenn die Anwendung zerlegt wird, da dies zu einer besseren Effizienz führt, die Entwicklung beschleunigt und eventuell auftretende Fehler dezentralisiert. Die Vorteile einer solchen Vorgehensweise kommen in der Regel dann zum Tragen, wenn man genügend „Teile“ einer Anwendung hat, um sie tatsächlich zu zerlegen, und mehrere Teams/Einzelpersonen simultan daran arbeiten. Wenn eine Anwendung nicht groß oder nicht komplex genug ist, um von diesem Ansatz zu profitieren, dann ist ein monolithischer Ansatz in Ordnung, da es dem Workflow nicht hilft.

Ähnlich wie oben: Werfen wir bei der Frage nach einem monolithischen Ansatz versus einem Microservice-Ansatz einen Blick auf die Komplexität hinsichtlich Entwicklung, Tests und Betrieb. Wir haben gesehen, dass mehrere Service-Mesh-Plattformen wieder zu einem monolithischen Modell zurückkehren. Dies ist auf die Komplexität zurückzuführen, die durch die Schaffung von einfach zu vernetzenden Schnittstellen überall in einer Plattform verursacht wird.

Es gilt abzuwägen: Einerseits will man Benutzern die Möglichkeit geben, Plattformen zu erweitern, andererseits aber soll Operations einfach gestaltet werden. Dieselbe Methodik gilt auch für Anwendungen: Man ermöglicht Anwendern erfolgreich zu sein, gleichzeitig sollte aber die User Experience bedacht werden. Denn wenn Microservices es erschweren, den Service zu nutzen, und der einzige Vorteil darin besteht, ihn erweitern zu können, muss man sich fragen, ob sich dies lohnt.

Entwickler: Istio setzt mittlerweile intern auf einen monolithischen Ansatz. Ist es nicht ironisch, dass eine Service-Mesh-Lösung selbst monolithisch ist? Wie sieht das bei Consul aus?

Raymond Austin: Die Anfänge von Service Mesh waren für viele Anbieter sehr komplex. Mit den auf dem Markt verfügbaren Lösungen kam die Idee auf, Plattformen zu schaffen, die einfach zu vernetzen sind. Dies führte jedoch zu einem hohen Grad an Komplexität, um selbst die grundlegendsten Anwendungsfälle überhaupt umzusetzen. Eine unserer Hauptüberzeugungen bei HashiCorp ist wie erwähnt „Workflows over Technologies“. Als wir uns also anschauten, wie ein Service Mesh nach der Workflow-Methodik aussehen sollte, bestand eines unserer grundlegenden Ziele darin, Probleme, die Unternehmen hatten, sofort zu lösen.

Wir haben uns schon früh auf den „monolithischen“ Ansatz konzentriert, denn die Komplexität, mit der der Administrator das Service Mesh aufbauen mussten, stand in keinem Verhältnis zu unserem eigentlichen Ziel. Consul wurde schon immer als Single-Binary verteilt. In Kubernetes stellen wir es mit einem einzigen Helm-Chart bereit und die Interaktion ist über kubectl möglich, wie man es normalerweise erwarten würde. Wenn man eher komplexe Vorgänge ausführen möchte, verwendet man eben das Single-Binary. Wir haben Erfahrung damit, eine Single Control Plane in großem Maßstab zu betreiben, denn darauf hat sich Consul immer fokussiert.

Consul 1.8 und Software-Architektur-Trends

Entwickler: Mit Consul 1.8 kam gerade ein größeres Update für die Service-Discovery-Lösung heraus, was sind die neuen Features?

Ich glaube, wir werden einen anhaltenden Trend zur Implementierung von Microservices-Modellen sehen.

Raymond Austin: Die neuen Funktionen für 1.8 sind:

  • Ingress Gateways – Ein dezidierter Einstiegspunkt für Drittanbieter / externe Clients und Services zur Kommunikation mit Diensten, die innerhalb eines Service Mesh ausgeführt werden.
  • WAN-Verbund über Mesh-Gateways – Eine Möglichkeit, ein Service-Mesh einfach auf mehrere Umgebungen (z. B. verschiedene Regionen / Clouds oder Hybridumgebungen) auszudehnen.
  • Terminating Gateways – Ermöglicht Anwendungen innerhalb des Service Mesh die Kommunikation mit jenen Diensten außerhalb des Mesh, die dem Service Mesh nicht hinzugefügt werden können – entweder aufgrund technischer Einschränkungen des Dienstes selbst (z. B. verwaltete Datenbanken in einer Cloud) oder aufgrund organisatorischer Anforderungen (z.B. Legacy-Anwendungen, die das Unternehmen nicht in einer öffentlichen Cloud betreiben will).
  • Single Sign On – Nutzt den vorhandenen OIDC-Anbieter (z.B. Okta, Ping, Auth0) für die Benutzerauthentifizierung.
  • Audit-Logging – Erfasst wichtige Daten auf Benutzer-/Ereignisebene, um die Einhaltung aller Compliance-Richtlinien zu gewährleisten.
  • UX-Verbesserungen –  Möglichkeit für detailliertere Service-Informationen (z. B. Labelling des Gateway-Typs)

Entwickler: Wie glaubst du wird sich die Software-Architektur in den nächsten Jahren entwickeln? Sprechen wir bald überhaupt noch über Microservices?

Raymond Austin: In Bezug auf die Softwarearchitektur der kommenden Jahre: Ich glaube, wir werden einen anhaltenden Trend zur Implementierung von Microservices-Modellen sehen – und zwar mit einem wachsenden Fokus darauf, wie eine gleichbleibende Nutzererfahrung zwischen traditionellen Plattformen und Scheduling-Runtimes hergestellt werden kann. Das bedeutet wohlgemerkt nicht immer Kubernetes, zumindest nicht in der aktuellen Form. Wir werden weiterhin feststellen, dass sich die Orchestrierungslandschaft ändert und sich damit der „Konsum“ von Plattformen für die Bereitstellung von Anwendungen vereinfacht. Entwickler werden zunehmend deklarative Plattformen erwarten, die ihnen die Möglichkeit bieten, ihre Anwendungen schnell auszuführen.

Ich denke auch, dass es heutzutage in der Welt der Softwarearchitektur viele wirklich komplexe Konzepte gibt – aber was wirklich interessant ist, ist die Tatsache, dass es heute große Unternehmen gibt (einschließlich HashiCorp), um die Funktionsweise von all dem zu vereinfachen. Wir sprechen derzeit viel über Microservices, da es sich insgesamt um eine relativ neue Architektur handelt und diese komplex ist. Mit der Zeit wird diese Architektur jedoch zur Norm. Stattdessen wird der Fokus weiterhin darauf liegen, wie wir konsistente Erfahrungen zwischen Umgebungen und Runtime-Plattformen erstellen können.

Entwickler: Vielen Dank für dieses Interview!

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: