Nach anfänglicher Euphorie macht sich unter vielen Entwickelnden nun allmählich Ernüchterung breit, was die Arbeit mit Microservices-Architekturen betrifft. Obwohl Microservices nach wie vor signifikante Vorteile bieten, wie eine schnellere Auslieferung, bessere Skalierbarkeit und eine größere Unabhängigkeit von spezifischen Technologien, haben sich auch erhebliche Herausforderungen gezeigt. Im Gegensatz zu monolithischen Architekturen, bei denen alle Komponenten eng miteinander verwoben sind, bilden Microservices ein verteiltes System. Diese Dezentralisierung erschwert es, die einzelnen Services zu überwachen, zu steuern und umfassend abzusichern. Zudem erfolgt die Kommunikation zwischen den Microservices über das Netzwerk, was nicht nur die Geschwindigkeit beeinträchtigen kann, sondern auch potenziell die Stabilität des gesamten Systems gefährdet.

Trotz dieser komplexen Herausforderungen sind Microservices weiterhin beliebt, was darauf hinweist, dass ihre Vorteile oftmals die dabei entstehenden Schwierigkeiten überwiegen. Um die Komplexität von Microservice-Architekturen zu reduzieren, gewinnt das Konzept des Service Mesh zunehmend an Bedeutung.

Doch was genau ist ein Service Mesh, warum und wann sollte es eingesetzt werden, und könnte es die Zukunft der Microservices-Architektur nachhaltig prägen? Mit genau diesen Fragen befassen sich unsere Xperten in unserer zweiteiligen Blogreihe.

Im ersten Teil werfen unsere Xperten einen Blick auf die Herausforderungen von Microservice-Architekturen und beleuchten, wie ein Service Mesh dabei helfen kann, diese zu bewältigen. Wir erklären die Grundlagen dieser Infrastrukturschicht und stellen die gängigsten Implementierungen vor.

Herausforderungen von Microservices

Für Entwickelnde ist es oft naheliegend, technische Herausforderungen mit einem gleichbleibenden Framework zu bewältigen. Ein Microservices-Framework bringt jedoch den Nachteil mit sich, dass es in der Regel nur eine bestimmte Programmiersprache unterstützt. Dadurch wird die Auswahl der Technologien, die für die Implementierung der Microservices verwendet werden können, eingeschränkt. Das führt dazu, dass ein wesentlicher Vorteil von Microservices – die Technologie-Freiheit – verloren geht. Diese Freiheit ermöglicht es, für jeden Microservice die am besten geeignete Technologie zu wählen. Wenn bspw. eine andere Programmiersprache oder ein anderer Technologie-Stack besser für ein spezifisches Problem geeignet ist, kann dieser problemlos in dem jeweiligen Microservice verwendet werden. Ist das verwendete Framework jedoch mit der neuen Programmiersprache oder dem neuen Technologie-Stack nicht kompatibel, wird diese Flexibilität stark eingeschränkt oder sogar unmöglich.

Auch innerhalb eines einheitlichen Technologie- Stacks bietet die Technologie-Freiheit erhebliche Vorteile. Jede Technologie wird früher oder später veralten und somit zum Risiko oder gänzlich unbrauchbar. Microservices-Architekturen ermöglichen es, ein Upgrade auf eine neue Version des Technologie-Stacks oder einer Bibliothek zunächst in einem einzigen Microservice zu testen. Nicht nur das Risiko wird dadurch reduziert, auch die schrittweise Modernisierung eines Systems wird wesentlich erleichtert. Sollte das Microservices-Framework jedoch nicht mit der neuen Version des Technologie-Stacks oder der Bibliothek kompatibel sein, wird das Update erheblich erschwert oder sogar vollständig blockiert.

Die Verwendung verschiedener Bibliotheken in einer großen und komplexen Microservices-Architektur kann mehrere problematische Konsequenzen haben:

• Inkompatibilität und Inkonsistenz: Bibliotheken können unterschiedliche Versionen, APIs und Konfigurationsanforderungen aufweisen. Sind verschiedene Microservices untereinander oder mit der zugrunde liegenden Infrastruktur nicht kompatibel, führt dies oftmals zu Inkonsistenzen. Unterschiedliche Fehlerbehandlung, Logging-Methoden oder Sicherheitspraktiken in den Bibliotheken können zu unvorhersehbarem Systemverhalten und schwer auffindbaren Bugs führen.
• Wartungsaufwand und technische Schulden: Die Pflege und Aktualisierung einer Vielzahl von Bibliotheken erhöht den Wartungsaufwand beträchtlich. Jede Bibliothek muss separat verwaltet und regelmäßig aktualisiert werden, um Sicherheitslücken zu schließen und neue Funktionen zu integrieren. Das kann schnell zu technischen Schulden führen, insbesondere wenn Bibliotheken veralten oder nicht mehr gepflegt werden.

