Inhaltsübersicht
Meinung des CTO-Büros von F5
Das Büro des CTO-Teams bei F5 untersucht seit über einem Jahr den Bereich der Technologien im Zusammenhang mit APIs. Dieses neueste Whitepaper ist eine Fortsetzung unserer Bemühungen, das sich ständig weiterentwickelnde API-Ökosystem zu verstehen.
Die Herausforderungen, die wir bei der Verwaltung des API-Wildwuchses beschrieben haben, werden zu Herausforderungen bezüglich des Wildwuchses von API-Gateways führen. Hierbei werden herkömmliche Ansätze zur Bewältigung dieser Herausforderungen nicht ausreichen. Während sich Graphtechnologien wie GraphQL in Bezug auf die Eindämmung der mit APIs verbundenen Komplexität als vielversprechend erweisen, stellen sie nur einen Teil der Lösung dar, da die Herausforderungen über Konnektivität, Sicherheit und Routing hinausgehen. Der korrekte Ansatz, der auf fast dreißig Jahren Erfahrung mit Skalierungssystemen und -anwendungen beruht, basiert auf einer verteilten – nicht föderierten – Architektur, die GraphQL zwar einsetzt, aber sich nicht nur darauf verlässt.
In diesem Beitrag wird eine verteilte architektonische Herangehensweise zur Bewältigung der Herausforderungen bezüglich des Wildwuchses von API-Gateways untersucht.
Kurzfassung
Die digitale Wirtschaft wird durch APIs angetrieben, was uns eine API-gesteuerte Ökonomie ermöglicht. Nach dem Whitepaper zum API-Wildwuchs wollten wir verstehen, wie wir die Auswirkungen des API-Wildwuchses beseitigen oder begrenzen können. GraphQL schien zwar vielversprechend, um die Auswirkungen des API-Wildwuchses zu reduzieren, jedoch liegt es in der Regel an den Entwicklern, einen großen Teil ihrer API-Codebasis neu zu schreiben. Ein aufkommender Vorteil zu GraphQL ist jedoch seine Fähigkeit, als effektiver Gateway-Akteur eingesetzt zu werden. Bei einem Gateway-Akteur handelt es sich um eine Funktion oder einen Prozess, die bzw. der in der Nähe des Clients erstellt wurde und eine API-Anforderung initiiert. Dieser Gateway-Akteur fungiert als erstes API-Gateway, das die API-Anforderung beendet. Dabei kann dieser Akteur auch kurzlebig sein, sodass er nach der Bearbeitung der Anfrage zerstört wird.
Neben Entwicklern und Betriebsteams, die die API-Verwaltung gegenüber API-Gateways priorisieren, haben wir außerdem ein Problem mit dem Wildwuchs von API-Gateways aufgrund des API-Wildwuchses entdeckt. Aus der Sicht eines Entwicklers besteht das Hauptanliegen darin, sicherzustellen, dass die API korrekt und zeitnah funktioniert. Auf der anderen Seite konzentriert sich das Betriebsteam mehr auf Aspekte wie Erkennung, Sicherheit, Benutzerfreundlichkeit und Zugriffskontrollen. Da API-Gateways heute eine kritische Komponente der API-Infrastruktur sind, wurde deutlich, dass die Ausbreitung von APIs die Bereitstellung von API-Gateways erhöht, was wiederum zu einem Wildwuchs der API-Gateways führt.
Die Zukunft der API-Architektur muss sich weiterentwickeln, um so den API-Wildwuchs zu akzeptieren und gleichzeitig die Bereitstellung und den Betrieb zu vereinfachen. Die vorgeschlagene Architektur stellt die nächste Entwicklung in Sachen Design-Patterns der API-Gateways dar. Während GraphQL nicht von zentraler Bedeutung oder gar notwendig für die Architektur ist, besitzt es die Fähigkeit, das Muster der Gateway-Akteure zu erweitern.
Zusammenfassung
Das Ökosystem der API-Verwaltung muss sich von der Verwaltung von monolithischen API-Gateways hin zu einem moderneren Systemdesign bewegen, was zu einem agileren und effektiveren API-Verwaltungssystem führt.
Wildwuchs der API-Gateways – Verwaltung von verteilten Monolithen
Der API-Wildwuchs stellt bereits eine Herausforderung innerhalb der API-Ökonomie dar. Er führt jedoch auch zum Wildwuchs der API-Gateways, einer Situation, in der die Verwaltung von APIs aufgrund verschiedener API-Gateway-Anbietertechnologien und eigensinniger Teams zur Verwaltung der API-Gateways unkontrollierbar geworden ist. Wir befinden uns an einem Wendepunkt bezüglich der API-Architekturen, da das bisherige API-Gateway (API-GWs) – eine dedizierte Softwareschicht, die als Einstiegspunkt für API-Aufrufe dient – nicht mehr ausreicht, um den Umfang und die Komplexität des aufkommenden API-Ökosystems zu verwalten.
Abbildung 1 veranschaulicht, wie wir von der Verwaltung des API-Wildwuchses zur Verwaltung des Wildwuchses der API-Gateways übergegangen sind.
Das Design-Pattern bezieht sich vor allem auf eine zentrale Steuerungsebene, wobei die API-Gateways die verteilte Datenebene bilden, wie in Abbildung 2 dargestellt.
API-Gateways sind ein wesentlicher Bestandteil moderner Softwarearchitekturen und bieten einen zentralen Kontroll- und Sicherheitspunkt für APIs. Da die Anzahl der Funktionen von API-Gateways jedoch gestiegen ist, erweist sich auch deren Verwaltung als immer komplexer und schwieriger. In vielen Fällen haben sich diese Gateways zu monolithischen Systemen entwickelt, wobei eine Vielzahl von Funktionen in einem einzigen Paket gebündelt sind.
Während die Verwaltung mehrerer Gateways wie ein verteiltes Design wirken mag, wird diese Art der Verwaltung in der Realität einer richtigen Verteilung nicht gerecht. Dies liegt daran, dass die Gateways immer noch eng miteinander verbunden sind und sich Ressourcen und Konfigurationen teilen, die schwer zu trennen sind. Infolgedessen verwalten viele Unternehmen verteilte Monolithen und alle damit verbundenen Herausforderungen.
Architekturen bisheriger API-Gateways
Abbildung 3 zeigt die Architektur bestehender API-Gateways. Vom Client ausgehende API-Anfragen werden zunächst über ein gemeinsam genutztes oder dediziertes Netzwerk übertragen und durchqueren eine Firewall, bevor sie das API-Gateway erreichen. Das API-Gateway, das als Reverse-Proxy fungiert, leitet den Datenverkehr dann an den API-Workload weiter.
Das bisherige API-GW wird zu einem Drosselpunkt der API-Verwaltung, wenn API-Gateways im gesamten Unternehmen bereitgestellt oder die API-Workloads betriebsbedingt über Regionen, Zonen, mehrere Clouds oder an den Rand verschoben werden, während der API-Wildwuchs bereits eine Herausforderung darstellt. Mehrere API-GWs werden von verschiedenen Teams ohne einen einzigen Punkt der Unternehmensverwaltung und -kontrolle erstellt. Wenn eine Person oder eine Gruppe von API-Diensten in eine andere Infrastruktur (egal, ob Cloud oder anderweitig) wechselt, muss das Betriebsteam über eine Methode verfügen, um alle Aspekte der API-Verwaltung zu migrieren, darunter Richtlinien zur Registrierung, Erkennung, Authentifizierung, Netzwerk sowie Sicherheit und Governance, Risiko und Compliance (GRC).
Die in Abbildung 3 dargestellte Architektur ist daher nicht skalierbar oder langfristig praktikabel, da sie im Laufe der Zeit zur Verwaltung von verteilten Monolithen führt (Abbildung 2).
Es gibt zwei Probleme, die zur Bildung des Drosselpunkts von API-Gateways führt: (1) Wildwuchs der API-Gateway-Anbieter und (2) flexible Skalierung, wenn in einem Unternehmen mehrere Anwendungen an mehreren Standorten ausgeführt werden.
- Wildwuchs der API-Gateway-Anbieter: Der Umgang mit dem Wildwuchs der API-Gateway-Anbieter stellt eine menschliche Herausforderung dar, da es schwierig sein kann, alle Teams davon zu überzeugen, einen einzigen API-Gateway-Anbieter zu nutzen. Auch die Migration zu einem neuen Anbieter kann sich als mühsam herausstellen. Infolgedessen verschwenden Unternehmen schlussendlich mehr Zeit und Ressourcen mit der Verwaltung mehrerer Gateway-Anbieter. Wenngleich dieses Problem angegangen werden kann, ist es in der Realität möglicherweise nicht vollständig realisierbar.
- Anwendungsskalierung: Die Skalierung von Anwendungen wird zum Problem, wenn die Anwendung mehrere Benutzer an einem einzigen Standort unterstützen muss oder an mehreren Standorten bereitgestellt werden muss. Dies erfordert eine horizontale oder vertikale Skalierung der Anwendung. Parallel zur Skalierung der Anwendung müssen auch die API-Gateways skaliert werden. In einigen Fällen müssen sie an mehreren Standorten bereitgestellt werden, um die Skalierung auf der Grundlage aktueller Architekturmuster zu unterstützen. Dies kann die betriebliche Komplexität bei der Verwaltung der API-Gateways erhöhen.
Lösung: Ein verteiltes Muster der Gateway-Akteure
Abbildung 4 zeigt ein verteiltes Muster der Gateway-Akteure, um so den Wildwuchs der API-Gateways einzudämmen. Während das verteilte Muster selbst nicht neu ist, bekräftigt dieser Beitrag die Verteilung im Kontext von API-Gateways. Die Clients initiieren die API-Anforderung. Die verteilten Gateway-Akteure sind kurzlebig und werden bei Bedarf so nah wie möglich am Client instanziiert. Es liegt in der Verantwortung der API-Transportschicht, die API-Anforderung vom Gateway-Akteur an das vereinfachte API-Gateway zu senden, das die Anforderung dann an den entsprechenden API-Workload weiterleitet. Während der unterstützende Einsatz von GraphQL für die verteilten Akteure eher ein weiteres Detail als eine Voraussetzung für das Funktionieren dieses Musters darstellt, ermöglicht dieser jedoch hilfreiche Funktionen wie die Dienstorchestrierung. Anstatt also eine neue Dienst-Orchestrierungsschicht zu erstellen, könnte GraphQL diese Funktion bereitstellen.
Zur Verdeutlichung: Das Muster des Datenverkehrs verläuft von rechts nach links. Das heißt, die Clients befinden sich auf der rechten Seite und die API-Anforderungen werden vom Client initiiert, wie in Abbildung 5 dargestellt.
Es entwickelt sich ein Bereitstellungsmuster, das Gateway-Akteure verwendet, um die übermäßige Abhängigkeit von API-Gateways für die Verwaltung von APIs innerhalb und im gesamten Unternehmen zu ersetzen oder zu reduzieren. Auch wenn GraphQL für die Architektur nicht notwendig ist, stellt die Einführung eine aktuelle Maßnahme dar, da der Gateway-Akteur das passende Mittel zur Unterstützung von GraphQL ist.
Um ein tieferes Verständnis des Gateway-Akteurs als potenzielle Lösung zu erlangen, ist es notwendig, den aktuellen Stand der API-Infrastrukturen, insbesondere der API-Gateways, genau zu untersuchen. Dies liegt daran, dass wir den Wildwuchs von Gateways als einen wesentlichen Faktor in Bezug auf die Herausforderungen des Betriebs und der Skalierung von API-Infrastrukturen identifiziert haben.
Um ein besseres Verständnis der API-Gateways zu erlangen, ist es wichtig, zunächst die verschiedenen Komponenten der modernen API-Verwaltungsinfrastruktur zu untersuchen.
Abbildung 6 bietet eine umfassende visuelle Darstellung der verschiedenen Funktionen und Komponenten, die in die API-Verwaltung integriert sind. Neben API-Gateways, die für das Routing und die Verwaltung des Datenverkehrs zu Backend-Diensten erforderlich sind, gibt es mehrere andere wichtige Infrastruktur-Komponenten. Dazu können unter anderem Lösungen für die Authentifizierung, die Ratenbegrenzung, das Caching und das Service-Mesh gehören. Durch die Integration dieser Funktionen können Unternehmen die Kontrolle über ihre APIs erlangen, die Sicherheit verbessern und die Leistung optimieren.
Sehen wir uns die allgemein anerkannten und bekannten Funktionen von API-Gateways an:
- Routing: Leitet Anforderungen basierend auf dem Pfad oder Inhalt der Anforderung an den entsprechenden Backend-Dienst weiter.
- Authentifizierung und Autorisierung: Authentifiziert und autorisiert Anfragen als einzelner Eintrittspunkt, um sicherzustellen, dass nur autorisierte Clients auf die Backend-Dienste zugreifen können.
- Ratenbegrenzung: Begrenzt die Geschwindigkeit, mit der Clients Anforderungen an die zugrunde liegenden APIs stellen können, um eine übermäßige Beanspruchung zu verhindern und die Backend-Dienste vor Überlastung zu schützen.
- Caching: Cacht Antworten von den zugrunde liegenden APIs, wodurch die Anzahl der Anforderungen an die Backend-Dienste reduziert und die Leistung verbessert wird.
- Protokollübersetzung: Übersetzt zwischen verschiedenen Protokollen, z. B. HTTP und WebSockets, sodass Clients über verschiedene Protokolle auf die zugrunde liegenden APIs zugreifen können.
- Lastenausgleich: Verteilt Anfragen an mehrere Backend-Dienste und verbessert so die Skalierbarkeit und Zuverlässigkeit.
- Sicherheit: Erledigt Sicherheitsaufgaben wie die Ver- und Entschlüsselung, um eine sichere Datenübertragung zu gewährleisten.
- Analyse und Überwachung: Verfolgt und meldet Nutzungsmetriken sowie Fehlerinformationen, die einen Einblick in die Verwendung des Systems bieten und dazu beitragen, Leistungsengpässe sowie Fehler zu identifizieren.
- Versionierung: Kümmert sich um die Versionierung der zugrunde liegenden APIs, sodass Clients je nach Bedarf auf verschiedene Versionen der API zugreifen können.
- Serviceerkennung: Erkennt verfügbare Backend-Dienste und leitet Anfragen dynamisch an diese weiter, was eine dynamischere und flexiblere Serviceerkennung ermöglicht.
Nach der Analyse der Funktionen der API-Verwaltungsinfrastruktur haben wir die Notwendigkeit erkannt, die Rolle von API-Gateways besser zu verstehen und Alternativen zum aktuellen monolithischen Design der API-Gateways zu erkunden.
Die wachsende Anzahl an APIs, die bereits zu einem Wildwuchs der APIs und API-Gateways zur Folge hat, führt zu einer zunehmenden Anzahl von Clients, die mobil oder hochgradig verteilt sind. Außerdem ist die Recheninfrastruktur von überall aus verfügbar, auch am Netzwerkrand. Wir benötigen daher einen Ansatz, der die Agilität, Flexibilität, Skalierbarkeit, Leistung und Sicherheit des API-Ökosystems verbessern kann.
Dieser neue Ansatz erfordert ein optimiertes Design, das die Vorteile einer wirklich verteilten Architektur voll ausschöpfen kann.
Wir analysieren ferner die Funktionalität und den Umfang eines API-Gateways, um seine Nuancen und Einschränkungen herauszuarbeiten.
Ein API-Gateway stellt eine wichtige Komponente der heutigen API-Verwaltungsinfrastruktur dar. Im Kern ist das API-Gateway ein Reverse-Proxy. Es fungiert als Vermittler zwischen Clients und Backend-Diensten, während es eine Vielzahl von Aufgaben für die eingehende Anfrage ausführt. Beispielsweise kann das Gateway eine Authentifizierung, eine Ratenbegrenzung, eine Weiterleitung der Anforderung, eine Anwendung der Sicherheitsrichtlinien, die Überwachung sowie die Versionierung übernehmen, bevor die Anforderung an einen geeigneten Backend-Dienst weitergeleitet wird. Sobald der Backend-Dienst die Anfrage verarbeitet und eine Antwort ausgegeben hat, kann das API-Gateway Aufgaben wie Caching, Protokollübersetzung und Antwortverarbeitung ausführen, bevor die Antwort an den Client weitergeleitet wird.
Mit der wachsenden Anzahl von APIs haben sich API-Gateways weiterentwickelt und übernehmen nun eine Vielzahl neuer Funktionen, die über das grundlegende Routing hinausgehen und so zur Bildung monolithischer Systeme führen. Diese Gateways verwalten jetzt Aufgaben wie Authentifizierung und Ratenbegrenzung, um die Leistung zu verbessern und die Belastung der Backend-Dienste zu reduzieren. Doch auch mit dieser erweiterten Funktionalität fungieren API-Gateways immer noch als einzelner Eintrittspunkt für den Backend-Service, was in stark verteilten Umgebungen zu Herausforderungen führen kann.
Insbesondere der Aufstieg von Cloud-, Hybrid-Multi-Cloud- und Edge-Infrastrukturen hat es erschwert, die Agilität, Sicherheit und Verwaltbarkeit bei der Anwendung eines API-Gateway-Ansatzes aufrechtzuerhalten. Da Clients, Geräte und Anwendungs-Workloads möglicherweise über eine Vielzahl von Standorten verteilt sind, ist ein API-Gateway möglicherweise nicht gut geeignet, um das erforderliche Maß an Edge-freundlicher Architektur bereitzustellen.
Da sie eine Vielzahl von Aufgaben erledigen und in mehrere Systeme integriert werden müssen, gestaltet sich die Implementierung und Verwaltung von API-Gateways in der Regel als schwierig. Auch wenn die Verwaltung von API-Gateways komplex sein kann, stellt sie eine wichtige Aufgabe dar, um die Verfügbarkeit, Sicherheit und Skalierbarkeit einer API zu gewährleisten. Unternehmen neigen dazu, spezialisierte Tools wie API-Verwaltungsplattformen einzusetzen, um ihre API-Gateways effektiver zu verwalten und zu überwachen.
Die folgende Liste ist zwar nicht vollständig, umfasst jedoch einige der Elemente, die zur Komplexität des API-Gateways beitragen:
- Konfigurationsverwaltung: API-Gateways verfügen über häufig eine Vielzahl von Konfigurationsoptionen und -einstellungen, die verwaltet und gepflegt werden müssen, wie z. B. Routingregeln, Ratenbegrenzung und Sicherheitseinstellungen. Die Verwaltung dieser Einstellungen kann sich als komplex und zeitaufwendig erweisen, insbesondere wenn die Anzahl der zugrunde liegenden APIs und Clients zunimmt.
- Integration in andere Systeme: Die Gateways müssen in eine Vielzahl anderer Systeme wie Authentifizierungs- und Autorisierungssysteme, Load Balancer und Datenbanken integriert werden. Dies kann sich als komplex erweisen, insbesondere wenn die zugrunde liegenden Systeme nicht optimal integriert sind oder wenn das API-Gateway mehrere Protokolle oder Datenformate verarbeiten muss. Dies wird umso problematischer, wenn ein Unternehmen über mehrere API-Gateway-Bereitstellungen von mehreren Anbietern verfügt.
- Skalierbarkeit und Verfügbarkeit: API-Gateways müssen in der Lage sein, eine große Anzahl von Anfragen zu verarbeiten und eine hohe Verfügbarkeit zu gewährleisten, wobei deren Verwaltung insbesondere im Umgang mit einer großen Anzahl von Backend-Diensten und Clients komplex sein kann.
- Sicherheit: Als kritische API-Sicherheitskomponente müssen im Rahmen der Sicherheit eingesetzte API-Gateways konfiguriert und verwaltet werden, um sicherzustellen, dass sensible Daten geschützt sind und der Zugriff kontrolliert wird. Dies kann sich als komplex erweisen und erfordert eine kontinuierliche Überwachung und Verwaltung.
- Versionierung: Während die Anzahl der zugrunde liegenden APIs und Clients zunimmt, wird es auch immer schwieriger, verschiedene Versionen der API zu verwalten und sicherzustellen, dass Clients auf die korrekte Version zugreifen.
- Überwachung und Fehlerbehebung: API-Gateways können große Datenmengen sammeln und generieren. In einem großen Unternehmen können Gateways über viele Standorte verteilt sein, was die Korrelation von Ereignissen, welche sich auf den allgemeinen Zustand der Anwendung auswirken, sowie die Fehlerbehebung erschwert.
Wildwuchs der API-Gateways
Der Wildwuchs der API-Gateways bezieht sich auf die Ausbreitung mehrerer, unabhängiger API-Gateways innerhalb einer Organisation. Verschiedene Teams oder Geschäftseinheiten erstellen häufig ihre eigenen APIs, was zur Erstellung mehrerer, unabhängiger API-Gateways führen kann, um diese verschiedenen APIs zu verwalten. Verschiedene Teams können auch API-Gateways von verschiedenen Anbietern oder Lösungen verwenden, um verschiedene Arten von APIs zu verwalten.
Dies führt zur Bereitstellung mehrerer API-Gateways, die alle über unterschiedliche Funktionen verfügen.
Der Wildwuchs der API-Gateways bringt mehrere zusätzliche Herausforderungen mit sich:
- Skalierung der Verwaltung von API-Gateways: Mehrere unabhängige API-Gateways können die Verwaltung und Wartung der Gateways erschweren, insbesondere da die Anzahl der zugrunde liegenden APIs und Clients zunimmt.
- Ineffizienzen bezüglich des Ost-West-Datenverkehrs: Mehrere Gateways können dazu führen, dass Anforderungen durch diese höhere Anzahl an Gateways geleitet werden müssen, was die Latenzzeit erhöht und die Leistung verringert.
- Einheitlichkeit der Sicherheitsrichtlinien: Die Verwaltung mehrerer Gateways kann sich als schwierig erweisen und zu inkonsistenten Sicherheitsrichtlinien führen, was den Schutz sensibler Daten und die Zugriffskontrolle erschwert.
- Standardisierte Governance: Bei der Verwendung mehrerer Gateways kann es schwierig sein, sicherzustellen, dass alle APIs ordnungsgemäß verwaltet werden und den Standards und Best Practices entsprechen.
- Höhere Kosten: Mehrere Gateways können zu höheren Kosten für Infrastruktur, Entwicklungsressourcen und Wartung führen.
- Höhere Herausforderungen bei der Integration: Die Nutzung mehrerer Gateways erschwert die Integration in andere Systeme und Technologien, z. B. andere Datenbanken, Data Warehouses und Datenanalysetools.
Unternehmen sollten ihre API-Verwaltung und -Governance nach Möglichkeit zentralisieren und eine einzige Art von API-Gateway verwenden. Während dies die oben genannten Herausforderungen bezüglich des Wildwuchses der API-Gateways reduziert, gestaltet sich die Nutzung einer einheitlichen Strategie für API-Gateways alles andere als einfach.
Herausforderungen bei der Standardisierung von API-Gateways in einem Unternehmen
Wenn Unternehmen organisch oder durch Übernahmen wachsen, kommt es zwischen den internen Teams, die auf bestimmte Geschäftseinheiten (BUs) ausgerichtet sind, bei der Auswahl von API-Gateway-Technologien oder Anbietern zu Abweichungen. Einige Gründe dafür sind:
- Technologie: Verschiedene Teams oder Geschäftseinheiten verfügen über unterschiedliche Technologie-Stacks oder bevorzugen unterschiedliche API-Gateway-Lösungen, was die standardisierte Nutzung eines einzelnen Gateway-Typs erschwert.
- Legacy-Systeme: Einige Teams nutzen bestehende Systeme, die mit einer anderen Art von API-Gateway erstellt wurden. Es wäre schwierig, diese Systeme durch ein neues Gateway zu ersetzen, insbesondere wenn sie noch im Einsatz sind.
- Anpassung: Einige Teams passen ihre vorhandenen API-Gateways an bestimmte Anforderungen an und haben Schwierigkeiten, diese Anpassungen auf einem neuen Gateway zu replizieren.
- Kosten für den Austausch: Das Ersetzen bestehender API-Gateways durch ein neues, standardisiertes Gateway kann sich sowohl in Bezug auf die Entwicklung als auch auf die Wartung als kostspielig erweisen.
- Schulung von Entwicklern: Teams verfügen über unterschiedliches Fachwissen und müssen sich möglicherweise mit einer neuen Gateway-Technologie eines anderen Anbieters vertraut machen oder eine Schulung dazu absolvieren. Dieser Prozess kann sowohl zeitaufwändig als auch teuer sein.
- Begrenzte Ressourcen: Unternehmen verfügen über begrenzte Ressourcen in Bezug auf Entwickler, Budget und Zeit zur Umsetzung von Änderungen, was die Implementierung eines neuen Gateways erschwert.
- Anwendungsabhängigkeiten: Verschiedene Teams oder Geschäftseinheiten weisen unterschiedliche Abhängigkeiten von ihren vorhandenen Gateways auf, wie die Integration in bestimmte Systeme oder andere benutzerdefinierte Integrationen, was den Wechsel zu einem neuen Gateway erschwert.
- Lösungen von Drittanbietern: Teams, die Lösungen von Drittanbietern verwenden, welche in das Gateway integriert sind, haben Schwierigkeiten, zu einer neuen Lösung zu wechseln, die diese Lösungen von Drittanbietern nicht unterstützt.
Wenn eine bestehende Anwendung demnach von einem eingespielten und eigensinnigen Team verwaltet wird, möchte das Team daher nicht zu einem anderen Bereitstellungsmuster wechseln, um keine Unterbrechung des Dienstes zu verursachen.
Wir kommen daher zu dem Schluss, dass ein neuer Ansatz erforderlich ist, der mehrere Einschränkungen der bestehenden API-Infrastruktur berücksichtigt und gleichzeitig den Wildwuchs der API-Gateways als eine der wichtigeren Überlegungen hervorhebt.
Designüberlegungen
Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit, sondern fasst einige der übergeordneten Designüberlegungen zusammen, die unserer Ansicht nach bei der Entwicklung der Lösung berücksichtigt werden sollten:
- Koexistenz mit aktuellen Bereitstellungen: Da Unternehmen bestrebt sind, mit der sich ständig verändernden Technologielandschaft Schritt zu halten, ist es üblich, dass Unternehmen über eine Vielzahl von API-Gateway-Bereitstellungen verfügen. Eine Anpassung der bestehenden API-Infrastruktur ist nicht möglich, da dies den kritischen Geschäftsbetrieb stören könnte. Daher muss jede neue Bereitstellung so gestaltet werden, dass sie neben der derzeit bereitgestellten Architektur existieren kann.
- Standardisierung von API-Gateway-Funktionen: Das primäre Ziel der API-Strategie eines Unternehmens sollte darin bestehen, seine API-Gateway-Funktionalität zu standardisieren, was aufgrund der vielfältigen APIs und der unterschiedlichen Anforderungen der verschiedenen Geschäftseinheiten eine herausfordernde Aufgabe sein kann. Dennoch ist diese Standardisierung entscheidend für die Schaffung einer stabilen und sicheren Infrastruktur, die die digitale Transformation des Unternehmens unterstützen kann.
- Einsatz von Edge-Bereitstellungen: Die Edge-Infrastruktur hat nicht nur das Potenzial, die Anzahl der APIs exponentiell zu erhöhen, sondern bietet Unternehmen auch die Möglichkeit, ihre Gateway-Akteure näher an den Netzwerkrand heranzuführen. Dies ist möglich, da die gleiche Infrastruktur, die zum Erstellen von APIs verwendet wird, auch zum Erstellen von verteilten Gateway-Akteuren eingesetzt werden kann. Daher muss die Lösung die Nähe zur Edge-Infrastruktur zu den Clients, die die API-Anforderung initiieren, vollständig nutzen.
- Transportunabhängig: Eine wichtige Überlegung für die Implementierung der Architektur verteilter Gateway-Akteure ist, dass sie nicht von einem bestimmten Transportmechanismus abhängig sein sollte. Egal, ob ein Unternehmen traditionelle IP-Netzwerke, Overlay-Netzwerke, VPNs oder Messaging-Infrastrukturen mit geringer Latenz nutzen möchte, muss die Lösung unabhängig vom Transportmechanismus sein. Dies bietet eine größere Flexibilität und ermöglicht es Unternehmen, den Transportmechanismus zu wählen, der ihren spezifischen Bedürfnissen und Anforderungen am besten entspricht.
- GraphQL-Unterstützung: GraphQL wird aufgrund seiner vielen Vorteile gegenüber herkömmlichen REST-APIs zu einer immer beliebteren Wahl für die API-Entwicklung. Ein wesentlicher Vorteil ist die Möglichkeit, einen fein abgestuften Zugriff auf Daten zu ermöglichen, sodass Kunden in einer einzigen Anfrage genau angeben können, welche Daten sie benötigen. Darüber hinaus kann GraphQL den Prozess der Aggregation von Daten aus mehreren Diensten vereinfachen und stellt damit die geeignete Architektur für die Zusammenstellung und Orchestrierung von Diensten dar. Dies kann die Netzwerkbelastung reduzieren und die Leistung verbessern, insbesondere in einem verteilten System, in dem mehrere API-Dienste zur Verarbeitung einer einzigen Anforderung eingesetzt werden. Schließlich kann GraphQL mit seinem stark typisierten Schema und seiner Abfragesprache die API-Erkennbarkeit verbessern und eine einfachere Cliententwicklung ermöglichen.
- Sicherheit als Grundvoraussetzung: Als wesentliches Designziel sollte ein API-Gateway die API-Sicherheitslage des Unternehmens verbessern. Die Lösung könnte einige der Sicherheitsfunktionen zusammenfassen, z. B. die Möglichkeit, API-Anforderungen zu authentifizieren und zu autorisieren, Zugriffskontrollen zu implementieren und Schutz vor gängigen Sicherheitsbedrohungen wie Cross-Site-Scripting (XSS) und SQL-Einschleusungen zu bieten. Unter keinen Umständen darf die neue Lösung das bestehende Bedrohungsmodell beeinträchtigen oder so stark verändern, dass sich die Angriffsfläche verändert. Durch die Priorisierung der Sicherheit als Designziel muss die Architektur eine sicherere Umgebung für die API-Kommunikation bieten und das Risiko von Datenschutzverletzungen und anderen Sicherheitsvorfällen reduzieren.
Auf der Grundlage dieser Designüberlegungen können spezifische Anforderungen abgeleitet werden, die wir in unsere Lösung verteilter Gateway-Akteure (DGA, Distributed Gateway Actors) integriert haben.
Verteilte Gateway-Akteure
Nachdem wir nun die API-Gateways vollständig erforscht haben, sehen wir uns die Lösung verteilter Gateway-Akteure an.
Design verteilter Gateway-Akteure
Das Design-Pattern der verteilten Gateway-Akteure (DGA) ist von Edge-Computing und Computing inspiriert, welche in der Nähe eines Clients verfügbar sind. Der Kern der Idee liegt darin, dass jeder Gateway-Akteur hochgradig und so nah wie möglich am Client verteilt wird und der Gateway-Akteur nur für die Dauer der Transaktion existiert, bevor er am Ende gelöscht wird.
Annahmen
Im Folgenden finden Sie einige Annahmen, die dieser Lösung zugrunde liegen.
Edge-Computing hat sich durchgesetzt. Wir bemerken inzwischen eine Art von Computing, das geografisch näher am Client verfügbar ist. Die Gateway-Akteure können auf diesen Edge-Computing-Knoten instanziiert werden. So soll eine Implementierung entstehen, bei der ein DGA sehr leicht und kurzlebig ist, sodass er auf jedem Edge-Computing instanziiert werden kann.
Der API-Transport ist ein entscheidender Bestandteil der Infrastruktur, da er den Aufbau eines Netzwerks zwischen den Gateway-Akteuren und dem API-Gateway umfasst. Die Art der erforderlichen Infrastruktur hängt vom Anbieter oder Unternehmen ab und kann variieren. Beispielsweise kann eine große öffentliche Cloud ihren eigenen Backbone für den API-Transport verwenden. Eine weitere Implementierung könnte einen Messaging-Bus mit niedriger Latenz umfassen, der über einem bestehenden Netzwerk mit hoher Bandbreite und niedriger Latenz in einem Unternehmensrechenzentrum angeordnet ist.
Funktionen von API-Gateways
Um es noch einmal zu betonen: Das API-Gateway ist im Wesentlichen ein Reverse-Proxy, dessen Hauptfunktion darin besteht, den HTTP-Verkehr an die entsprechenden API-Workloads weiterzuleiten. Dieser Ansatz ist sinnvoll, wenn alle APIs wie in einem lokalen Netzwerk vor Ort oder in einer Virtual Private Cloud (VPC) innerhalb einer Verfügbarkeitszone angeordnet sind. Aber wenn die Anzahl der APIs skaliert, diese sich über eine hybride Infrastruktur bewegen oder einfach mobil werden, erscheint dieser Ansatz des API-Gateway-Designs ineffizient, komplex in der Bedienung und kostspielig.
Auch wenn es unterschiedliche Ansichten darüber gibt, wie alle in Abbildung 6 beschriebenen Funktionen zu klassifizieren sind, können wir uns darauf einigen, dass die API-Verwaltungsinfrastruktur zu einer komplexen Bereitstellung vieler Komponenten geworden ist, die sorgfältig koordiniert werden müssen.
Abbildung 7 ordnet die verschiedenen Merkmale und Funktionen der API-Verwaltung aus Abbildung 6 der Architektur der verteilten Gateway-Akteure zu. Diese Zuordnung veranschaulicht visuell, wie jedes Merkmal und jede Funktion mit dem DGA-Ansatz abgestimmt sind, und hebt die nahtlose Integration der API-Verwaltungskomponenten in die Architektur hervor.
Zentralisierte Funktionen
Die meisten der oben aufgeführten Funktionen verfügen über eine Verwaltungskomponente, die logisch zentralisiert werden kann. Unser Ziel besteht nicht in der Neugestaltung der Verwaltungsebene, sondern, wenn möglich, in der Entfernung bestimmter Funktionen.
Kernfunktionen von API-Gateways
Hierbei handelt es sich um Datenebenenfunktionen, welche daher im Idealfall in der API implementiert und mit Anwendungs-Workloads verknüpft werden sollten. API-Gateways sind eine entscheidende Komponente der modernen Microservices-Architektur, die als Einstiegspunkt für den gesamten externen Datenverkehr dient. Wir haben die Kernfunktionen kategorisiert und Routing, Lastenausgleich, dynamisches Routing, Integritätsprüfung, Neuversuche und Fallbacks aufgenommen.
Ein API-Gateway leitet eingehende Anfragen an den entsprechenden Microservice weiter, verteilt den Datenverkehr auf mehrere Instanzen, unterstützt das dynamische Routing, überwacht den Zustand von Microservices und deren Instanzen, wiederholt fehlgeschlagene Anfragen und liefert Fallback-Antworten, wenn ein Microservice nicht verfügbar oder ausgefallen ist. Andere Funktionen wie Authentifizierung, Autorisierung, Ratenbegrenzung, Caching und Protokollierung können je nach den spezifischen Anforderungen des Systems auf den Netzwerkrand oder zentralisierte Funktionen verteilt werden.
Dieser modulare Ansatz ermöglicht eine flexiblere, optimierte Architektur und bildet den Kern unserer Empfehlung zur Vereinfachung, Modernisierung und Skalierung der API-Infrastruktur für Unternehmen.
Zusammengefasst
API-Gateway und API-Verwaltung werden von Anbietern oft fälschlicherweise als Teil der API-Gateway-Funktion zusammengefasst, dabei handelt es sich eigentlich um zwei unterschiedliche Funktionen, die getrennt behandelt werden sollten. Ein API-Gateway ist für die Weiterleitung von Anfragen von Clients an Backend-Dienste verantwortlich, während die API-Verwaltung eine breitere Palette von Funktionen wie Zugriffskontrolle, Ratenbegrenzung, Analysen und die Verwaltung des Entwicklerportals umfasst.
Während einige Anbieter sowohl API-Gateway- als auch API-Verwaltungsfunktionen als Teil eines einzigen Produkts anbieten, ist es wichtig, die Unterschiede zwischen diesen Funktionen zu verstehen und sie separat auf der Grundlage ihrer spezifischen Anforderungen zu bewerten. Die Kombination dieser Funktionen kann zu Verwirrung führen und möglicherweise die Flexibilität und Skalierbarkeit der API-Infrastruktur eines Unternehmens einschränken. Dies ist auch entscheidend, um unsere Position zur Verteilung der API-Gateway-Funktionalität zu verstehen.
Gateway-Akteur – Inline-Funktionen
Bei den hier aufgeführten Funktionen handelt es sich um Kernfunktionen, die sich inline zum Datenpfad befinden müssen. In einem verteilten Gateway-Pattern werden auch einige der Inline-Funktionen des API-Gateways verteilt. Diese Funktionen umfassen Zugriffskontrolle, Ratenbegrenzung, Anfragevalidierung, API-Analyse, Nutzungsmetriken, Fehlerratenüberwachung, Alarmierung und Ereignismeldung, Authentifizierungsintegration, Integration von Drittanbietern, Überwachung und Protokollierung, Edge-Caching sowie Komprimierung.
Das Verschieben dieser Funktionen in das verteilte Gateway-Pattern bietet die folgenden Vorteile:
- Reduzierte Belastung des API-Gateways: Trägt zur Reduzierung der Belastung des zentralisierten API-Gateways sowie zur Verbesserung der Leistung und Skalierbarkeit des Systems bei.
- Schnellere Reaktionszeiten: Ermöglicht schnellere Reaktionszeiten und reduziert die Latenzzeit, indem diese Funktionen näher an den Clients bereitgestellt werden. Durch die Nutzung des Cachings von Daten und Funktion können die Edge-gehosteten API-Gateways schnell auf eingehende Anfragen reagieren.
Beispielsweise können Zugriffskontrolle, Ratenbegrenzung und Anfragevalidierung von einem Edge-Gateway-Akteur durchgeführt werden, der näher an den Clients bereitgestellt wird. Dies kann dazu beitragen, die Anzahl der Anfragen zu reduzieren, die vom zentralisierten API-Gateway bearbeitet werden müssen, und so die Leistung und Skalierbarkeit zu verbessern. In ähnlicher Weise können API-Analysen, Nutzungsmetriken, Fehlerratenüberwachung, Alarmierung und Ereignismeldungen sowie Überwachungen und Protokollierungen über Edge-Gateways abgewickelt werden, die Daten aus mehreren Microservices sammeln und aggregieren.
Gateway-Akteure – GraphQL-Kandidaten
Eine wichtige Funktion, die API-Gateways heutzutage unterstützen, ist die Servicezusammensetzung und -orchestrierung. Obwohl sich dies als ziemlich komplex erweisen kann, könnte es zu einem Problem werden, wenn diese Funktion nicht vom vereinfachten API-Gateway unterstützt wird. Wir sind der Ansicht, dass GraphQL ein interessanter Ansatz für die Servicezusammensetzung sein kann, der als eine Art Middleware für bestehende APIs fungiert.
Aufgrund seiner Sichtbarkeit aller APIs wird das API-Gateway zum logischen Ort für die Durchführung der Dienstekomposition. So können Entwickler die APIs hinter dem Gateway kombinieren, um die Geschäftslogik zu verbessern, ohne neue Services schreiben zu müssen, die einfacher in einer Schicht der Dienstekomposition kombiniert werden können.
Die Dienstekomposition in GraphQL wird durch die Verwendung eines stark typisierten Schemas ermöglicht, das die Form der für Kunden verfügbaren Daten definiert. Clients können dieses Schema verwenden, um Abfragen zu erstellen, die die benötigten Daten genau angeben, unabhängig davon, welche Dienste oder Quellen sie bereitstellen. Resolver, bei denen es sich um Funktionen handelt, die die Abfragen den Datenquellen zuordnen, werden verwendet, um Daten aus dem entsprechenden Dienst oder der entsprechenden Quelle abzurufen. Während GraphQL zwar eine bessere Sicherheit verspricht, erweist sich diese als nur so gut wie der Entwickler, der den Code schreibt.
Weitere Merkmale und Funktionen
Einige weitere Funktionen wurden noch nicht in Abbildung 6: API-Verwaltungs- und Infrastrukturfunktionen erwähnt. Diese verbleibenden Merkmale und Funktionen können in einzelne Verwaltungs- und Betriebs- oder Datenebenenfunktionen verschoben werden.
Wir verwenden bewusst den Begriff „Akteur“, um zu vermeiden, eine bestimmte Implementierungs- oder Anbietertechnologie vorzuschlagen. Die Implementierung des Gateway-Akteurs könnte auf Methoden, Funktionen, Arbeitern, Threads und Prozessen basieren, die unter Verwendung von Infrastrukturen implementiert werden, die auf VMs, Containern, Serverless-Ansätzen oder anderen herstellerspezifischen Herangehensweisen basieren.
Eigenschaften und Verhalten der Komponente
Der mit der Architektur der verteilten Gateway-Akteure (DGA) verfolgte Ansatz vereinfacht die Funktionen des API-Gateways und verschiebt andere Inline-Funktionen entweder an den Netzwerkrand oder die Steuerungsebene.
Steuerungsebene
Abgesehen von den API-Gateway-Funktionen empfiehlt die DGA-Architektur auch, Funktionen zu identifizieren, die in der Steuerungsebene als logisch zentralisierte Komponente besser verarbeitet werden könnten, als in der Implementierung eines monolithischen API-Gateways. Die Verwaltung und Steuerung der bereits bestehenden API-Infrastruktur können um diese zusätzliche Funktionalität erweitert werden.
Vereinfachtes API-Gateway
Die Vereinfachung des API-Gateways wird somit zu einer Aufgabe, bei der ein Standardsatz von Kernfunktionen abgeleitet wird, den alle API-Gateway-Anbieter über einen gemeinsamen Satz von Konfigurationsparametern verwalten können.
Ein Unternehmen, das diese Transformation durchführen möchte, könnte die DGA-Architektur nacheinander für jede Anwendung einführen, ohne die bestehenden Bereitstellungen zu stören und ohne dass ein gestapelter Betrieb erforderlich ist.
Verteilte Gateway-Akteure
Ein wichtiger Aspekt eines DGA besteht darin, dass jeder Gateway-Akteur kurzlebig ist und nur für die Dauer einer API-Sitzung instanziiert wird (d. h. ein Client führt einen API-Aufruf durch).
Ein verteilter Gateway-Akteur kann flexibler, skalierbarer und kostengünstiger sein als das herkömmliche API-Gateway. Anstatt sich auf mehrere monolithische API-Gateways von verschiedenen Anbietern zu verlassen, um den API-Datenverkehr zu aggregieren und zu verarbeiten, ermöglicht der Gateway-Akteur Entwicklern, einzelne Gateway-Instanzen für jede API näher am Rand des Netzwerks festzulegen und bereitzustellen. Die APIs selbst könnten eine bessere Kontrolle und Anpassung an ihre spezifischen Bedürfnisse bieten.
Dieser neue Ansatz ermöglicht zudem eine größere Skalierbarkeit, da Entwickler die Instanzen der Gateway-Akteure bei Bedarf problemlos erhöhen können, um den höheren Datenverkehr zu bewältigen, ohne sich um den Aufwand für die Verwaltung eines großen, zentralisierten Gateways kümmern zu müssen.
Neben seinen technischen Vorteilen bietet der Gateway-Akteur auch Kosteneinsparungen gegenüber dem herkömmlichen API-Gateway, da Unternehmen nur für die kurzlebigen Instanzen der verwendeten Gateway-Akteure bezahlen müssen. Dieses Bereitstellungsmodell kann Möglichkeiten für zusätzliche Umsatzmodelle eröffnen.
Platzierung des Gateway-Akteurs
Durch die Nutzung einer API-Transportschicht entkoppeln die DGAs im Wesentlichen den API-Eintrittspunkt vom API-Gateway. Die DGAs können an den Netzwerkrand verschoben werden, d. h. näher an den Client, der den API-Aufruf durchführt. Die APIs können in den DGAs enden und dann unter Einsatz beliebiger Methoden transportiert werden. Dies unterscheidet sich von Abbildung 3: Architekturen bisheriger API-Gateways, bei denen der Client-Datenverkehr topologisch angrenzend an die API-Gateways eintritt.
Fazit
Unsere Absicht war es daher, einen anbieter- und bereitstellungsunabhängigen Ansatz vorzuschlagen. Verschiedene Anbieter werden möglicherweise ihr eigenes geistiges Eigentum an, um diese Komponenten zu erstellen und somit ähnliche Ziele wie hier beschrieben umzusetzen.
In diesem Beitrag haben wir unsere Erkenntnisse aus mehreren Quartalen zusammengefasst, in denen wir uns Themen wie den API-Wildwuchs, Edge 2.0-Architekturen, die API-Ökonomie und Untersuchungen zu GraphQL angesehen haben. Während das letzte Wort in Bezug auf bestehende API-Infrastrukturen noch nicht gesprochen wurde, sind wir der Ansicht, dass ein neuer Ansatz erforderlich ist.
Allein das Versprechen, den Wert jedes einzelnen Geräts oder Unternehmens weltweit zu erschließen, bietet einen ausreichend starken Grund, einen neuen Ansatz zu erforschen. Wir müssen uns heute von der bisherigen API-Infrastruktur entfernen, denn obwohl diese verteilt wirkt, ist sie im Grunde monolithisch.
Wir schlagen den Ansatz des verteilten, GraphQL-basierten Gateway-Akteurs als herstellerunabhängigen Weg vor, um das volle Potenzial der aufstrebenden API-Ökonomie auszuschöpfen.