Verteilte Gateway-Akteure: Die Weiterentwicklung des API-Managements

Von Rajesh Narayanan

Überprüft und mit Beiträgen von: Ian Smith, Sam Bisbee, Andrew Stiefel, Lori MacVittie, Mike Wiley und weiteren Mitwirkenden.

Stellungnahme des F5 Office of the CTO

Das Team des Office of the CTO bei F5 beschäftigt sich seit über einem Jahr mit dem Technologiebereich rund um APIs. Dieses neueste Whitepaper setzt unsere Bemühungen fort, das sich ständig weiterentwickelnde API-Ökosystem besser zu verstehen.

Die von uns beschriebenen Herausforderungen bei der Bewältigung der zunehmenden Verbreitung von APIs werden auch zu Herausforderungen durch eine zunehmende Verbreitung von API-Gateways führen. Herkömmliche Ansätze zur Bewältigung dieser Herausforderungen werden nicht ausreichen. Graphtechnologien wie GraphQL sind zwar äußerst vielversprechend, wenn es darum geht, die mit APIs verbundene Komplexität zu beherrschen, doch sie sind nur ein Teil der Lösung, da die Herausforderungen über Konnektivität, Sicherheit und Routing hinausgehen. Der richtige Ansatz basiert auf fast dreißig Jahren Erfahrung mit der Skalierung von Systemen und Anwendungen und setzt auf eine verteilte – nicht föderierte – Architektur, die GraphQL nutzt, sich jedoch nicht ausschließlich darauf stützt.

Dieses Whitepaper untersucht einen verteilten Architekturansatz zur Bewältigung der Herausforderungen, die durch die zunehmende Verbreitung von API-Gateways entstehen.

Zusammenfassung

Die digitale Wirtschaft wird durch APIs angetrieben und schafft so eine API-gesteuerte Wirtschaft. Im Anschluss an das Whitepaper zur API-Ausbreitung wollten wir herausfinden, wie sich die Auswirkungen der API-Ausbreitung beseitigen oder abmildern lassen. GraphQL schien zwar vielversprechend, um die Folgen der API-Ausbreitung zu reduzieren, verlagert jedoch tendenziell die Verantwortung auf die Entwickler, die einen großen Teil ihrer API-Codebasis neu schreiben müssen. Eine neue Sichtweise auf GraphQL besteht jedoch darin, dass es als effektiver Gateway-Akteur eingesetzt werden kann. Der Gateway-Akteur ist eine Funktion oder ein Prozess, die bzw. der in der Nähe des Clients erstellt wird und eine API-Anfrage initiiert. Dieser Gateway-Akteur fungiert als erstes API-Gateway, an dem die API-Anfrage endet. Er kann auch kurzlebig sein, sodass er nach der Bearbeitung der Anfrage wieder entfernt werden kann.

Neben der Tatsache, dass Entwickler und Betriebsteams dem API-Management Vorrang vor API-Gateways einräumen, haben wir auch das Problem der unkontrollierten Ausbreitung von API-Gateways infolge der unkontrollierten Ausbreitung von APIs erkannt. Aus Entwicklersicht besteht das Hauptanliegen darin, sicherzustellen, dass die API korrekt und zeitnah funktioniert. Das Betriebsteam hingegen konzentriert sich stärker auf Aspekte wie Auffindbarkeit, Sicherheit, Benutzerfreundlichkeit und Zugriffskontrollen. Da API-Gateways heute eine zentrale Komponente der API-Infrastruktur sind, wurde deutlich, dass die zunehmende Verbreitung von APIs zu einem verstärkten Einsatz von API-Gateways führt – und damit zu einer unkontrollierten Ausbreitung von API-Gateways.

Die API-Architektur der Zukunft muss sich weiterentwickeln, um die zunehmende Verbreitung von APIs zu bewältigen und gleichzeitig Bereitstellung und Betrieb zu vereinfachen. Die vorgeschlagene Architektur stellt den nächsten Evolutionsschritt für API-Gateway-Entwurfsmuster dar. GraphQL ist zwar weder ein zentraler Bestandteil der Architektur noch zwingend erforderlich, kann das Gateway-Akteur-Muster jedoch verbessern.

Zusammenfassung

Das API-Management-Ökosystem muss sich von der Verwaltung monolithischer API-Gateways lösen und zu einem moderneren Systemdesignansatz übergehen. Dadurch entsteht ein agileres und effektiveres API-Management-Ökosystem.

API-Gateway-Wildwuchs – Verwaltung verteilter Monolithen

Die unkontrollierte Ausbreitung von APIs, die bereits eine Herausforderung innerhalb der API-Ökonomie darstellt, führt auch zu einer unkontrollierten Ausbreitung von API-Gateways, bei der die Verwaltung von APIs aufgrund unterschiedlicher Technologien verschiedener API-Gateway-Anbieter und eigenwilliger Teams, die die API-Gateways verwalten, außer Kontrolle gerät. Wir befinden uns an einem Wendepunkt der API-Architekturen, da das herkömmliche API-Gateway (API-GW) – eine dedizierte Softwareschicht, die als Einstiegspunkt für API-Aufrufe dient – nicht mehr ausreicht, um die Größenordnung und Komplexität des entstehenden API-Ökosystems zu bewältigen.

Abbildung 1 veranschaulicht, wie wir von der Bewältigung der API-Ausbreitung zur Bewältigung der API-Gateway-Ausbreitung übergegangen sind.

Abbildung 1: Vom API-Wildwuchs zum Wildwuchs bei API-Gateways

Das obige Entwurfsmuster deutet auf eine zentralisierte Steuerungsebene hin, wobei die API-Gateways die verteilte Datenebene bilden, wie in Abbildung 2 dargestellt.

