Unternehmen, die von monolithischen Anwendungen zu einer Microservices-Infrastruktur wechseln, die über Container zur Verfügung gestellt wird, sollten das zu Grunde legende Service-Mesh optimieren. Autor und Berater Thomas Joos erläutert warum.
Im Service Mesh tragen die Proxys die Bezeichnung „Sidecars“, da sie parallel zu den Services arbeiten und nicht in den Services selbst.
(Bild: Maik Steiskal auf Pixabay)
Wenn Unternehmen neue Dienste oder Anwendungen einführen, stellt sich häufig die Frage, ob der Fokus auf monolithischen Anwendungen liegen soll, oder ob der Einsatz von Microservices mit einem Service-Mesh sinnvoll sind. Beide Ansätze haben Vor- und Nachteile. Allerdings wird vor allem bei komplexen Systemen zunehmend auf Microservices gesetzt.
Einfach ausgedrückt bestehen Anwendungsmonolithen aus Diensten und Funktionen, die in einem einzelnen großen Block oder Server zusammengefasst sind. Zudem sind diese eng miteinander verbunden und verwoben. Das führt dazu, dass eine solche Anwendung als Ganzes betrieben, gewartet und aktualisiert werden muss.
Zudem werden häufig proprietäre Schnittstellen verwendet, Ressourcen wie Hardware spielen eine wichtige Rolle, und die einzelnen Teilsysteme und Komponenten werden nicht gegliedert und getrennt voneinander betrieben. In der Vergangenheit wurden solche Systeme meistens auf dedizierten Servern oder Clustern betrieben. Das sorgt dafür, dass die Bereitstellung schnell erfolgt; denn die Komponenten sind aufeinander abgestimmt.
Viele Anwendungen aus der IT-Vergangenheit, etwa ERP-Systeme und Branchenapplikationen aber auch Datenbankanwendungen, wurden auf Basis der monolithischen Struktur erstellt. Entsprechend schwierig gestaltet sich die Eingliederung in Microservices.
Die Zeit der Monolithen ist angezählt
Zu den heutigen Trends gehört es, die monolithischen Infrastrukturen aufzubrechen und die einzelnen Teilkomponenten in Microservices unterteilt sowie Hardware-unabhängig getrennt voneinander zu betreiben. Dabei kommen meistens Container zum Einsatz, in denen die einzelnen Dienste/Services bereitgestellt werden. Dabei besteht auch die Möglichkeit, dass ein Service auf mehreren Containern betrieben wird, zum Beispiel aus Gründen der Skalierung.
Die einzelnen Komponenten/Services lassen sich auf diese Weise getrennt voneinander aktualisieren und warten. Der Effekt: Das gesamte System wird transparenter und wesentlich flexibler.
So lassen sich neue Funktionen in den einzelnen Diensten schneller implementieren. Die Leistung erhöht sich, weil jeder einzelne Dienst getrennt von den anderen skaliert werden kann. Services lassen sich auch durch zusätzliche Container leicht skalieren.
Das Aber: Da die Bereitstellung der einzelnen Microservices über Container getrennt voneinander stattfindet, steigt im Gegenzug zur gewonnenen Flexibilität sowohl der initiale Aufwand für die Bereitstellung als auch die Komplexität der Umgebung.
Service-Mesh beim Einsatz von Microservices
Beim Einsatz von Microservices kommt zwangsläufig auch ein Service-Mesh zum Einsatz. Hier wird definiert, wie die einzelnen Dienste und Teile der kompletten Anwendung und die eingesetzten Container Daten miteinander austauschen und teilen. Bei der Kommunikation zwischen Services und den einzelnen Containern spielen Identity Management, Verschlüsselung, Zertifikate, Access Control und Telemetrie eine wichtige Rolle.
Außerdem muss der Verkehr zwischen den Services verwaltet und der stabile Zustand der Kommunikation sichergestellt sein. Das sind nur einige Beispiele der Aufgaben, die ein Service-Mesh in einer Container-Umgebung mit Microservices erledigen muss.
Ein Service-Mesh hat die Aufgabe alle Services in einer Microservices-Infrastruktur miteinander zu koordinieren, den Datenaustausch zu steuern und vor allem die Zusammenarbeit zu optimieren. Nur ein optimiertes Service-Mesh kann sicherstellen, dass die einzelnen Microservices ihre Funktionen so zur Verfügung stellen, dass der komplette Dienst auch problemlos funktioniert. Je komplexer eine Microservices-Infrastruktur ist, desto sinnvoller ist der Einsatz eines Service-Mesh, um die Kommunikation im Griff zu behalten und Fehler schneller diagnostizieren zu können.
Auf der Basis von Regeln
Eine Microservices-Infrastruktur wird durch jeden Container und jeden Service umfassender und damit komplizierter. Vor allem bei Fehlern und Leistungseinbrüchen kann ein Service-Mesh wesentlich schneller und leichter eine Lösung aufzeigen, wie eine manuelle Konfiguration der Datenverbindungen einzelner Services. Durch die Erfassung der wichtigsten Kennzahlen für die Leistung im Service-Mesh, können Regeln ständig angepasst und dadurch optimiert werden.
Microservices werden getrennt voneinander entwickelt und sind so unabhängig, dass der Ausfall eines einzelnen Service nicht den Ausfall der kompletten zugrundeliegenden App bedeutet. Damit zum Beispiel ein Shop-System, das auf Microservices aufbaut, funktioniert, muss definiert werden, welche einzelne Dienste in der Struktur Zugriff auf die verschiedenen Daten und Funktionen im Unternehmen und auf andere Services hat.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
Sucht ein Kunde ein Produkt, dann muss der Service, der dafür zur Verfügung steht, Zugriff auf die Datenbank erhalten, in der die Produkte gespeichert sind. Dieser Service muss wiederum mit dem Service kommunizieren, der den Warenkorb im Shop-System darstellt.
Werden Kunden auch Produkte empfohlen, die auf der Auswahl bereits gekaufter Produkte aufbauen, ist eine Kommunikation mit der Datenbank der Produkte notwendig und anderer Daten, auf deren Basis Produkte empfohlen werden. Wenn ein Service in einer solchen Infrastruktur überlastet ist, betrifft das entsprechend auch die anderen Bereiche, da der Endanwender schlicht und ergreifend durch einen Flaschenhals ausgebremst wird.
Vorsicht Steinschlag! Die Monolithen brökeln.
(Bild: Clker-Free-Vector-Images auf Pixabay)
Ein solches Netzwerk aus Services, das nur zusammen eine Funktion zur Verfügung stellt, die Anwender benötigen, zum Beispiel einen Webshop, sollte also ständig optimiert und skaliert werden. Nur dann können Microservices ihre kompletten Vorteile ausspielen.
Häufig erfordert es eine solche Infrastruktur auch, dass einzelne Services Daten von anderen Services abrufen. Auch hier muss definiert werden, wie das erreicht werden soll, ohne die Abhängigkeiten zu groß zu machen, wie bei monolithischen Anwendungen. Auch dazu wird ein Service-Mesh genutzt.
Sidecars im Service-Mesh
Die Übertragung von Daten in einer Microservices-Infrastruktur wird mit Regeln gesteuert. Diese Regeln werden vom Service-Mesh genutzt, um die Logik der Kommunikation zwischen Services in die Infrastrukturschicht zu extrahieren. Das Service-Mesh wird dazu als ein Array aus Proxys in die Anwendung integriert, die durch die Microservices-Infrastruktur bereitgestellt wird.
Die Funktion entspricht der eines Webproxy im Unternehmen, bei denen Anfragen der Anwender entgegengenommen und geprüft werden. Danach wird die aufgerufene Webseite auf den Proxy umgeleitet, der diese prüft und an den Anwender weitergibt. Der Proxy steht also als Schnittstelle zwischen Anwendern und Diensten.
Im Service-Mesh werden die Anfragen der einzelnen Services über Proxys in einer eigenen Schicht übertragen. Die Proxys tragen die Bezeichnung „Sidecars“, da sie parallel zu den Services arbeiten, nicht in den Services selbst. Die Verbindungen der einzelnen Proxys bilden das Mesh-Netzwerk. Diese Komponenten gilt es in Einklang zu bringen und miteinander zu verknüpfen.