API-Gateway vs. Service Mesh vs. Message Queue – wann nutze ich was?

Hinweis: Dieser Beitrag erschien erstmals im März 2020 und wurde seither grundlegend überarbeitet, um aktuelle Entwicklungen wie die Kubernetes Gateway API und eBPF-basierte Service Meshes einzubeziehen.

Microservices lösen ein Problem, aber sie erzeugen auch ein neues: Sobald die monolithische Anwendung in viele kleine Services zerlegt wurde, muss geklärt werden, wie diese untereinander und mit der Außenwelt kommunizieren. Wer diese Entscheidung für seinen Cluster trifft, landet fast zwangsläufig bei drei Bausteinen: API-Gateway, Service Mesh und Message Queue. Meist ist es jedoch keine Entweder-oder-Entscheidung. Viele DevOps-Teams verwenden diese Ansätze kombiniert, beispielsweise ein API-Gateway für eingehenden Traffic von außen, ein Service Mesh für die Kommunikation zwischen den Diensten und eine Message Queue für asynchrone Aufgaben. Dieser Artikel ordnet die drei Konzepte ein, zeigt ihre Überschneidungen und gibt eine Entscheidungshilfe, wann welcher Baustein sinnvoll ist.

Wo liegt eigentlich das Problem?

Dafür folgt eine kurze Analyse des Problems: Damit Microservices als verteiltes System funktionieren, müssen sie eine lange Liste von Herausforderungen meistern.

Elastizität
Es kann Dutzende oder sogar Hunderte von Instanzen eines bestimmten Microservices geben, von denen jede zu einem beliebigen Zeitpunkt ausfallen kann – etwa durch einen Node-Neustart, einen Out-of-Memory-Fehler oder ein fehlgeschlagenes Deployment. Ein System, das das nicht einkalkuliert, reißt bei jedem einzelnen Ausfall den ganzen Request mit runter. Elastizität bedeutet: Der ausgefallene Payment-Service-Pod verschwindet einfach aus der Liste der ansprechbaren Instanzen, ein neuer übernimmt – ohne dass die aufrufende Anwendung davon etwas merkt.

Lastenausgleich und automatische Skalierung
Mit potenziell Hunderten von Endpunkten, die eine Anfrage bedienen können, sind Routing und Skalierung alles andere als trivial. Es reicht nicht, Anfragen einfach reihum zu verteilen (Round Robin): Eine Instanz, die gerade eine rechenintensive Anfrage verarbeitet, sollte seltener neue Anfragen bekommen als eine gerade freie. Genauere Routing- und Skalierungsentscheidungen – etwa basierend auf aktueller Auslastung statt fester Verteilung – zählen zu den wirksamsten Kostenhebeln in großen Architekturen.

Serviceerkennung
Je verteilter eine Anwendung ist, desto schwieriger wird es, herauszufinden, welche Instanzen eines Services gerade überhaupt existieren und erreichbar sind – IP-Adressen von Pods ändern sich bei jedem Neustart. Service Discovery (Serviceerkennung) löst das, indem Services sich unter einem stabilen Namen registrieren (z. B. payment-service) statt unter einer festen IP-Adresse, und ein Verzeichnis diesen Namen laufend auf die aktuell gültigen Instanzen auflöst.

Rückverfolgung und Überwachung
Eine einzelne Nutzeranfrage kann in einer Microservice-Architektur mehrere Services durchlaufen – ein Kaufvorgang etwa Auth-Service, Payment-Service, Inventory-Service und Notification-Service nacheinander. Schlägt irgendwo in dieser Kette etwas fehl, ist ohne durchgängiges Tracing kaum zu erkennen, welcher der vier Services das Problem verursacht hat. Distributed Tracing (verteilte Rückverfolgung) verknüpft alle Teilschritte einer Anfrage über eine gemeinsame Trace-ID, sodass sich der komplette Weg im Nachhinein rekonstruieren lässt.

Versionierung
Wenn Systeme wachsen, müssen APIs weiterentwickelt werden, ohne bestehende Konsumenten zu brechen – ein anderes Team, das noch gegen /api/v1/orders arbeitet, darf nicht plötzlich ins Leere laufen, nur weil intern längst /api/v2/orders im Einsatz ist. Mehrere API-Versionen müssen deshalb oft parallel angeboten und mit klarem Enddatum ausgemustert werden (Deprecation), statt Breaking Changes ungefragt auszurollen.

Die Lösungen

