Leseproben
Hanna Prinz INNOQ

„Ein Service Mesh scheint den Technologiestack für Microservices perfekt zu machen. Es ermöglicht die zentrale Kontrolle von Monitoring, Resilienz, Routing und Sicherheit, die dezentral in den Sidecars umgesetzt wird. Damit fügt sich ein Service Mesh harmonisch in Microservices-Architekturen ein und kann API-Gateways und viele Bibliotheken ersetzen.“

Eberhard Wolff INNOQ

„Der Preis eines Service Mesh ist der Aufwand für die Einführung neuer Technologien, ein erhöhter Ressourcenverbrauch und eine höhere Latenz. Im konkreten Fall müssen diese Auswirkungen untersucht und Vor- und Nachteile abgewogen werden.“

Die Stärke einer Microservices-Architektur ist die lose Kopplung der Module. Und gleichzeitig ist diese auch ein großer Nachteil, denn in jedem Microservice müssen Funktionen wie Monitoring, Tracing und Circuit Breaking erneut gelöst werden. Ein Service Mesh verspricht, viele der Funktionen in die Infrastruktur zu ziehen. So wird es endlich kinderleicht, Microservices zu entwickeln und zu bändigen – oder vielleicht doch nicht?

Microservices bedeuten Unabhängigkeit. Also legen die Teams los und es entstehen viele Microservices. Nach dem ersten Problem in Produktion wird klar: Alle Microservices brauchen Logging, Monitoring und Tracing. Um Angriffen vorzubeugen, muss die Kommunikation außerdem authentifiziert und verschlüsselt werden. Eine weitere Herausforderung ist es, die Services vor den Effekten von jederzeit möglichen Netzwerk- oder Service-Ausfällen zu schützen.

Bitte keine Microservices Frameworks

Was tun? Für Entwickler liegt es nahe, technische Probleme mit einem Framework zu lösen. Ein Microservices Framework hat jedoch den Nachteil, dass es nur eine bestimmte Programmiersprache unterstützt. Das schränkt die Auswahl der Implementierungstechnologien für die Microservices ein. Damit gibt das Team eine große Stärke der Microservices auf, nämlich die Technologiefreiheit. Diese Freiheit erlaubt es, für jeden Microservice die beste Technologie zu wählen. Wenn ein anderer Technologiestack oder eine Programmiersprache für ein Detailproblem in einem System besser geeignet ist, kann man diese Technologie einfach in dem betreffenden Microservice für diese Detailprobleme einführen. Wenn die Microservices-Bibliothek mit der neuen Programmiersprache oder dem neuen Technologiestack inkompatibel ist, ist dieser Weg leider unmöglich.

Auch für einen einheitlichen Technologiestack ergibt die Technologiefreiheit Vorteile. Jeder Stack veraltet früher oder später. Durch die Technologiefreiheit kann ein Update auf eine neue Version des Technologiestacks oder einer Bibliothek zunächst in einem einzigen Microservice umgesetzt werden, was das Risiko minimiert. So helfen Microservices dabei, ein System risikoarm modern zu halten. Wenn nun das Microservices Framework mit der neuen Version des Technologiestacks oder der Bibliothek inkompatibel ist, wird das Update entweder erschwert oder ist völlig unmöglich.

Unabhängig davon, ob die technischen Herausforderungen mit Microservices Frameworks oder anders gelöst werden, hat die Entscheidung erhebliche Konsequenzen. Der Netflix-Stack enthält beispielsweise die Java-Bibliothek Hystrix, mit der die Kommunikation zwischen Microservices bei Ausfällen einzelner Microservices abgesichert werden kann. Leider pflegt Netflix diese Bibliothek aber mittlerweile nicht mehr. So wird Code, der diese Bibliothek noch nutzt, plötzlich zu veraltetem Code, der nun so umgeschrieben werden muss, dass er die Bibliothek nicht mehr nutzt.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 8.19 - "Service Mesh"

Alle Infos zum Heft
579897961Das Service Mesh
X
- Gib Deinen Standort ein -
- or -