Michael Hofmann Freiberufler

„Die verteilte Anwendung sollte bezüglich Last und Ausfallsicherheit genügend Reserven haben. Eine Verdopplung der Serviceanzahl, um die Verfügbarkeit zu erhöhen, ist das Minimum.“

Markus Lackner Softwareentwickler in einem österreichischen Bankenrechenzentrum

„Die Stärken einer transparenten Sidecar-Infrastruktur liegen auf der Hand: Die Entwicklung von Anwendungen wird von wiederkehrenden Aufgaben befreit und kann sich auf das Wesentliche, die Businesslogik, konzentrieren.“

Mit dem Einzug von Microservices als Grundlage einer modernen verteilten Anwendungsarchitektur entstehen immer öfter komplexe Laufzeitumgebungen. Bei der Verwaltung der steigenden Zahl an Services und Instanzen tauchen schnell typische Problemstellungen auf. Dabei entsteht ein Geflecht an Services, das Service Mesh. Da die Microservices in der Regel auf Cloud-Plattformen betrieben und Cloud Native entwickelt wurden, braucht es Werkzeuge, die bei der Verwaltung des Service Mesh in der Cloud helfen. Istio ist ein Werkzeug, das helfen soll, diesen wilden Zoo an Services in den Griff zu bekommen.

Eine Microservices-Anwendung, die zum Beispiel aus einer zweistelligen Anzahl von Microservices besteht, kann bezüglich ihrer Verwaltung schon problematisch werden. In der Regel wird jede neue Version eines Microservice parallel zu vorhandenen Versionen desselben Microservice in Produktion deployed. Das geschieht deswegen, weil eine Abkündigung einer alten Version des Microservice nicht so einfach durchsetzbar ist und
man die neue Version ohne Anpassungen an ältere Versionen mit weniger Nebeneffekten einfacher in Produktion bringt. Der Kompromiss, der dabei eingegangen wird, führt dazu, dass mehrere Versionen eines Microservice parallel existieren. Wenn durchschnittlich jeder Service in zwei oder drei Versionen parallel existiert, was nicht unüblich ist, verdoppelt bzw. verdreifacht sich die Anzahl der Services ganz schnell. Eine Microservices- Anwendung, die ursprünglich einmal mit beispielsweise fünfzehn Services gestartet ist, ist entsprechend gleich bei knapp fünfzig Services angelangt.

Was bei der Betrachtung der Services gerne zu kurz kommt, sind die notwendigen Datenbanksysteme, da ein Microservice in der Regel auch Persistenzanforderungenmit sich bringt. Die beteiligten Datenbankinstanzen gehören demnach auch zum Service Mesh (Kasten „Service Mesh“). Dabei kann man noch froh sein, wenn sich mehrere Versionen eines Microservice dieselbe Datenbank teilen können, weil man es geschafft hat, das Datenbankschema abwärtskompatibel zu gestalten. In Erweiterung des obigen Beispiels der Microservices-Anwendungkommen zu den knapp fünfzig Services auch noch mindestens fünfzehn Datenbankservices hinzu. Das ergibt als Zwischenergebnis ungefähr sechzig Prozesse.

Doch damit noch nicht genug. Die verteilte Anwendung sollte auch bezüglich Last und Ausfallsicherheit genügend Reserven mit sich bringen. Eine Verdopplung der Serviceanzahl, um die Verfügbarkeit zu erhöhen, ist in diesem Zusammenhang das einzuplanende Minimum. In unserem Anwendungsbeispiel wurde die magische Grenze von einhundert Prozessinstanzen gesprengt – bei anfänglich nur fünfzehn Microservices. Zusätzliche Faktoren wie etwa Staging-Umgebungen oder spezielle Multi-Mandant-Anforderungen können die Zahl nochmals deutlich in die Höhe treiben, oder lassen mehrere komplexe Service Meshes entstehen, die auch verwaltet werden müssen.

In der Konsequenz eines Service Mesh ergeben sich verschiedene Funktionalitäten, die ein Verwaltungswerkzeug bereitstellen muss. Angefangen bei Service Discovery und Load Balancing bis hin zu Resilienz und Failure Recovery. Damit wären zumindest die minimalen Notwendigkeiten der Service-zu-Service- Kommunikation abgedeckt. Für die Fehleranalyse ist es notwendig, die Aufrufketten der einzelnen Services nachverfolgen zu können. In der Regel ermöglichen das Tracing-Werkzeuge. Für die Ops-Kollegen sind Metrics und Monitoring für den stabilen Betrieb der verteilten Anwendung unerlässlich, und ohne Security (Access Control und End-to-End Authentication) kommen die wenigsten Anwendungen aus. Auch ein Rate Limiting ist manchmal notwendig, um eine Überlastung der verteilten Anwendung zu vermeiden.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 8.18 - "Privacy by Design: Mit Netz und doppeltem Boden"

Alle Infos zum Heft
579847848Service Mesh mit Istio
X
- Gib Deinen Standort ein -
- or -