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
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.
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.
| Szenario | API Gateway | Service Mesh |
|---|---|---|
| API als Produkt mit/ohne Monetarisierung | X | |
| L7-Service-Kommunikation mit Sicherheit und Überwachung über verschiedene API-Produkte hinweg | X | |
| L4/L7-Servicekommunikation mit Sicherheit und Überwachung innerhalb desselben API-Produkts | X | |
| Entwicklern ein vollständiges Lifecycle-Management der API anbieten | X | |
| Sichere Kommunikation zwischen Services | X | |
| Transformation von Kommunikationsprotokollen | X |
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.
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.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Daniel Kocot & Dennis Effing
20.11.2024 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*innen
Daniel Kocot
Senior Solution Architect / Head of API Consulting
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Dennis Effing
IT Consultant / Software Engineer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.