API-Gateways sind ein wesentlicher Bestandteil moderner Softwarearchitekturen und bieten eine zentrale Kontroll- und Sicherheitsinstanz für APIs. Mit der wachsenden Zahl der von API-Gateways angebotenen Funktionen sind sie jedoch zunehmend komplexer und schwieriger zu verwalten geworden. In vielen Fällen haben sich diese Gateways zu monolithischen Systemen entwickelt, in denen zahlreiche Funktionalitäten in einem einzigen Paket gebündelt sind.

Abbildung 2: Verteilte Monolithen verwalten

Die Verwaltung mehrerer Gateways mag zwar wie eine verteilte Architektur erscheinen, tatsächlich handelt es sich dabei jedoch nicht um eine echte Verteilung. Das liegt daran, dass die Gateways weiterhin eng miteinander gekoppelt sind und gemeinsam genutzte Ressourcen und Konfigurationen nur schwer voneinander getrennt werden können. Daher verwalten viele Unternehmen letztlich verteilte Monolithen – mit all den damit verbundenen Herausforderungen.

Legacy-API-Gateway-Architekturen

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 durchlaufen eine Firewall, bevor sie das API-Gateway erreichen. Das API-Gateway, das als Reverse-Proxy fungiert, leitet den Datenverkehr anschließend an den API-Workload weiter.

Abbildung 3: Herkömmliche API-Gateway-Architekturen

Das herkömmliche API-Gateway wird zum Engpass für das API-Management, wenn API-Gateways im gesamten Unternehmen bereitgestellt werden oder wenn API-Workloads aufgrund der zunehmenden API-Verbreitung betriebsbedingt zwischen Regionen, Zonen, mehreren Clouds oder an den Edge verlagert werden. Verschiedene Teams richten mehrere API-Gateways ein, ohne dass es eine zentrale Stelle für die unternehmensweite Verwaltung und Kontrolle gibt. Wenn einzelne API-Services oder eine Gruppe von API-Services auf eine andere Infrastruktur (Cloud oder anderweitig) verlagert werden, benötigt das Betriebsteam eine Methode, um sämtliche Aspekte des API-Managements zu migrieren – Registrierung, Erkennung, Authentifizierung, Vernetzung, Sicherheit sowie Richtlinien für Governance, Risiko und Compliance (GRC).

Die in Abbildung 3 dargestellte Architektur ist daher langfristig weder skalierbar noch praktikabel, da sie mit der Zeit dazu führt, dass verteilte Monolithen verwaltet werden müssen (Abbildung 2).

Zwei Probleme führen dazu, dass das API-Gateway zum Engpass wird: (1) die Vielzahl unterschiedlicher API-Gateway-Anbieter und (2) die Notwendigkeit, bei zunehmender Anzahl von Anwendungen, die an immer mehr Orten ausgeführt werden, schrittweise zu skalieren.

1. Wildwuchs bei API-Gateway-Anbietern: Der Umgang mit dem Wildwuchs bei API-Gateway-Anbietern ist eine menschliche Herausforderung, da es schwierig sein kann, alle Teams davon zu überzeugen, sich für einen einzigen API-Gateway-Anbieter zu entscheiden. Auch die Migration zu einem neuen Anbieter kann aufwendig sein. Daher investieren Unternehmen viel Zeit und Ressourcen in die Verwaltung mehrerer Gateway-Anbieter. Dieses Problem lässt sich zwar angehen, doch in der Praxis ist eine vollständige Lösung möglicherweise nicht realisierbar.
2. Anwendungsskalierung: Die Skalierung von Anwendungen stellt eine Herausforderung dar, wenn eine Anwendung an einem einzelnen Standort mehr Benutzer unterstützen oder an mehreren Standorten bereitgestellt werden muss. Dazu muss die Anwendung horizontal oder vertikal skaliert werden. Mit der Anwendung müssen jedoch auch die API-Gateways skaliert und in einigen Fällen an mehreren Standorten bereitgestellt werden, um die Skalierung gemäß den aktuellen Architekturmustern zu unterstützen. Dies kann die Verwaltung der API-Gateways aus betrieblicher Sicht komplex machen.

Lösung: Ein verteiltes Gateway-Akteur-Muster

Abbildung 4 zeigt ein Muster verteilter Gateway-Akteure, mit dem der unkontrollierten Ausbreitung von API-Gateways begegnet werden kann. Das verteilte Muster selbst ist zwar nicht neu, wird in diesem Dokument jedoch für den Kontext von API-Gateways formalisiert. Die Clients initiieren die API-Anfrage. Die verteilten Gateway-Akteure sind kurzlebig und werden bei Bedarf so nah wie möglich am Client instanziiert. Die API-Transportschicht ist dafür verantwortlich, die API-Anfrage vom Gateway-Akteur an das vereinfachte API-Gateway zu senden, das die Anfrage anschließend an den entsprechenden API-Workload weiterleitet. Die GraphQL-Unterstützung in den verteilten Akteuren ist zwar eher ein Implementierungsdetail als eine Voraussetzung für die Funktionsfähigkeit dieses Musters, ermöglicht jedoch zusätzliche Funktionen wie die Service-Orchestrierung. Anstatt also eine neue Service-Orchestrierungsschicht zu erstellen, könnte GraphQL diese Funktion übernehmen.

Abbildung 4: GraphQL-basierte verteilte Gateway-Akteure

Zur Klarstellung: Der Datenverkehr verläuft von rechts nach links. Das heißt, die Clients befinden sich auf der rechten Seite, und die API-Anfragen werden vom Client initiiert, wie in Abbildung 5 dargestellt.

Abbildung 5: Der Datenverkehr fließt vom Client (rechts) zur API-Workload (links)