Eine mögliche Lösung für all diese Probleme bietet der Einsatz eines Service Mesh.

Warum ein Service Mesh nutzen? Eine Einführung in Service Mesh

Microservices, die ein Service Mesh verwenden, können auf viele zuvor notwendige Bibliotheken verzichten, wie etwa solche für Monitoring, Tracing und Circuit Breaking. Ein Service Mesh verlagert diese und weitere Funktionen von der Anwendungsebene in die Infrastruktur.

Es ist nicht das erste Konzept, das diese Strategie verfolgt, aber das erste, das sich nahtlos in die dezentrale Natur einer Microservice-Architektur einfügt. Während andere Lösungen wie API-Gateways auf zentrale Komponenten setzen, stellt ein Service Mesh jeder Microservice-Instanz eine zusätzliche Anwendung zur Seite, in der Funktionen wie Monitoring und Circuit Breaking realisiert werden. Diese zusätzliche Anwendung kommuniziert mit der Microservice-Instanz über den localhost, ein Ansatz, der als „Sidecar“ bekannt ist. Sämtlicher ein- und ausgehender Datenverkehr der Microservice-Anwendung wird über diese Sidecar-Anwendung geleitet, die auch als Service Proxy bezeichnet wird. Um den Datenverkehr automatisch an die Service Proxys zu lenken, werden die Netzwerkkonfigurationen so angepasst, dass die Microservices selbst unverändert bleiben.

Service-Mesh-Implementierungen

Es gibt zahlreiche Service-Mesh-Implementierungen, die sich in Funktionalität, Architektur und unterstützten Plattformen unterscheiden. Zu den bekanntesten und am häufigsten verwendeten gehören:

• Istio ist eine der bekanntesten und weitverbreitetsten Service-Mesh-Implementierungen. Entwickelt von Google, IBM und Lyft, bietet Istio eine umfassende Lösung für das Management von Microservices-Kommunikation. Istio verwendet Sidecar-Proxys, um die Kommunikation zwischen Microservices zu verwalten, und bietet eine umfangreiche API zur Steuerung und Überwachung des Verkehrs.
• Linkerd ist ein weiteres beliebtes Service Mesh, das ursprünglich von Buoyant entwickelt wurde. Es ist bekannt für seine Nutzungsfreundlichkeit und seine einfache Implementierung. Linkerd zeichnet sich durch seine einfache Konfiguration und den geringen Overhead aus, was es zu einer beliebten Wahl für kleinere und mittlere Deployments macht.
• Consul Connect ist eine Service-Mesh-Lösung, die als Teil der Consul-Plattform von HashiCorp angeboten wird. Consul Connect ist gut in die Consul-Plattform integriert, die auch eine Service Discovery sowie ein Konfigurationsmanagement umfasst.
• AWS App Mesh ist eine von Amazon Web Services angebotene Service-Mesh-Lösung, die speziell für AWS-Umgebungen entwickelt wurde. AWS App Mesh ist besonders nützlich für Unternehmen, die stark in die AWS-Cloud integriert sind.
• Kuma ist ein Service Mesh, das von Kong Inc. entwickelt wurde und sowohl für Kubernetes als auch andere Umgebungen verwendet werden kann. Kuma legt großen Wert auf Einfachheit und Skalierbarkeit, bietet eine nutzungsfreundliche Konfiguration.

Im nächsten Teil unserer Reihe beleuchten wir die wichtigsten Features eines Service Mesh, darunter das Monitoring, die Resilienz, das Routing und die Sicherheitsaspekte. Gleichzeitig gehen wir auch auf die Herausforderungen ein, die mit der Implementierung verbunden sind. Dazu gehören insbesondere die hohe Lernkurve, die entstehenden Kosten, die erhöhte Latenz und der Ressourcenbedarf. Unsere Xperten geben dabei wertvolle Einblicke, wie diese Herausforderungen gemeistert werden können.

Quellen

www.istio.io
www.smi-spec.io
www.redhat.com