© Susan Schmitz/Shutterstock.com
Java Magazin
Service Mesh mit Istio

Den Microservices-Zoo bändigen

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.

Michael Hofmann, Markus Lackner


Video: Microservices – Durchblick im Framework-Dschungel

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 Persistenzanforderungen mit 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-Anwendung kommen zu den knapp fünfzig Services auch noch mindestens fünfzehn Datenbankservices hinzu. Das ergibt als Zwischenergebnis ungefähr sechzig Prozesse.

Service MeshDer Begriff Service Mesh umschreibt ein Geflecht von (Micro-)Services, die über Netzwerkaufrufe miteinander interagieren und so eine gesamtheitliche Anwendung bilden. Mit steigender Anzahl an Services wird das Aufrufverhalten der einzelnen Komponenten untereinander immer komplexer und analog auch schwieriger zu verstehen bzw. zu beherrschen.

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 Micros...

Java Magazin
Service Mesh mit Istio

Den Microservices-Zoo bändigen

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.

Michael Hofmann, Markus Lackner


Video: Microservices – Durchblick im Framework-Dschungel

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 Persistenzanforderungen mit 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-Anwendung kommen zu den knapp fünfzig Services auch noch mindestens fünfzehn Datenbankservices hinzu. Das ergibt als Zwischenergebnis ungefähr sechzig Prozesse.

Service MeshDer Begriff Service Mesh umschreibt ein Geflecht von (Micro-)Services, die über Netzwerkaufrufe miteinander interagieren und so eine gesamtheitliche Anwendung bilden. Mit steigender Anzahl an Services wird das Aufrufverhalten der einzelnen Komponenten untereinander immer komplexer und analog auch schwieriger zu verstehen bzw. zu beherrschen.

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 Micros...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang