Das Konzept von Microservices ist beinahe deckungsgleich mit Cloud-nativen Anwendungen: kleine Komponenten, die miteinander vernetzt und als lose verknüpfte Services bereitgestellt werden. Um APIs erfolgreich in Microservices-Umgebungen einzusetzen, müssen Unternehmen Tools bereitstellen, die Entwicklern die automatisierte Erstellung, Implementierung und Veröffentlichung von APIs ermöglichen – idealerweise als Teil einer CI/CD Pipeline. Anzustreben ist dabei eine iterative Vorgehensweise mit starkem Fokus auf Sicherheit.
Programmierschnittstellen (APIs) gibt es schon seit Jahrzehnten, API-Gateways sind also nichts Neues. Aber im Zuge der Entwicklung weg von monolithischen hin zu Microservices-basierten Apps wechseln Unternehmen weitgehend von SOAP APIs mit XML-codierten Payloads zu REST APIs mit JSON-codierten Payloads. Geändert haben sich damit nicht nur die zugrunde liegende Technologie und die Datenformate, sondern auch die Art, wie APIs erstellt werden, sowie die Methoden der Informationsübermittlung und Interaktion.
Eine hochgradig verteilte Umgebung mit Hunderten von APIs, die von verschiedenen Entwicklern betreut werden, stellt naturgemäß eine Herausforderung dar. Möglicherweise nutzen sie mehrere API-Gateways – eines pro API, eines für jedes Team, das die APIs entwickelt usw. Da in der Produktion externe Parteien Zugang zu APIs haben, spielen Sicherheitsaspekte eine wichtige Rolle.
Bei Ende-zu-Ende-Konfiguration des TLS-Protokolls zum Beispiel müssen sie dafür sorgen, dass der Traffic Ende-zu-Ende abgesichert ist. Ein weiteres Thema sind die widerstreitenden Prioritäten von Anwendungs- und Sicherheitsteams: Bei DevOps liegt der Fokus auf Geschwindigkeit, während NetOps die Aufgabe hat, Änderungen sorgfältig auf die Einhaltung bestehender Richtlinien zu testen, um die Assets der Organisation zu schützen.
Schnellere Bereitstellung in kürzeren Abständen funktioniert nur mit einer effizienten CI/CD Pipeline. Möglicherweise befindet sich das API-Gateway in dieser Pipeline. Wie aber lässt sich ein API aktualisieren und dabei dafür sorgen, dass das API-Gateway Traffic verarbeitet oder die Authentifizierungs- und Zugangssteuerung für die Endgeräte übernimmt? Das Gateway muss wahrscheinlich über ein eigenes API konfiguriert werden. Idealerweise sollten diese API-Aufrufe über ein gesondertes zentrales System erfolgen, um das korrekte Update des Gateways zu gewährleisten.
Glücklicherweise steht mittlerweile die Technologie zur Bereitstellung der benötigten APIs zur Verfügung. Es ist also möglich, bestehende APIs zu aktualisieren und neue bereitzustellen, sodass Anwendungsentwickler schnell handeln und ihre eigenen CI/CD Pipelines aufbauen können. Gleichzeitig muss das API-Management in einer zentralisierten Umgebung erfolgen, damit die einschlägigen Sicherheitsrichtlinien eingehalten werden, ohne den Gesamtprozess auszubremsen.
Cloud-Anbieter erleichtern die Einrichtung eines API-Gateways. Unternehmen können ihre Workloads in die Cloud verlagern und dann ein API-Gateway für Authentifizierung, Durchsatzdeckelung und Routing aufsetzen. Dabei sollten sie allerdings die Frage der Komplexität bedenken. API Endpoints haben vielleicht die passende Infrastruktur – aber wie viele APIs werden in sechs oder zwölf Monaten zum Einsatz kommen? Unternehmen müssen in der Lage sein, hoch- und runterzuskalieren. Wie viele Teams stellen APIs bereit oder nehmen Änderungen daran vor? Sie brauchen eine rollenbasierte Zugangssteuerung mit geeigneten Berechtigungen. Sind die APIs für interne oder externe Nutzung vorgesehen? In der Regel gilt: Je externer das API, desto attraktiver wird die Bereitstellung in der Public Cloud.
Wenn es um den Einsatz von APIs bei Kubernetes zur Orchestrierung und Containerisierung geht, stellen sich andere Fragen. Dann ist entscheidend, welches API-Gateway verwendet wird und wo es sich befindet. Es könnte vor dem Cluster oder als Teil eines Service innerhalb des Clusters liegen. Wird ein Ingress Controller benötigt? Das API-Gateway kann als Ingress Controller fungieren und unnötige Hops und Single Points of Failure vermeiden.
Service Mesh ist ein aktuelles Thema, insbesondere wenn es um die Verbesserung des Managements und der Transparenz von Microservices-basierten Anwendungen geht.
Bei Kubernetes besteht der Nord-Süd-Traffic meist aus API-Aufrufen von Clients an Endgeräte. Die Antwort auf einen erstmaligen API-Aufruf erfordert aber möglicherweise den Aufruf eines weiteren API. Und damit beginnt die Service-to-Service-Kommunikation, also Ost-West-Traffic. An dieser Stelle kommen Service Meshes ins Spiel. Ein Service Mesh sorgt für mehr Transparenz beim Ost-West-Verkehr, mehr Sicherheitskontrollen (z. B. mit Mutual TLS/mTLS) und bietet die Möglichkeit zur Verwaltung auf einer Steuerebene. Bei Ost-West-Traffic haben API-Endgeräte möglicherweise einen Sidecar-Proxy, bei dem es sich auch um ein API-Gateway handeln könnte.
API-Gateways können zwar als Sidecar-Proxys genutzt werden, doch es ist besser, sie für den Nord-Süd-Verkehr einzusetzen, also getrennt von den Sidecar-Proxys, die den Ost-West-Traffic bewältigen. Bei einem Service Mesh sind die Sidecar-Proxys im Wesentlichen autonom und unsichtbar bei der Konfiguration der Kommunikation zwischen den einzelnen Services. Die Clients sehen nicht, ob Microservices oder Service Meshes zum Einsatz kommen. Normalerweise ist es also am besten, wenn das API-Gateway weiterhin derjenige Kanal bleibt, über den APIs veröffentlicht werden. Dagegen sorgt das Service Mesh für Sicherheitsmaßnahmen, die Steuerung der Kommunikation zwischen Services und die Übersicht über laufende Prozesse aus Service-to-Service-Perspektive.
Es ist an dieser Stelle bedeutsam, sich den Unterschied zwischen API-Management und API-Gateways vor Augen zu führen. Das API-Gateway ist die Datenebene zwischen Client und API-Endgerät. Es ist verantwortlich für Routing, Richtlinien und Sicherheit. In Hybrid-Cloud-Umgebungen gibt es unter Umständen zahlreiche API-Gateways, die dann miteinander synchronisiert werden müssen. Dazu brauchen Unternehmen eine API-Management-Steuerebene, über die sie Richtlinien definieren, Konfigurationen ausrollen, Berichte erstellen und die Übersicht über alle API-Gateways behalten. Im besten Fall funktioniert die API-Management-Plattform infrastrukturunabhängig. Dann lassen sich API-Gateways immer auf der jeweils optimalen Infrastruktur einsetzen.
In DevOps-Umgebungen ist es wichtig, die Konfiguration der API-Gateways in die CI/CD Pipeline zu integrieren, damit die Gateways die entwickelten APIs reibungslos bereitstellen können. Zur fehlerfreien Konfiguration und Bereitstellung von Gateways benötigt man in der Regel Bedingungslogik und spezifische Verarbeitung. Hierfür lässt sich ein zentralisiertes API-Managementsystem nutzen, anstatt die Logik in CI/CD-Skripten zu erfassen. API-Definitionen, Bereitstellungsorte oder Richtlinien sollten jedoch nicht in der API-Management-Plattform selbst, sondern in einem Source-Control-Repository gespeichert werden. Die CI/CD-Pipeline-Skripts ziehen dann die Informationen aus diesem Repository.
Seit etwa zehn Jahren haben JSON REST APIs die SOAP XML APIs überholt. Es gibt gute Gründe für eine Kombination von synchroner (z. B. JSON REST APIs) und asynchroner Kommunikation (z. B. Pub/Sub-Messaging). Das Protokoll gRPC ermöglicht beides über bidirektionales Streaming – etwa Message Events Streams und RPC-Aufrufe.
Bei der Verknüpfung synchroner und asynchroner Protokolle sind API-Gateways unverzichtbar. Sie bilden einen einheitlichen Single Entry Point, an den der API-Client über verschiedene Messagingmethoden Aufrufe sendet. Das erleichtert es dem API-Client, Übermittlungen in unterschiedlicher Form zu verarbeiten.
Heutige Architekturen verändern sich schnell. APIs kommen möglicherweise in verschiedenen Clouds und in Containern, verwaltet durch Plattformen wie Kubernetes, zum Einsatz. Es gibt diverse neue Konzepte zur Steuerung und zum Routing von Traffic über einen API-Gateway. Dazu zählen Sidecar-Gateways oder -Proxys, die Service-Mesh-Funktionen mitbringen. Diese bieten höhere Transparenz bei der Verwaltung und Sicherung von APIs innerhalb von Containerclustern.
Die Kommunikationsmethoden sind dabei vielfältig – etwa JSON-basiertes REST und RPC –, und diese Formate werden sich mit der Zeit verändern. Sie sind alle für Entwickler hilfreich. Daher müssen API-Gateways unterschiedliche Programmiersprachen unterstützen, etwa synchrone und asynchrone, interne und externe.
Beim Einsatz von APIs oder API-Gateways über verschiedene Clouds hinweg benötigen Unternehmen eine Lösung, um diese APIs nahtlos zu verwalten, zu verteilen und zu sichern, während sie sich weiterentwickeln. Dies erfordert eine API-Management-Plattform, die mit beliebigen Infrastrukturen funktioniert.
Roman Borovits ist als Sr. Systems Engineer für F5 Networks in der Region Deutschland, Österreich und Schweiz tätig und blickt im Bereich Netzwerk und Security auf fast 20 Jahre Berufserfahrung zurück. Sein universitärer Background liegt im Bereich Business Process Engineering und Management. Die Themenschwerpunkte bei F5 liegen im Bereich Cloud und Automatisierung. Dazu zählt die Integration von Layer 4-7 Services in hochautomatisierte Workflows, das Verständnis für moderne Toolchains sowie intensive Kenntnis über Private- und Public-Cloud-Architekturen. Die Integration von Security-Services für Webanwendungen und APIs, vor allem wenn diese über automatisierte Prozesse entstehen, sieht er als eine der großen Herausforderungen der gegenwärtigen IT, die sich mit immer kürzeren Releasezyklen konfrontiert sieht.