Es zeichnet sich ein neues Bereitstellungsmuster ab, bei dem Gateway-Aktoren eingesetzt werden, um die übermäßige Abhängigkeit von API-Gateways bei der Verwaltung von APIs innerhalb eines Unternehmens und über Unternehmensgrenzen hinweg zu verringern oder diese vollständig zu ersetzen. GraphQL ist für diese Architektur zwar nicht erforderlich, doch seine Einführung kommt zum richtigen Zeitpunkt, da der Gateway-Aktor die geeignete Grundlage für die Unterstützung von GraphQL bietet.

Rolle von API-Gateways im API-Management

Um API-Gateways besser zu verstehen, ist es wichtig, zunächst die verschiedenen Komponenten einer modernen API-Management-Infrastruktur zu betrachten.

API-Management-Infrastruktur und -Funktionen

Abbildung 6 bietet eine umfassende visuelle Darstellung der verschiedenen Funktionen und Komponenten, die für das API-Management von zentraler Bedeutung sind. Neben API-Gateways, die für die Weiterleitung und Steuerung des Datenverkehrs zu Backend-Diensten erforderlich sind, gibt es mehrere weitere wichtige Infrastrukturkomponenten. Dazu können unter anderem Lösungen für Authentifizierung, Ratenbegrenzung, Caching und Service Mesh gehören. Durch die Einbindung dieser Funktionen können Unternehmen die Kontrolle über ihre APIs erlangen, die Sicherheit erhöhen und die Leistung optimieren.

Abbildung 6: Funktionen für API-Management und Infrastruktur

Allgemeine Funktionen des API-Gateways

Sehen wir uns die allgemein bekannten und vertrauten Funktionen von API-Gateways an:

1. Routing: Leitet Anfragen basierend auf dem Pfad oder Inhalt der Anfrage an den entsprechenden Backend-Dienst weiter.
2. Authentifizierung und Autorisierung: Authentifiziert und autorisiert Anfragen über einen zentralen Zugangspunkt und stellt sicher, dass nur autorisierte Clients auf die Backend-Dienste zugreifen können.
3. Ratenbegrenzung: Begrenzt die Häufigkeit, mit der Clients Anfragen an die zugrunde liegenden APIs senden können, verhindert so eine übermäßige Nutzung und schützt die Backend-Dienste vor Überlastung.
4. Caching: Speichert Antworten der zugrunde liegenden APIs im Cache, wodurch weniger Anfragen an die Backend-Dienste erforderlich sind und die Leistung verbessert wird.
5. Protokollübersetzung: Übersetzt zwischen verschiedenen Protokollen wie HTTP und WebSockets, sodass Clients über unterschiedliche Protokolle auf die zugrunde liegenden APIs zugreifen können.
6. Lastverteilung: Verteilt Anfragen auf mehrere Backend-Dienste und verbessert so die Skalierbarkeit und Zuverlässigkeit.
7. Sicherheit: Übernimmt Sicherheitsaufgaben wie Ver- und Entschlüsselung, um eine sichere Datenübertragung zu gewährleisten.
8. Analyse und Überwachung: Erfasst und meldet Nutzungskennzahlen und Fehlerinformationen. Dadurch wird transparent, wie das System genutzt wird, und Leistungsengpässe sowie Fehler lassen sich leichter erkennen.
9. Versionierung: Verwaltet die Versionierung der zugrunde liegenden APIs, sodass Clients je nach Bedarf auf verschiedene Versionen der API zugreifen können.
   
10. Diensterkennung: Erkennt verfügbare Backend-Dienste und leitet Anfragen dynamisch an sie weiter, wodurch eine dynamischere und flexiblere Diensterkennung ermöglicht wird.

Kontext: API-Gateways im Fokus

Nach der Analyse der Funktionen der API-Management-Infrastruktur stellten wir fest, dass wir die Rolle von API-Gateways besser verstehen und Alternativen zum derzeitigen monolithischen API-Gateway-Design untersuchen müssen.

Da die wachsende Zahl von APIs bereits zu einer unkontrollierten Ausbreitung von APIs und API-Gateways führt, immer mehr Clients mobil oder stark verteilt sind und Recheninfrastruktur inzwischen überall – auch am Netzwerkrand – verfügbar ist, benötigen wir einen Ansatz, der die Agilität, Flexibilität, Skalierbarkeit, Leistung und Sicherheit des API-Ökosystems verbessern kann.

Dieser neue Ansatz erfordert ein schlankes Design, das die Vorteile einer wirklich verteilten Architektur voll ausschöpfen kann.

API-Gateways

Wir analysieren die Funktionalität und den Umfang eines API-Gateways genauer, um seine Feinheiten und Grenzen herauszuarbeiten.

Ein API-Gateway ist eine zentrale Komponente moderner API-Management-Infrastrukturen. Im Kern handelt es sich dabei um einen Reverse-Proxy, der als Vermittler zwischen Clients und Backend-Diensten fungiert und gleichzeitig verschiedene Aufgaben für eingehende Anfragen übernimmt. So kann das Gateway beispielsweise die Authentifizierung durchführen, die Anfragerate begrenzen, Anfragen weiterleiten, Sicherheitsrichtlinien anwenden, den Datenverkehr überwachen und Versionierungsregeln umsetzen, bevor es die Anfrage an einen geeigneten Backend-Dienst übermittelt. Nachdem der Backend-Dienst die Anfrage verarbeitet und eine Antwort zurückgegeben hat, kann das API-Gateway Aufgaben wie Caching, Protokollübersetzung und Antwortverarbeitung übernehmen, bevor es die Antwort an den Client weiterleitet.

