API Gateway und Service Mesh im Kontext von Service-Konnektivität

Keine Kommentare

Wenn man sich mit der Entwicklung von Microservices und der Konnektivität dieser beschäftigt, stolpert man unweigerlich über Begriffe / Muster von API Gateway und Service Mesh. Aber warum gibt es diese Patterns bzw. Technologien überhaupt? Manchmal passiert es auch, dass die Patterns inhaltlich miteinander vertauscht werden, da ein vertieftes Verständnis für die Anwendung der Patterns fehlt und ein Tutorial nicht unbedingt die beste Grundlage bildet. Zu Beginn ist es wichtig, erstmal einen Blick auf das OSI-Netzwerkschichtenmodell zu werfen. Dieses Modell stellt die Grundlage für alle nachfolgenden Überlegungen dar.

OSI-Netzwerkschichtenmodell

OSI Model
Das Modell beschreibt als Referenz die entsprechenden Netzwerkprotokolle in Form von Schichten. Im Laufe des Blogposts werden wir immer wieder auf dieses Modell zurückkommen.
In verschiedenen Blogposts wurde das API Gateway schon im Detail beschrieben, hier sollen die wichtigsten Punkte für einen möglichen Vergleich mit einem Service Mesh nun zusammengefasst werden.

API Gateway

Ein API Gateway fungiert als einziger Zugriffspunkt in einem Cluster, einem Datenzentrum oder für eine Gruppe von verteilten Diensten. In der Netzwerktopologie wird dies oft als North-South-Traffic bezeichnet. Typischerweise benutzen mobile Clients diese Art von Netzwerkverkehr.
Es ist auch durchaus möglich, dass man API Gateways für die Kommunikation zwischen zwei im selben Rechenzentrum eingesetzten Produkten verwendet. In diesem Fall kann es auch zu einem East-West-Traffic kommen.
Ein API Gateway nimmt Aufrufe von Routen entgegen und leitet diese an entsprechende Dienste weiter. Dabei kann es u.a. auch Protokolle übersetzen.

Die Verwendung eines API Gateways bietet verschiedene Vorteile:
Abstraktion: Ein API Gateway kann die Komplexität der darunter liegenden (Mikro)services abstrahieren und eine einheitliche Sicht für die Konsumenten der APIs schaffen.
Authentifizierung / Autorisierung: Ein API Gateway kann sich um die Authentifizierung kümmern und u.a. die Token-Informationen an die Dienste weiterleiten.
Rate-Limiting: Ein API Gateway kann eingehenden und ausgehenden API-Traffic drosseln
API-Monitoring: Ein API Gateway kann Monitoring auch auf Grundlage bestimmter Metriken des ein- und ausgehenden Traffics vornehmen.
Monetarisierung: Ein API Gateway kann auch bei der Entwicklung von Monetarisierungsregeln hinsichtlich der Nutzung der APIs unterstützen. Dies basiert dann nicht nur auf den Metriken aus dem Monitoring.
Transformationen: Ein API Gateway kann bei der Übersetzung/Transformation von API-Anfragen/Antworten unterstützen. Hierbei sollten aber nur Transformationen von Protokollen, wie beispielsweise XML zu JSON, vorgenommen werden.

Zusammenfassend konzentrieren sich API Gateways auf die Kommunikation der Applikationsschicht bzw. Layer 7 nach dem OSI-Modell.

Arten von API-Gateways

Aus der Einsatzperspektive gibt es zwei Möglichkeiten, API Gateways zu verwenden:
Interne API Gateways: fungieren als Gateway für eine Gruppe von Diensten oder ein entsprechendes API-Produkt
Edge-API Gateway: dient als Gateway für Kunden von externen Organisationen

Service Mesh

Ein Service Mesh ist ein Technologieansatz, der die Service zu Service Kommunikation innerhalb eines verteilten Softwaresystems verwaltet. Service Meshes sollen im Regelfall den East-West-Typ der Netzwerkkommunikation verwalten. East-West-Traffic zeigt einen Verkehrsfluss innerhalb eines Datenzentrums, Kubernetes-Clusters oder eines verteilten Systems an.
Service Meshes bestehen aus zwei wichtigen Komponenten:
Control Plane
Data Plane
Die sogenannten Sidecar Proxys, die gemeinsam mit dem jeweiligen Service betrieben werden, bezeichnet man als Data Plane.
Concept Service Mesh
Ein Service Mesh ermöglicht, die Geschäftslogik der Anwendung von Themen des sogenannten Off-Loadings zu trennen.

