Wir haben es mittlerweile verstanden: Microservices sind eine tolle Sache. Seit ein paar Jahren wird in der IT über wenig anderes gesprochen und es ist eine überraschend einfache Idee, dass es das Softwaremanagement erleichtern kann, ein großes, durch Interdependenzen geprägtes System in viele kleine, leichte Systeme zu teilen.
Jetzt kommt der Haken: Nachdem man seine Monolith-Anwendung nun in bekömmliche Häppchen zerteilt hat, wie soll man diese nun wieder sinnhaft zusammensetzen? Hier gibt es leider nicht nur eine richtige Antwort auf diese Frage, sondern wie so oft vielschichtige Ansätze, die jeweils von der Anwendung und den individuellen Anforderungen abhängen. Es geht um die Frage, wie sollen die Microservices miteinander kommunizieren? Per Service Mesh? Per API-Gateway? Oder per Message Queue? Die Überlappungen zwischen API-Gateway- und Service-Meshes sind erheblich. Beide liefern Serviceerkennung, Anforderungsrouting, die Authentifizierung, die Durchsatzratenbegrenzung und Monitoringfunktionen. Sie zeigen jedoch Unterschiede in ihren Architekturen und Nutzungsabsichten. Der Hauptzweck eines API-Gateways besteht darin, Datenverkehr von außerhalb ihres Netzwerks zu akzeptieren und intern zu verteilen. Der Hauptzweck eines Service-Meshes besteht darin, den Datenverkehr in ihrem Netzwerk weiterzuleiten und zu verwalten.
Wo liegt eigentlich das Problem?
Dafür eine kurze Analyse des Problems: Damit Microservices funktionieren, müssen sie eine lange Liste von Herausforderungen als verteiltes System meistern:
Elastizität
Es kann Dutzende oder sogar Hunderte von Instanzen eines bestimmten Microservices geben, von denen jede zu einem beliebigen Zeitpunkt aus einer Reihe von Gründen fehlschlagen kann.
Lastenausgleich und automatische Skalierung
Mit potenziell Hunderten von Endpunkten, die eine Anforderung erfüllen können, sind Routing und Skalierung alles andere als trivial. Tatsächlich besteht eine der effektivsten kostensparenden Maßnahmen für große Architekturen darin, die Genauigkeit von Routing- und Skalierungsentscheidungen zu erhöhen.
Serviceerkennung
Je komplexer und verteilter eine Anwendung ist, desto schwieriger wird es, vorhandene Endpunkte zu finden und einen Kommunikationskanal mit ihnen einzurichten.
Rückverfolgung und Überwachung
Eine einzelne Transaktion in einer Microservice-Architektur kann mehrere Services durchlaufen, was es schwierig macht, ihre Reise zu verfolgen.
Versionierung
Wenn Systeme ausgereift sind, ist es von größter Bedeutung, verfügbare Endpunkte und APIs zu aktualisieren und gleichzeitig sicherzustellen, dass ältere Versionen verfügbar bleiben.
Die Lösungen
In diesem Artikel stellen wir drei mögliche Lösungsansätze für diese Probleme vor, die derzeit am häufigsten in Frage kommen: Service Meshes, API Gateways und Message Queues. Natürlich gibt es auch eine Reihe anderer Ansätze, die genutzt werden könnten, angefangen bei einfachem statischen Lastenausgleich (Loadbalancing) über feste IP-Adressen bis hin zu zentralen Orchestrierungsservern. In diesem Beitrag konzentrieren wir uns jedoch auf die beliebtesten und in vielerlei Hinsicht ausgefeiltesten Optionen.
API-Gateways
Ein API-Gateway ist der große Bruder des guten alten Reverse-Proxys für HTTP-Aufrufe. Es handelt sich um einen skalierbaren, normalerweise mit dem Internet verbundenen Server, der Anforderungen sowohl vom öffentlichen Internet als auch von internen Diensten empfangen und an die am besten geeignete Microservice-Instanz weiterleiten kann. API-Gateways bieten eine Reihe hilfreicher Funktionen, darunter Lastenausgleich und Integritätsprüfungen, API-Versionierung und -Routing, Anforderungsprüfung und -autorisierung, Datentransformation, -analyse, Protokollierung, SSL-Beendigung und vieles mehr. Beispiele für beliebte Open-Source-API-Gateways sind Kong oder Tyk. Die meisten Cloud-Anbieter bieten auch ihre eigene Implementierung an, z.B. AWS API Gateway, Azure Api Management oder Google Cloud Endpoints.
Die Vorteile
API-Gateways bieten leistungsstarke Funktionen, sind vergleichsweise wenig komplex und für erfahrene Web-Veteranen leicht verständlich. Sie bieten einen soliden Schutz gegen das öffentliche Internet und übernehmen viele sich wiederholende Aufgaben wie Benutzerauthentifizierung oder Datenvalidierung.
Die Nachteile
API-Gateways sind ziemlich zentralisiert. Sie können zwar horizontal-skalierbar bereitgestellt werden. Im Gegensatz zu Service-Meshes müssen neue APIs jedoch an zentraler Stelle registriert oder die Konfiguration geändert werden. Aus organisatorischer Sicht sollten sie daher auch nur von einem Team gemanagt werden.
Service-Meshes
Service Meshes sind dezentrale, selbstorganisierende Netzwerke zwischen Microservice-Instanzen, die den Lastausgleich, die Endpunkterkennung, Integritätsprüfungen, das Monitoring und Rückverfolgung übernehmen. Sie arbeiten, indem sie jeder Instanz einen kleinen Agenten hinzufügen, der als “Begleitwagen” (engl. Sidecar) bezeichnet wird. Der Service-Mesh vermittelt den Datenverkehr und die Registrierung von Instanzen, übernimmt die Erfassung von Metriken und die Wartung. Während die meisten Service-Meshes konzeptionell dezentralisiert sind, verfügen sie über ein oder mehrere zentrale Elemente, um Daten zu sammeln oder Admin-Schnittstellen bereitzustellen. Beliebte Service-Mesh Beispiele sind Istio, Linkerd oder Hashicorp’s Consul.
Vorteile
Service-Meshes sind dynamischer und können leicht ihre Form ändern, um neue Funktionen und Endpunkte aufzunehmen. Ihr dezentraler Charakter erleichtert die Arbeit an Mikrodiensten in isoliert arbeitenden Teams.
Nachteile
Service-Meshes basieren auf vielen beweglichen Teilen und können daher sehr schnell sehr komplex werden. Die vollständige Nutzung von Istio erfordert beispielsweise die Bereitstellung eines separaten Trafficmanagers, eines Telemetriesammlers, eines Zertifikatemanagers und eines Sidecarprozesses für jeden Knoten. Sie sind auch eine relativ junge Entwicklung für etwas, das das Rückgrat Ihrer IT-Architektur bilden soll.
Message-Queues
Auf den ersten Blick scheint der Vergleich von Service-Meshes mit einem Message Queue (deutsch: Nachrichtenwarteschlange) wie der Vergleich von Äpfeln mit Orangen: Sie sind völlig verschiedene Dinge, aber sie lösen das gleiche Problem, wenn auch auf sehr unterschiedliche Weise.
Mit einem Message Queue können Sie komplexe Kommunikationsmuster zwischen Diensten herstellen, indem Sie Sender und Empfänger entkoppeln. Sie erreichen dies mithilfe einer Reihe von Maßnahmen wie themenbasiertem Routing oder Publish-Subscribe-Messaging sowie durch gepuffertes Abarbeiten, das es für mehrere Instanzen einfacher macht, verschiedene Aspekte einer Aufgabe im Laufe der Zeit zu verarbeiten.
Message Queues gibt es schon seit ewigen Zeiten, was zu einer großen Auswahl von Alternativen führt: Beliebte Open-Source-Alternativen sind Apache Kafka, AMQP Broker wie RabbitMQ oder HornetQ. Sie werden aber auch vom jeweiligen Cloud Provider gestellt, wie AWS SQS oder Kinesis, Google PubSub oder Azure Service Bus.
Vorteile
Das einfache Entkoppeln von Sendern und Empfängern ist ein wirksames Konzept, das eine Reihe anderer Konzepte wie Integritätsprüfungen, Routing, Endpunkterkennung oder Lastausgleich unnötig macht. Instanzen können relevante Aufgaben aus einer gepufferten Warteschlange auswählen, sobald sie dazu bereit sind. Dies ist besonders effektiv, wenn Entscheidungen zur automatischen Orchestrierung und Skalierung auf der Anzahl der Nachrichten in jeder Warteschlange basieren, was zu ressourceneffizienten Systemen führt.
Nachteile
Message Queues sind bei der Anforderungs- / Antwortkommunikation nicht gut. Einige erlauben es, dies auf bestehende Konzepte abzustimmen, aber es ist nicht wirklich das, wofür sie gemacht sind. Aufgrund ihrer Pufferung können sie einem System auch eine erhebliche Latenz hinzufügen. Sie sind zudem auch ziemlich zentralisiert (obwohl horizontal skalierbar) und können im großen Maßstab recht kostspielig sein.
Also, wann sollte man welche Lösung wählen?
Eigentlich ist das nicht unbedingt eine Entweder-Oder-Entscheidung. Tatsächlich kann es durchaus sinnvoll sein, die öffentlich zugängliche API mit einem API-Gateway zu versehen, ein Service-Mesh für die Kommunikation zwischen Diensten auszuführen und Dinge mit einem Message Queue für die asynchrone Aufgabenplanung zu unterstützen. Ein Service-Mesh kann mit einem API-Gateway zusammenarbeiten, um externen Datenverkehr auf effiziente Weise zu akzeptieren und diesen Datenverkehr dann effektiv weiterzuleiten, sobald er sich im Netzwerk befindet. Die Kombination dieser Technologien kann eine leistungsstarke Methode sein, um die Verfügbarkeit und Ausfallsicherheit von Anwendungen zu gewährleisten und gleichzeitig sicherzustellen, dass Ihre Anwendungen problemlos verwendet werden können.
Bei einer Bereitstellung mit einem API-Gateway und einem Service-Mesh wird eingehender Datenverkehr von außerhalb des Clusters zuerst über das API-Gateway und dann in das Mesh geleitet. Das API-Gateway kann Authentifizierung, Edge-Routing und andere Edge-Funktionen übernehmen, während das Service-Mesh eine detaillierte Beobachtung und Kontrolle Ihrer Architektur bietet.
Wenn man sich jedoch nur auf die Kommunikation zwischen Diensten konzentrieren möchte, könnte eine mögliche Antwort sein:
- Wenn Sie bereits ein API-Gateway für Ihre öffentlich zugängliche API ausführen, können Sie die Komplexität ebenso gering halten und dieses für die Kommunikation zwischen Diensten wiederverwenden.
- Wenn Sie in einem großen Unternehmen mit isolierten Teams und schlechter Kommunikation arbeiten, bietet Ihnen ein Service-Mesh ein Höchstmaß an Unabhängigkeit, sodass Sie im Laufe der Zeit problemlos neue Services hinzufügen können.
- Wenn Sie ein System entwerfen, bei dem einzelne Schritte über die Zeit verteilt sind, z.B. ein YouTube-ähnlicher Dienst, bei dem das Hochladen, Verarbeiten und Veröffentlichen von Videos einige Minuten dauern kann, verwenden Sie dazu einen Message oder einen Task Queue.
Was die Zukunft bringt
Trotz allem Hypes sind Service-Meshes ein ziemlich junges Konzept, mit Istio als die beliebteste Alternative, die jedoch rasch weiterentwickelt wird. Es ist zu erwarten, dass Service-Meshes wie Istio zukünftig viel von dem enthalten werden, was man heute von einem API-Gateway bekommt. Beide Konzepte werden zunehmend zu einem zusammengeführt, was zu einem dezentraleren Netz von Diensten führt, das sowohl externen API-Zugriff als auch interne Kommunikation bietet — möglicherweise sogar in einer zeitlich gepufferten Form.
ScaleUp ist ist Hosting-Anbieter für OpenSource Multi-Cloud Lösungen basierend auf OpenStack und Kubernetes, die zu 100% in eigenen Rechenzentren in Deutschland gehostet werden.