Mit der wachsenden Zahl von APIs haben sich API-Gateways weiterentwickelt und bieten heute neben dem grundlegenden Routing eine Vielzahl neuer Funktionen, wodurch sie faktisch zu monolithischen Systemen geworden sind. Diese Gateways übernehmen inzwischen Aufgaben wie Authentifizierung und Ratenbegrenzung, um die Leistung zu verbessern und Backend-Dienste zu entlasten. Trotz dieser erweiterten Funktionalität bleiben API-Gateways jedoch ein zentraler Zugangspunkt zum Backend-Dienst, was in stark verteilten Umgebungen zu Herausforderungen führen kann.

Insbesondere der Aufstieg von Cloud-, Hybrid-Multi-Cloud- und Edge-Infrastrukturen hat es erschwert, mit einem API-Gateway-Ansatz Agilität, Sicherheit und Verwaltbarkeit zu gewährleisten. Da Clients, Geräte und Anwendungs-Workloads potenziell über zahlreiche Standorte verteilt sind, eignet sich ein API-Gateway möglicherweise nicht, um das erforderliche Maß an Edge-freundlicher Architektur bereitzustellen.

Herausforderungen bei API-Gateways

Da sie eine Vielzahl von Aufgaben übernehmen und in mehrere Systeme integriert werden müssen, sind API-Gateways in der Regel schwierig bereitzustellen und zu verwalten. Auch wenn die Verwaltung von API-Gateways komplex sein kann, ist sie dennoch eine entscheidende Voraussetzung, um die Verfügbarkeit, Sicherheit und Skalierbarkeit einer API zu gewährleisten. Unternehmen setzen häufig spezialisierte Tools wie API-Management-Plattformen ein, um ihre API-Gateways effektiver zu verwalten und zu überwachen.

Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit. Zu den Faktoren, die zur Komplexität von API-Gateways beitragen, gehören unter anderem:

1. Konfigurationsverwaltung: API-Gateways verfügen häufig über eine Vielzahl von Konfigurationsoptionen und Einstellungen, die verwaltet und gepflegt werden müssen, beispielsweise Routingregeln, Ratenbegrenzungen und Sicherheitseinstellungen. Die Verwaltung dieser Einstellungen kann komplex und zeitaufwendig sein, insbesondere wenn die Anzahl der zugrunde liegenden APIs und Clients wächst.
2. Integration mit anderen Systemen: Die Gateways müssen in eine Vielzahl anderer Systeme integriert werden, beispielsweise in Authentifizierungs- und Autorisierungssysteme, Load Balancer und Datenbanken. Dies kann komplex sein, insbesondere wenn die zugrunde liegenden Systeme nicht gut integriert sind oder das API-Gateway mehrere Protokolle oder Datenformate verarbeiten muss. Noch problematischer wird dies, wenn ein Unternehmen mehrere API-Gateway-Implementierungen verschiedener Anbieter betreibt.
3. Skalierbarkeit und Verfügbarkeit: API-Gateways müssen eine große Anzahl von Anfragen verarbeiten und eine hohe Verfügbarkeit gewährleisten können. Dies kann insbesondere bei einer großen Anzahl von Backend-Diensten und Clients komplex zu verwalten sein.
4. Sicherheit: Als kritische Komponente der API-Sicherheit müssen API-Gateways entsprechend konfiguriert und verwaltet werden, um den Schutz sensibler Daten und eine kontrollierte Zugriffssteuerung zu gewährleisten. Dies kann komplex sein und erfordert eine kontinuierliche Überwachung und Verwaltung.
5. Versionierung: Mit zunehmender Anzahl der zugrunde liegenden APIs und Clients kann es immer schwieriger werden, verschiedene Versionen der API zu verwalten und sicherzustellen, dass die Clients auf die richtige Version zugreifen.
6. Überwachung und Fehlerbehebung: API-Gateways können große Datenmengen erfassen und erzeugen. In einem Großunternehmen können die Gateways über viele Standorte verteilt sein, was es erschwert, Ereignisse, die sich auf den Gesamtzustand der Anwendung auswirken, miteinander in Beziehung zu setzen und Probleme zu beheben.

Wildwuchs bei API-Gateways

API-Gateway-Wildwuchs bezeichnet die unkontrollierte Zunahme mehrerer unabhängiger API-Gateways innerhalb eines Unternehmens. Verschiedene Teams oder Geschäftsbereiche erstellen häufig eigene APIs, was dazu führen kann, dass mehrere unabhängige API-Gateways für die Verwaltung dieser unterschiedlichen APIs eingerichtet werden. Verschiedene Teams können zudem API-Gateways unterschiedlicher Anbieter oder Lösungen verwenden, um verschiedene Arten von APIs zu verwalten.

Dies führt zur Bereitstellung mehrerer API-Gateways, die jeweils über unterschiedliche Funktionen verfügen.

Die unkontrollierte Ausbreitung von API-Gateways bringt mehrere zusätzliche Herausforderungen mit sich:

1. Skalierung der API-Gateway-Verwaltung: Mehrere voneinander unabhängige API-Gateways können deren Verwaltung und Wartung erschweren, insbesondere wenn die Anzahl der zugrunde liegenden APIs und Clients wächst.
2. Ineffizienzen beim Ost-West-Datenverkehr: Mehrere Gateways können dazu führen, dass Anfragen mehrere dieser Gateways durchlaufen müssen, was die Latenz erhöht und die Leistung beeinträchtigt.
3. Einheitlichkeit der Sicherheitsrichtlinien: Die Verwaltung mehrerer Gateways kann schwierig sein und zu uneinheitlichen Sicherheitsrichtlinien führen. Dadurch wird es schwieriger, den Schutz sensibler Daten und die Kontrolle des Zugriffs zu gewährleisten.
4. Standardisierte Governance: Bei mehreren Gateways kann es schwierig sein, sicherzustellen, dass alle APIs ordnungsgemäß verwaltet werden und Standards sowie Best Practices entsprechen.
5. Höhere Kosten: Der Einsatz mehrerer Gateways kann zu höheren Kosten für Infrastruktur, Entwicklungsressourcen und Wartung führen.
6. Größere Herausforderungen bei der Integration: Mehrere Gateways erschweren die Integration mit anderen Systemen und Technologien, beispielsweise mit anderen Datenbanken, Data-Warehouses und Datenanalysetools.