Info: Off-Loading
Unter Off-Loading fasst man die Elemente der Cross-Cutting Concerns zusammen, wie Zertifikatsverwaltung, Authentifizierung, SSL-Terminierung, Überwachung, Protokollübersetzung oder Drosselung.

Netzwerk- und Trafficmanagement

Durch den Einsatz eines Service Mesh lässt sich eine dynamische Service-Discovery durchführen. Ein Sidecar-Proxy unterstützt beim Load-Balancing, Rate-Limiting und beim Routing des Traffics, um z.B. einen A/B-Test durchzuführen, was bei einem Canary Release hilfreich sein kann.

Monitoring und Resilience

Ein Service Mesh unterstützt distributed traceability, was das Monitoring bezogen auf die Anzahl der Requests, Success Rates, Responselatenzen und somit die Fehlersuche einbezieht. Da das Service Mesh Health-Checks, Retrys, Timeouts und Circuit-Breaking bietet, verbessert es die Zuverlässigkeit der Anwendung.

Sicherheit

Ein Service Mesh ermöglicht ein gegenseitiges TLS zwischen den Diensten, was dazu beiträgt, die Sicherheit der Service-zu-Service-Kommunikation zu erhöhen. Ebenfalls lassen sich auch Zugriffe über ACLs als Sicherheitsrichtlinien implementieren.
Zusammenfassend decken Service Meshes die Kommunikation in der Transport- und Applikationsschicht, bzw. Layer 4 und 7 nach dem OSI-Modell, ab.

Was kann man wann und wie verwenden?

Hierzu soll ein Blick auf konkrete Anwendungsszenarien geworfen werden, um auszuloten, welche Komponente zielgerichtet verwendet werden kann.

SzenarioAPI GatewayService Mesh
API als Produkt mit/ohne MonetarisierungX
L7-Service-Kommunikation mit Sicherheit und Überwachung über verschiedene API-Produkte hinwegX
L4/L7-Servicekommunikation mit Sicherheit und Überwachung innerhalb desselben API-ProduktsX
Entwicklern ein vollständiges Lifecycle-Management der API anbietenX
Sichere Kommunikation zwischen ServicesX
Transformation von KommunikationsprotokollenX

Bei Betrachtung der einzelnen Szenarien stellt sich auch die Frage, wie API Gateway und Service Mesh zusammenarbeiten könnten. Aus diesem Grund soll zum Abschluss genau dieses Zusammenspiel näher betrachtet werden.
API Gateway and Service Mesh
Das API Gateway gewährt hier Zugriff auf die einzelnen API Services. Dahinter befinden sich nun, aufgeteilt in zwei Schichten der Composite/Integration und der Core-Schicht, die Services für die Business-Logik. Die Kommunikation der einzelnen Services findet über die Sidecar Proxy an den jeweiligen Services statt.

Fazit

API Gateways und Service Meshes können ein Bestandteil von Softwarearchitekturen sein und werden. Es ist aber wichtig, den jeweiligen Use Case genau zu betrachten, um entsprechende Technologien einsetzen zu können.

Daniel Kocot ist der erste Kong Champion (Experte für das API Gateway Kong) Deutschlands und seit 2016 bei codecentric. Schon seit Anfang der 2000er Jahre widmet er sich dem Thema der „Digitalen Transformation“. Neben den aktuellen Schwerpunkten API Design und Management, Application Lifecycle Management Tooling und VoiceUI, ist er auch Experte für den Einsatz von Produktinformationssystemen (PIM) und Database-Publishing mit Hilfe von Rendering-Technologien.

Dennis ist IT-Consultant und Software Engineer bei der codecentric AG und legt seinen aktuellen Schwerpunkt auf die architektonische Gestaltung und Entwicklung von Cloud-Native-Anwendungen. Er begeistert sich vor allem für Service-Mesh-Architekturen und evaluiert diverse Implementierungen für den Einsatz beim Kunden.

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien.
Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.