In diesem Artikel stellen wir die drei zentralen Lösungsansätze für diese Probleme vor: Service Meshes, API-Gateways (inklusive ihrer Kubernetes-nativen Variante, der Gateway API) 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.

Kubernetes-native Variante: Gateway API
Der Betrieb von Microservices auf Kubernetes erfolgt inzwischen kaum noch ohne die Nutzung einer weiteren Variante: der Gateway API. Sie ist der offizielle Nachfolger des klassischen Kubernetes-Ingress-Objekts und behebt dessen größte Schwäche: die Abhängigkeit von controllerspezifischen Annotationen. Letztere sind zwischen verschiedenen Ingress-Controllern nicht portabel. Die Kernressourcen der Gateway API – GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute und ReferenceGrant – haben den Status „General Availability” (GA) erreicht und gelten als produktionsreif. Besonders relevant: Der in vielen Clustern eingesetzte Ingress-NGINX-Controller ist seit März 2026 offiziell retired. Es sind bereits mehrere hochkritische CVEs (u. a. CVSS 8.8) für die verwaiste Codebasis veröffentlicht worden, für die es keine Patches mehr geben wird. Wer noch auf klassischem Ingress läuft, sollte daher die Migration zur Gateway API einplanen, um nicht ohne Sicherheitsupdates weiterzulaufen.

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.

Die Weiterentwicklung: sidecar-lose Meshes
Der größte Kritikpunkt am klassischen Sidecar-Modell – ein zusätzlicher Proxy-Prozess pro Pod, der Ressourcen frisst und Latenz addiert (siehe Vergleichstabelle) – wird inzwischen durch eBPF-basierte Ansätze adressiert. eBPF (extended Berkeley Packet Filter) erlaubt es, Netzwerklogik direkt im Linux-Kernel auszuführen, statt sie in einem separaten Sidecar-Prozess pro Pod laufen zu lassen. Cilium Service Mesh nutzt das für einen sidecar-losen Ansatz auf Node-Ebene. Auch Istio selbst bietet mit Ambient Mesh inzwischen einen Betriebsmodus ohne verpflichtenden Sidecar pro Pod. Für neue Cluster empfiehlt sich daher zunehmend: Cilium als CNI (Container Network Interface) einsetzen, dessen native Mesh-Fähigkeiten mit Hubble zur Observability testen – und erst bei zusätzlichem Bedarf eine separate Mesh-Schicht wie Istio ergänzen, statt sie von vornherein vorauszusetzen.

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 Apache ActiveMQ Artemis. Sie werden aber auch vom jeweiligen Cloud Provider gestellt.

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.

Vergleichstabelle

Bei klassischem Sidecar-Mesh (Istio mit Envoy-Sidecar) entstehen zwei zusätzliche Hops pro Call (Sidecar sendend + Sidecar empfangend), nicht nur einer. Bei Ambient Mesh entfällt das durch die geteilte Node-Proxy-Architektur teilweise.

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

Die 2020er-Prognose dieses Artikels ist inzwischen eingetreten: API-Gateway und Service Mesh sind näher zusammengerückt, als damals absehbar war – die Kubernetes Gateway API übernimmt heute Routing-Aufgaben, die früher exklusiv beim API-Gateway lagen, und moderne Service Meshes wie Istio Ambient Mesh oder Cilium lösen sich zunehmend vom ressourcenintensiven Sidecar-Modell. Der Trend geht dabei nicht in Richtung „immer mehr Mesh“, sondern in Richtung gezielter Einsatz: Teams stellen fest, dass ein modernes CNI wie Cilium bereits einen Großteil dessen abdeckt, wofür früher ein vollständiges Service Mesh nötig war – die zusätzliche Komplexität lohnt sich erst ab einer gewissen Systemgröße. Für die kommenden Jahre ist zu erwarten, dass sich diese Konsolidierung fortsetzt: weniger separate Komponenten, mehr Funktionalität direkt im Kernel (eBPF) und in der Kubernetes-Plattform selbst.ner zeitlich gepufferten Form.

Wer Service Mesh, API-Gateway oder Message Queue deployed, betreibt auch Infrastruktur darunter. ScaleUp bietet SCS-zertifiziertes Managed Kubernetes und Cloud-Hosting zu 100 % in eigenen deutschen Rechenzentren – Open-Source-basiert auf OpenStack und Kubernetes.

Quellen:

https://arcentry.com/blog/api-gateway-vs-service-mesh-vs-message-queue/
https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
https://gateway-api.sigs.k8s.io/