Unternehmen sollten bestrebt sein, ihr API-Management und ihre API-Governance zu zentralisieren und nur einen einzigen API-Gateway-Typ zu verwenden. Dies mindert zwar die oben genannten Herausforderungen einer unkontrollierten Ausbreitung von API-Gateways, doch eine einheitliche API-Gateway-Strategie ist alles andere als einfach.

Herausforderungen bei der Standardisierung von API-Gateways in einem Unternehmen

Wenn Unternehmen organisch oder durch Übernahmen wachsen, sind sich interne Teams, die bestimmten Geschäftsbereichen (Business Units, BUs) zugeordnet sind, bei der Auswahl einer API-Gateway-Technologie oder eines Anbieters häufig uneinig. Dies hat unter anderem folgende Gründe:

• Technologie: Verschiedene Teams oder Geschäftsbereiche nutzen unterschiedliche Technologie-Stacks oder bevorzugen unterschiedliche API-Gateway-Lösungen, was die Standardisierung auf einen einzigen Gateway-Typ erschwert.
• Altsysteme: Einige Teams verfügen über bestehende Systeme, die mit einer anderen Art von API-Gateway entwickelt wurden. Diese Systeme durch ein neues Gateway zu ersetzen, wäre schwierig, insbesondere wenn sie noch in Betrieb sind.
• Anpassungen: Einige Teams passen ihre bestehenden API-Gateways an spezifische Anforderungen an und werden Schwierigkeiten haben, diese Anpassungen auf einem neuen Gateway nachzubilden.
• Austauschkosten: Der Austausch bestehender API-Gateways durch ein neues, standardisiertes Gateway kann sowohl hinsichtlich der Entwicklung als auch der Wartung kostspielig sein.
• Schulung von Entwicklern: Teams verfügen über unterschiedliche Fachkenntnisse und müssen sich möglicherweise mit einer neuen Gateway-Technologie eines anderen Anbieters vertraut machen oder entsprechend geschult werden – ein Prozess, der sowohl zeitaufwendig als auch kostspielig sein kann.
• Begrenzte Ressourcen: Unternehmen verfügen nur über begrenzte Ressourcen in Form von Entwicklern, Budget und Zeit für die Umstellung, was die Implementierung eines neuen Gateways erschwert.
• Anwendungsabhängigkeiten: Verschiedene Teams oder Geschäftsbereiche sind auf unterschiedliche Weise von ihren bestehenden Gateways abhängig, etwa durch die Integration in bestimmte Systeme oder andere benutzerdefinierte Integrationen. Dies erschwert den Wechsel zu einem neuen Gateway.
• Drittanbieterlösungen: Teams, die in das Gateway integrierte Drittanbieterlösungen verwenden, werden Schwierigkeiten haben, zu einer neuen Lösung zu migrieren, die diese Drittanbieterlösungen nicht unterstützt.

Wenn also eine bestehende Anwendung von einem etablierten Team mit klaren Vorstellungen betreut wird, wird dieses Team nicht auf ein anderes Bereitstellungsmuster umsteigen wollen, um den Betrieb seines Dienstes nicht zu beeinträchtigen.

Daraus können wir schließen, dass ein neuer Ansatz erforderlich ist, der die vielfältigen Einschränkungen bestehender API-Infrastrukturen berücksichtigt und dabei die unkontrollierte Ausbreitung von API-Gateways als einen der wichtigeren Aspekte hervorhebt.

Designüberlegungen

Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit, fasst jedoch einige der übergeordneten Designüberlegungen zusammen, die unserer Ansicht nach bei der Entwicklung der Lösung berücksichtigt werden sollten:

1. Koexistenz mit bestehenden Bereitstellungen: Da Unternehmen bestrebt sind, mit der sich ständig wandelnden Technologielandschaft Schritt zu halten, verfügen sie häufig über eine Vielzahl unterschiedlicher API-Gateway-Bereitstellungen. Ein vollständiger Austausch der bestehenden API-Infrastruktur ist nicht praktikabel, da dies kritische Geschäftsabläufe beeinträchtigen kann. Daher muss jede neue Bereitstellung so konzipiert sein, dass sie parallel zur derzeit eingesetzten Architektur betrieben werden kann.
2. API-Gateway-Funktionen standardisieren: Das Hauptziel der API-Strategie eines Unternehmens sollte darin bestehen, die Funktionen seiner API-Gateways zu standardisieren. Dies kann aufgrund der Vielzahl unterschiedlicher APIs und der verschiedenen Anforderungen einzelner Geschäftsbereiche eine Herausforderung darstellen. Dennoch ist diese Standardisierung entscheidend für den Aufbau einer stabilen und sicheren Infrastruktur, die die digitale Transformation des Unternehmens unterstützen kann.
3. Edge-Bereitstellungen nutzen: Die Edge-Infrastruktur birgt 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 zu verlagern. Dies ist möglich, da dieselbe Infrastruktur, die zur Erstellung von APIs verwendet wird, auch zur Einrichtung verteilter Gateway-Akteure genutzt werden kann. Daher muss die Lösung die Nähe der Edge-Infrastruktur zu den Clients, die die API-Anfrage initiieren, voll ausschöpfen.
4. Transportunabhängig: Ein wichtiger Aspekt bei der Implementierung einer Architektur mit verteilten Gateway-Akteuren ist, dass sie nicht von einem bestimmten Transportmechanismus abhängig sein sollte. Unabhängig davon, ob ein Unternehmen herkömmliche IP-Netzwerke, Overlay-Netzwerke, VPNs oder Messaging-Infrastrukturen mit geringer Latenz nutzen möchte, muss die Lösung gegenüber dem Transportmechanismus agnostisch sein. Dies ermöglicht mehr Flexibilität und versetzt Unternehmen in die Lage, den Transportmechanismus zu wählen, der ihren spezifischen Bedürfnissen und Anforderungen am besten entspricht.
5. GraphQL-Unterstützung: GraphQL erfreut sich bei der API-Entwicklung aufgrund seiner zahlreichen Vorteile gegenüber herkömmlichen REST-APIs zunehmender Beliebtheit. Ein wesentlicher Vorteil besteht darin, dass GraphQL einen differenzierten Datenzugriff ermöglicht, sodass Clients in einer einzigen Anfrage genau angeben können, welche Daten sie benötigen. Darüber hinaus kann GraphQL die Aggregation von Daten aus mehreren Diensten vereinfachen und eignet sich daher als Architektur für die Zusammenstellung und Orchestrierung von Diensten. Dies kann den Netzwerk-Overhead reduzieren und die Leistung verbessern, insbesondere in einem verteilten System, in dem mehrere API-Dienste zur Bearbeitung einer einzigen Anfrage verwendet werden. Schließlich kann GraphQL mit seinem streng typisierten Schema und seiner Abfragesprache die Auffindbarkeit von APIs verbessern und die Client-Entwicklung erleichtern.
6. Sicherheit ist eine Grundvoraussetzung: Das oberste Designziel besteht darin, die API-Sicherheitslage des Unternehmens zu verbessern. Die Lösung könnte einige Funktionen übernehmen, etwa die Authentifizierung und Autorisierung von API-Anfragen, die Implementierung von Zugriffskontrollen und den Schutz vor gängigen Sicherheitsbedrohungen wie Cross-Site-Scripting (XSS) und SQL-Injection-Angriffen. Unter keinen Umständen darf die neue Lösung das bestehende Bedrohungsmodell beeinträchtigen oder es so grundlegend verändern, dass sich die Angriffsfläche vergrößert. Indem Sicherheit als Designziel priorisiert wird, muss die Architektur eine sicherere Umgebung für die API-Kommunikation schaffen und so das Risiko von Datenschutzverletzungen und anderen Sicherheitsvorfällen verringern.

Aus diesen Designüberlegungen lassen sich konkrete Anforderungen ableiten, die wir in unsere Lösung mit verteilten Gateway-Aktoren (Distributed Gateway Actors, DGA) integriert haben.

Verteilte Gateway-Akteure

Nachdem wir API-Gateways nun umfassend untersucht haben, können wir die Lösung mit verteilten Gateway-Akteuren erläutern.

Entwurf verteilter Gateway-Aktoren

Das Entwurfsmuster der Distributed Gateway Actors (DGA) ist von Edge Computing und der Bereitstellung von Rechenleistung in unmittelbarer Nähe eines Clients inspiriert. Der Kerngedanke besteht darin, jeden Gateway Actor möglichst nah am Client zu verteilen und ihn nur für die Dauer der Transaktion bestehen zu lassen, bevor er am Ende gelöscht wird.

Annahmen

Dieser Lösung liegen unter anderem die folgenden Annahmen zugrunde.

Edge Computing ist inzwischen weiter verbreitet, sodass nun Rechenressourcen geografisch näher am Client verfügbar sind. Die Gateway-Akteure können auf diesen Edge-Computing-Knoten instanziiert werden. Ziel ist eine Implementierung, bei der der DGA sehr schlank und kurzlebig ist, sodass er auf beliebigen Edge-Computing-Ressourcen instanziiert werden kann.

Der API-Transport ist eine entscheidende Komponente der Infrastruktur, da er den Aufbau eines Netzwerks zwischen den Gateway-Akteuren und dem API-Gateway umfasst. Welche Art von Infrastruktur erforderlich ist, hängt vom Anbieter oder Unternehmen ab und kann variieren. Beispielsweise kann eine große Public Cloud ihr eigenes Backbone für den API-Transport nutzen. Eine andere Implementierungsmöglichkeit wäre ein Messaging-Bus mit geringer Latenz, der auf einem bestehenden Netzwerk mit hoher Bandbreite und geringer Latenz innerhalb eines Unternehmensrechenzentrums aufsetzt.

Funktionen des API-Gateways

Noch einmal zusammengefasst: Das API-Gateway ist im Wesentlichen ein Reverse-Proxy, dessen Hauptfunktion darin besteht, den HTTP-Datenverkehr an die entsprechenden API-Workloads weiterzuleiten. Dieser Ansatz ist sinnvoll, wenn sich alle APIs am selben Ort befinden, etwa in einem lokalen On-Premises-Netzwerk oder in einer Virtual Private Cloud (VPC) innerhalb einer Availability Zone. Wenn jedoch die Anzahl der APIs steigt, sie über eine hybride Infrastruktur verteilt werden oder mobil werden, erweist sich dieser Ansatz für die Gestaltung von API-Gateways als ineffizient, komplex im Betrieb und kostspielig.

Auch wenn es unterschiedliche Auffassungen darüber geben mag, wie all die in Abbildung 6 beschriebenen Funktionen einzuordnen sind, können wir uns darauf einigen, dass die API-Management-Infrastruktur mittlerweile eine komplexe Bereitstellung aus zahlreichen Komponenten darstellt, die sorgfältig orchestriert werden müssen. 

Abbildung 7: Akteure eines verteilten GraphQ-basierten Gateways

Abbildung 7 ordnet die verschiedenen Merkmale und Funktionen des API-Managements aus Abbildung 6 der Distributed-Gateway-Actors-Architektur zu. Diese Zuordnung veranschaulicht, wie die einzelnen Merkmale und Funktionen auf den DGA-Ansatz abgestimmt sind, und hebt die nahtlose Integration der API-Management-Komponenten in die Architektur hervor.

Zentralisierte Funktionen

Die meisten der oben aufgeführten Funktionen verfügen über eine Verwaltungskomponente, die sich logisch zentralisieren lässt. Unser Ziel besteht nicht darin, die Verwaltungsebene neu zu konzipieren, sondern nach Möglichkeit bestimmte Funktionen zu entfernen.

Kernfunktionen des API-Gateways

Dabei handelt es sich um Funktionen der Datenebene, die daher am besten in der API implementiert und gemeinsam mit den Anwendungs-Workloads bereitgestellt werden. API-Gateways sind eine entscheidende Komponente moderner Microservices-Architekturen und dienen als Einstiegspunkt für den gesamten externen Datenverkehr. Zu ihren Kernfunktionen zählen Routing, Lastverteilung, dynamisches Routing, Zustandsprüfungen, Wiederholungsversuche und Ausweichmechanismen.

Ein API-Gateway leitet eingehende Anfragen an den entsprechenden Microservice weiter, verteilt den Datenverkehr auf mehrere Instanzen, unterstützt dynamisches Routing, überwacht den Zustand der Microservices und ihrer Instanzen, wiederholt fehlgeschlagene Anfragen und stellt Ausweichantworten bereit, 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 verteilt oder zentralisiert werden.

Dieser modulare Ansatz ermöglicht eine flexiblere und optimierte Architektur und bildet den Kern unserer Empfehlung, die unternehmensweite API-Infrastruktur zu vereinfachen, zu modernisieren und zu skalieren.

Zusammengeführt

API-Gateway und API-Management werden von Anbietern häufig fälschlicherweise als Bestandteile der API-Gateway-Funktion gleichgesetzt. Tatsächlich handelt es sich jedoch um zwei unterschiedliche Funktionen, die getrennt voneinander betrachtet werden sollten. Ein API-Gateway ist dafür zuständig, Anfragen von Clients an Backend-Dienste weiterzuleiten, während das API-Management ein breiteres Spektrum an Funktionen umfasst, darunter Zugriffskontrolle, Ratenbegrenzung, Analysen und die Verwaltung von Entwicklerportalen.

Auch wenn einige Anbieter sowohl API-Gateway- als auch API-Management-Funktionen in einem einzigen Produkt anbieten, ist es wichtig, die Unterschiede zwischen diesen Funktionen zu verstehen und sie anhand ihrer jeweiligen spezifischen Anforderungen getrennt 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

Die hier aufgeführten Features sind Kernfunktionen, die direkt in den Datenpfad eingebunden sein müssen. Bei einem verteilten Gateway-Muster werden auch einige der Inline-Funktionen des API-Gateways verteilt. Zu diesen Funktionen gehören Zugriffskontrolle, Ratenbegrenzung, Anfragevalidierung, API-Analysen, Nutzungsberichte, Überwachung der Fehlerrate, Warnmeldungen und Ereignisverarbeitung, Authentifizierungsintegration, Integration von Drittanbietern, Integration von Überwachung und Protokollierung, Edge-Caching und Komprimierung.

Die Verlagerung dieser Funktionen in das verteilte Gateway-Muster bietet folgende Vorteile:

• Geringere Belastung des API-Gateways: Trägt dazu bei, das zentrale API-Gateway zu entlasten und die Leistung und Skalierbarkeit des Systems zu verbessern.
• Schnellere Reaktionszeiten ermöglichen: Durch die Bereitstellung dieser Funktionen näher bei den Clients werden schnellere Reaktionszeiten ermöglicht und die Latenz reduziert. Mithilfe der Zwischenspeicherung von Daten und Funktionen können die am Netzwerkrand gehosteten API-Gateways schnell auf eingehende Anfragen reagieren.

Beispielsweise können Zugriffskontrolle, Ratenbegrenzung und Anfragevalidierung von einem Edge-Gateway-Akteur übernommen werden, der näher bei den Clients bereitgestellt wird. Dadurch lässt sich die Anzahl der Anfragen reduzieren, die vom zentralen API-Gateway verarbeitet werden müssen, was dessen Leistung und Skalierbarkeit verbessert. Ebenso können API-Analysen, Nutzungsberichte, die Überwachung von Fehlerraten, Warnmeldungen und Ereignisverarbeitung sowie die Integration von Monitoring und Protokollierung von Edge-Gateways übernommen werden, die Daten aus mehreren Microservices erfassen und aggregieren können.

Gateway-Akteure – GraphQL-Kandidaten

Eine wichtige Funktion, die API-Gateways heute unterstützen, ist die Komposition und Orchestrierung von Diensten. Dies kann zwar recht komplex werden, doch wäre es problematisch, wenn das vereinfachte API-Gateway diese Funktion nicht unterstützen würde. Wir sind der Ansicht, dass GraphQL einen interessanten Ansatz für die Komposition von Diensten darstellen kann, indem es als eine Art Middleware für bestehende APIs fungiert.

Da das API-Gateway Einblick in alle APIs hat, ist es der logische Ort für die Service-Komposition. So können Entwickler die hinter dem Gateway liegenden APIs kombinieren, um die Geschäftslogik zu erweitern, ohne neue Services schreiben zu müssen, die sich in einer Service-Kompositionsschicht leichter zusammenführen lassen.

Die Servicekomposition in GraphQL wird durch die Verwendung eines streng typisierten Schemas ermöglicht, das die Struktur der für Clients verfügbaren Daten definiert. Clients können dieses Schema verwenden, um Abfragen zu erstellen, die genau die benötigten Daten angeben – unabhängig davon, von welchen Diensten oder Quellen sie bereitgestellt werden. Resolver, also Funktionen, die Abfragen Datenquellen zuordnen, dienen dazu, Daten vom entsprechenden Dienst oder aus der entsprechenden Quelle abzurufen. GraphQL verspricht zwar mehr Sicherheit, ist jedoch nur so gut wie der Entwickler, der den Code schreibt.

Weitere Features und Funktionen

Es gibt noch einige weitere Funktionen, die in Abbildung 6: API-Management- und Infrastrukturfunktionen nicht hervorgehoben sind. Diese verbleibenden Features und Funktionen können in einzelne Management- und Betriebsfunktionen oder Funktionen der Datenebene verlagert werden.

Wir verwenden bewusst den Begriff „Akteur“, um nicht den Eindruck zu erwecken, dass eine bestimmte Implementierung oder Technologie eines bestimmten Anbieters gemeint ist. Die Implementierung des Gateway-Akteurs könnte auf Methoden, Funktionen, Workern, Threads und Prozessen basieren und Infrastrukturen nutzen, die auf VMs, Containern, serverlosen Architekturen oder anderen anbieterspezifischen Ansätzen beruhen.

Funktionen und Verhalten der Komponente

Der mit der Distributed-Gateway-Actors-Architektur (DGA) verfolgte Ansatz vereinfacht die Funktionen des API-Gateways und verlagert andere Inline-Funktionen entweder an den Netzwerkrand oder auf die Steuerungsebene.

Steuerungsebene

Neben den Funktionen des API-Gateways empfiehlt die DGA-Architektur auch, Funktionen zu identifizieren, die besser in der Steuerungsebene als logisch zentralisierte Komponente bereitgestellt werden könnten, anstatt sie innerhalb eines monolithischen API-Gateways zu implementieren. Die Verwaltung und Steuerung der bereits vorhandenen API-Infrastruktur kann erweitert und ausgebaut werden, um diese zusätzliche Funktionalität einzubeziehen.

Vereinfachtes API-Gateway

Die Vereinfachung des API-Gateways besteht somit darin, einen Standardsatz von Kernfunktionen abzuleiten, 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 Anwendung für Anwendung einführen, ohne bestehende Bereitstellungen zu beeinträchtigen und ohne eine umfassende Umstellung vornehmen zu müssen.

Verteilte Gateway-Akteure

Ein wichtiger Aspekt der 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 ein herkömmliches API-Gateway. Anstatt sich auf mehrere monolithische API-Gateways verschiedener Anbieter zu verlassen, die den API-Datenverkehr bündeln und verarbeiten, ermöglicht der Gateway-Akteur Entwicklern, für jede API individuelle Gateway-Instanzen festzulegen und näher am Netzwerkrand bereitzustellen. Die APIs selbst könnten so eine bessere Kontrolle und Anpassung an ihre jeweiligen Anforderungen ermöglichen.

Dieser neue Ansatz ermöglicht zudem eine bessere Skalierbarkeit, da Entwickler bei Bedarf problemlos weitere Gateway-Actor-Instanzen bereitstellen können, um ein erhöhtes Datenverkehrsaufkommen zu bewältigen, ohne sich Gedanken über den Verwaltungsaufwand eines großen, zentralisierten Gateways machen zu müssen.

Neben seinen technischen Vorteilen bietet der Gateway Actor auch Kosteneinsparungen gegenüber einem herkömmlichen API-Gateway, da Unternehmen nur für die kurzlebigen Gateway-Actor-Instanzen bezahlen, die sie tatsächlich nutzen. Dieses Bereitstellungsmodell kann Möglichkeiten für zusätzliche Erlösmodelle eröffnen.

Platzierung des Gateway-Aktors

Durch den Einsatz einer API-Transportschicht entkoppeln die DGAs im Wesentlichen den API-Eingangspunkt vom API-Gateway. Die DGAs können an den Netzwerkrand verlagert werden, also näher an den Client, der den API-Aufruf durchführt. Die APIs können in den DGAs terminieren und anschließend auf beliebige Weise weitertransportiert werden. Dies unterscheidet sich von Abbildung 3: Herkömmliche API-Gateway-Architekturen, wo der Client-Datenverkehr topologisch unmittelbar neben den API-Gateways in das Netzwerk eintritt. 

Fazit

Unser Ziel war es daher, einen hersteller- und bereitstellungsunabhängigen Ansatz vorzuschlagen, da verschiedene Anbieter möglicherweise über eigenes geistiges Eigentum verfügen, um diese Komponenten so zu entwickeln, dass damit ähnliche Ziele wie die beschriebenen erreicht werden.

In diesem Beitrag haben wir unsere Erkenntnisse aus mehreren Quartalen der Forschung zu API-Wildwuchs, Edge-2.0-Architekturen, der API-Ökonomie (https://www.f5.com/company/blog/inverting-the-api-is-the-digital-transformation-that-enterprises-need-to-participate-and-compete-in-an-api-economy) und unseren Untersuchungen zu GraphQL zusammengefasst. Auch wenn die Bewertung bestehender API-Infrastrukturen noch nicht abgeschlossen ist, sind wir überzeugt, dass ein neuer Ansatz erforderlich ist.

Allein die Aussicht, das Potenzial jedes einzelnen Geräts oder jeder einzelnen Entität weltweit zu erschließen, ist Grund genug, einen neuen Ansatz zu verfolgen. Wir müssen uns von der heutigen veralteten API-Infrastruktur lösen, denn obwohl sie verteilt erscheint, ist sie im Kern monolithisch.

Wir schlagen den auf verteilten GraphQL-Gateway-Akteuren basierenden Ansatz als herstellerunabhängige Möglichkeit vor, das volle Potenzial der aufstrebenden API-Wirtschaft auszuschöpfen.