Verteilte Gateway-Akteure: Weiterentwickelndes API-Management
Inhaltsverzeichnis
F5-Stellungnahme des CTO-Büros
Das Team des Office of the CTO bei F5 erforscht den Technologiebereich APIs bereits seit über einem Jahr. Dieses neueste Whitepaper ist eine Fortsetzung unserer Bemühungen, das sich ständig weiterentwickelnde API-Ökosystem zu verstehen.
Die Herausforderungen, die wir im Zusammenhang mit der Bewältigung der API-Ausbreitung beschrieben haben, führen zu Herausforderungen hinsichtlich der Ausbreitung von API-Gateways , und herkömmliche Ansätze zur Bewältigung dieser Herausforderungen werden nicht ausreichen. Obwohl Graphentechnologien wie GraphQL vielversprechend sind, wenn es darum geht, die mit APIs verbundene Komplexität zu bewältigen, stellen sie nur einen Teil der Lösung dar, denn die Herausforderungen gehen über Konnektivität, Sicherheit und Routing hinaus. Der richtige Ansatz, der auf fast dreißig Jahren Erfahrung mit der Skalierung von Systemen und Anwendungen beruht, basiert auf einer verteilten – nicht föderierten – Architektur, die GraphQL verwendet, aber nicht ausschließlich darauf angewiesen ist.
In diesem Dokument wird ein verteilter Architekturansatz zur Bewältigung der Herausforderungen der Ausbreitung von API-Gateways untersucht.
Zusammenfassung
Die digitale Wirtschaft wird durch APIs angetrieben, was uns eine API-gesteuerte Wirtschaft beschert. Im Anschluss an das Whitepaper zum Thema „API Sprawl“ wollten wir herausfinden, wie sich die Auswirkungen des API Sprawl beseitigen oder abmildern lassen. Obwohl GraphQL eine vielversprechende Methode zur Reduzierung der Auswirkungen der API-Ausbreitung zu sein scheint, führt es dazu, dass die Entwickler große Teile ihres API-Codes neu schreiben müssen. Allerdings entsteht zunehmend die Ansicht, dass GraphQL als effektiver Gateway-Akteur eingesetzt werden kann. Der Gateway-Akteur ist eine in der Nähe des Clients erstellte Funktion oder ein Prozess, der eine API-Anfrage initiiert. Dieser Gateway-Akteur fungiert als erstes API-Gateway, das die API-Anfrage beendet. Es kann auch flüchtig sein, sodass es nach der Bearbeitung der Anfrage vernichtet werden kann.
Zusätzlich dazu, dass Entwickler und Betriebsteams der API-Verwaltung Vorrang vor API-Gateways einräumen, haben wir auch das Problem der Ausbreitung von API-Gateways aufgrund der Ausbreitung von APIs entdeckt. Aus der Sicht eines Entwicklers besteht das Hauptanliegen darin, sicherzustellen, dass die API korrekt und zeitnah funktioniert. Andererseits konzentriert sich das Betriebsteam stärker auf Aspekte wie Erkennung, Sicherheit, Benutzerfreundlichkeit und Zugriffskontrollen. Da API-Gateways heutzutage eine kritische Komponente der API-Infrastruktur darstellen, wurde deutlich, dass die Verbreitung von APIs den Einsatz von API-Gateways erhöht – was zu einer Ausbreitung von API-Gateways führt.
Die API-Architektur der Zukunft muss sich weiterentwickeln, um eine zunehmende Verbreitung der APIs zu ermöglichen und gleichzeitig die Bereitstellung und den Betrieb zu vereinfachen. Die vorgeschlagene Architektur stellt die nächste Entwicklungsstufe der erforderlichen API-Gateway-Entwurfsmuster dar. Obwohl GraphQL weder zentral für die Architektur ist noch eine Notwendigkeit darstellt, kann es das Gateway-Actor-Muster verbessern.
Zusammenfassung
Das API-Management-Ökosystem muss sich von der Verwaltung von API-Gateway-Monolithen hin zu einem zeitgemäßeren Systemdesignansatz bewegen. Das Ergebnis ist ein agileres und effektiveres API-Management-Ökosystem.
API-Gateway-Ausbreitung – Verwaltung verteilter Monolithen
Die API-Ausbreitung, die bereits eine Herausforderung innerhalb der API-Wirtschaft darstellt, führt auch zu einer Ausbreitung der API-Gateways . Dabei handelt es sich um eine Situation, in der die Verwaltung von APIs aufgrund unterschiedlicher Technologien der API-Gateway-Anbieter und eigensinniger Teams, die die API-Gateways verwalten, unkontrollierbar geworden ist. Wir stehen an einem Wendepunkt in den API-Architekturen, da das herkömmliche API-Gateway (API-GWs) – eine dedizierte Softwareschicht, die als Einstiegspunkt für API-Aufrufe fungiert – nicht mehr ausreicht, um das Ausmaß und die Komplexität des entstehenden API-Ökosystems zu bewältigen.
Abbildung 1 veranschaulicht, wie wir von der Verwaltung der API-Ausbreitung zur Verwaltung der API-Gateway-Ausbreitung übergegangen sind.
Das obige Entwurfsmuster spielt auf eine zentralisierte Steuerungsebene an, wobei die API-Gateways die verteilte Datenebene bilden, wie in Abbildung 2 dargestellt.
API-Gateways sind eine wesentliche Komponente moderner Softwarearchitekturen und bieten einen zentralen Kontroll- und Sicherheitspunkt für APIs. Da jedoch die Anzahl der von API-Gateways angebotenen Funktionen zunimmt, sind sie zunehmend komplexer und schwieriger zu verwalten geworden. In vielen Fällen haben sich diese Gateways zu monolithischen Systemen entwickelt, bei denen eine breite Palette von Funktionen in einem einzigen Paket gebündelt ist.
Obwohl die Verwaltung mehrerer Gateways auf den ersten Blick wie ein verteiltes Design aussieht, handelt es sich in Wirklichkeit nicht um echte Verteilung. Dies liegt daran, dass die Gateways immer noch eng gekoppelt sind und Ressourcen und Konfigurationen gemeinsam nutzen, die nur schwer zu trennen sind. Dies hat zur Folge, dass viele Unternehmen letztlich mit der Verwaltung verteilter Monolithen und allen damit verbundenen Herausforderungen konfrontiert sind.
Legacy-API-Gateway-Architekturen
Abbildung 3 zeigt die Architektur vorhandener API-Gateways. Vom Client stammende API-Anfragen werden zunächst über ein gemeinsam genutztes oder dediziertes Netzwerk übertragen und passieren eine Firewall, bevor sie das API-Gateway erreichen. Das API-Gateway, das als Reverse-Proxy fungiert, leitet den Datenverkehr dann an die API-Workload weiter.
Das veraltete API-GW wird zu einem Engpass im API-Management, wenn API-Gateways im gesamten Unternehmen eingesetzt werden oder wenn die API-Workloads betrieblich über Regionen, Zonen, mehrere Clouds oder an den Rand verschoben werden und gleichzeitig mit der Ausbreitung der APIs zu kämpfen haben. Mehrere API-GWs werden von verschiedenen Teams hochgefahren, ohne dass es eine einheitliche Verwaltung und Kontrolle im Unternehmen gibt. Wenn ein einzelner oder eine Gruppe von API-Diensten in eine andere Infrastruktur (Cloud oder anderweitig) verschoben wird, muss das Betriebsteam über eine Methode verfügen, um alle Aspekte der API-Verwaltung zu migrieren – Registrierung, Erkennung, Authentifizierung, Netzwerk, Sicherheit sowie Governance-, Risiko- und Compliance-Richtlinien (GRC).
Die in Abbildung 3 dargestellte Architektur ist daher weder skalierbar noch langfristig praktikabel, da sie im Laufe der Zeit zur Verwaltung verteilter Monolithen führt (Abbildung 2).
Es gibt zwei Probleme, die den Engpass beim API-Gateway verursachen: (1) Ausbreitung von API-Gateway-Anbietern und (2) schrittweise Skalierung, wenn in einem Unternehmen mehr Anwendungen an mehr Orten ausgeführt werden.
- Wilder Ausbau der API-Gateway-Anbieter : Der Umgang mit der zunehmenden Verbreitung von API-Gateway-Anbietern ist eine menschliche Herausforderung, da es schwierig sein kann, alle Teams davon zu überzeugen, einen einzigen API-Gateway-Anbieter zu verwenden. Zudem kann die Migration zu einem neuen Anbieter eine mühsame Aufgabe sein. Dies hat zur Folge, dass Unternehmen Zeit und Ressourcen mit der Verwaltung mehrerer Gateway-Anbieter verbringen müssen. Dieses Problem lässt sich zwar lösen, in der Realität ist dies jedoch möglicherweise nicht ganz umsetzbar.
- Anwendungsskalierung: Das Skalieren von Anwendungen ist dann ein Problem, wenn die Anwendung mehr Benutzer an einem Standort unterstützen muss oder an mehreren Standorten bereitgestellt werden muss. Dies erfordert eine horizontale oder vertikale Skalierung der Anwendung. Wenn die Anwendung skaliert wird, müssen jedoch auch die API-Gateways skaliert werden. In einigen Fällen müssen sie an mehreren Standorten bereitgestellt werden, um die Skalierung basierend auf aktuellen Architekturmustern zu unterstützen. Dies kann die Verwaltung der API-Gateways betrieblich komplex machen.
Lösung: Ein verteiltes Gateway-Akteurmuster
Abbildung 4 zeigt ein Muster verteilter Gateway-Akteure zur Adressierung der Ausbreitung von API-Gateways. Während das verteilte Muster selbst nicht neu ist, formalisiert dieses Dokument es im Kontext von API-Gateways. Die Clients initiieren die API-Anfrage. Die verteilten Gateway-Akteure sind flüchtig und werden bei Bedarf so nah wie möglich am Client instanziiert. Die API-Transportschicht ist nun dafür verantwortlich, die API-Anforderung vom Gateway-Akteur an das vereinfachte API-Gateway zu senden, das die Anforderung dann an die entsprechende API-Workload weiterleitet. Während die Verwendung der GraphQL-Unterstützung in den verteilten Akteuren eher ein Detail als eine Voraussetzung für die Funktion dieses Musters ist, ermöglicht sie unterstützende Funktionen wie die Service-Orchestrierung. Anstatt eine neue Service-Orchestrierungsschicht zu erstellen, könnte GraphQL diese Unterstützung bereitstellen.
Zur Verdeutlichung: Das Verkehrsmuster 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.
Es gibt ein neues Bereitstellungsmuster, bei dem Gateway-Akteure verwendet werden, um die übermäßige Abhängigkeit von API-Gateways beim Verwalten von APIs innerhalb und über ein Unternehmen hinweg zu ersetzen oder zu reduzieren. Obwohl GraphQL für die Architektur nicht erforderlich ist, ist seine Einführung zeitgemäß, da der Gateway-Akteur das richtige 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 Status der API-Infrastrukturen, insbesondere der API-Gateways, genau zu untersuchen. Dies liegt daran, dass wir die Ausbreitung von Gateways als einen wesentlichen Faktor identifiziert haben, der zu den Herausforderungen beim Betrieb und der Skalierung von API-Infrastrukturen beiträgt.
Um API-Gateways besser zu verstehen, ist es wichtig, zunächst die verschiedenen Komponenten der modernen API-Management-Infrastruktur zu untersuchen.
Abbildung 6 bietet eine umfassende visuelle Darstellung der verschiedenen Funktionen und Komponenten, die für die API-Verwaltung von wesentlicher Bedeutung sind. Neben API-Gateways, die für die Weiterleitung und Verwaltung des Datenverkehrs zu Backend-Diensten erforderlich sind, gibt es mehrere andere wichtige Infrastrukturkomponenten. Hierzu können unter anderem Lösungen zur Authentifizierung, Ratenbegrenzung, Zwischenspeicherung 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.
Lassen Sie uns die allgemein anerkannten und bekannten Funktionen von API-Gateways untersuchen:
- Routenplaner : Leitet Anfragen basierend auf dem Pfad oder Inhalt der Anfrage an den entsprechenden Backend-Dienst weiter.
- Authentifizierung und Autorisierung : Authentifiziert und autorisiert Anfragen als einzelner Eingangspunkt und stellt so sicher, dass nur autorisierte Clients auf die Back-End-Dienste zugreifen können.
- Ratenbegrenzung : Begrenzt die Rate, mit der Clients Anfragen an die zugrunde liegenden APIs stellen können, verhindert so eine Überbeanspruchung und schützt die Back-End-Dienste vor einer Überlastung.
- Zwischenspeicherung : Speichert Antworten der zugrunde liegenden APIs im Cache. Dadurch wird die Anzahl der an die Backend-Dienste zu stellenden Anfragen verringert und die Leistung verbessert.
- Protokollübersetzung : Übersetzt zwischen verschiedenen Protokollen wie HTTP und WebSockets und ermöglicht Clients so den Zugriff auf die zugrunde liegenden APIs unter Verwendung verschiedener Protokolle.
- Lastverteilung : Verteilt Anfragen an mehrere Backend-Dienste und verbessert so Skalierbarkeit und Zuverlässigkeit.
- Sicherheit: Übernimmt Sicherheitsaufgaben wie Verschlüsselung und Entschlüsselung, um eine sichere Datenübertragung zu gewährleisten.
- Analyse und Überwachung: Verfolgt und meldet Nutzungsmetriken und Fehlerinformationen, bietet Einblick in die Systemnutzung und hilft bei der Identifizierung von Leistungsengpässen und Fehlern.
- Versionierung : Verwaltet die Versionierung der zugrunde liegenden APIs und ermöglicht Clients je nach Bedarf den Zugriff auf unterschiedliche Versionen der API.
- Diensterkennung : Erkennt verfügbare Backend-Dienste und leitet Anfragen dynamisch an sie weiter. Dies ermöglicht eine dynamischere und flexiblere Diensterkennung.
Nach der Analyse der Funktionen der API-Verwaltungsinfrastruktur erkannten wir, dass wir die Rolle von API-Gateways besser verstehen und Alternativen zum aktuellen monolithischen API-Gateway-Design erkunden müssen.
Das Wachstum der Anzahl von APIs führt bereits zu einer Ausbreitung der APIs und API-Gateways, immer mehr Clients werden mobil oder stark verteilt und Computerinfrastrukturen sind überall verfügbar geworden, auch an der Peripherie. 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 außerdem die Funktionalität und den Umfang eines API-Gateways, um seine Nuancen und Einschränkungen herauszuarbeiten.
Ein API-Gateway ist eine wichtige Komponente der heutigen API-Verwaltungsinfrastruktur. Im Kern ist das API-Gateway ein Reverse-Proxy. Es fungiert als Vermittler zwischen Clients und Backend-Diensten und führt verschiedene Aufgaben für die eingehende Anfrage aus. Beispielsweise kann das Gateway eine Authentifizierung durchführen, die Rate begrenzen, Routen anfordern, Sicherheitsrichtlinien anwenden, überwachen und eine Versionierung durchführen, bevor die Anforderung an einen entsprechenden Back-End-Dienst weitergeleitet wird. Sobald der Back-End-Dienst die Anforderung verarbeitet und eine Antwort zurückgegeben hat, kann das API-Gateway Aufgaben wie Caching, Protokollübersetzung und Antwortverarbeitung ausführen, bevor es die Antwort an den Client zurückleitet.
Mit der steigenden Anzahl an APIs haben sich auch die API-Gateways weiterentwickelt und bieten nun eine Vielzahl neuer Funktionen über das grundlegende Routing hinaus, sodass sie praktisch zu monolithischen Systemen geworden sind. Diese Gateways verwalten jetzt Aufgaben wie Authentifizierung und Ratenbegrenzung, um die Leistung zu verbessern und die Belastung der Backend-Dienste zu verringern. Doch selbst mit dieser erweiterten Funktionalität bleiben API-Gateways ein einziger Zugriffspunkt zum Backend-Dienst, was in stark verteilten Umgebungen eine Herausforderung darstellen kann.
Insbesondere der Aufstieg von Cloud-, Hybrid-Multi-Cloud- und Edge-Infrastrukturen hat es schwieriger gemacht, Agilität, Sicherheit und Verwaltbarkeit mit einem API-Gateway-Ansatz aufrechtzuerhalten. Da Clients, Geräte und Anwendungs-Workloads potenziell ü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 ein breites Aufgabenspektrum bewältigen und in mehrere Systeme integriert werden müssen, sind API-Gateways in der Regel schwer bereitzustellen und zu verwalten. Obwohl die Verwaltung von API-Gateways komplex sein kann, ist sie dennoch eine wichtige Aufgabe, um die Verfügbarkeit, Sicherheit und Skalierbarkeit einer API sicherzustellen. Unternehmen verwenden in der Regel spezialisierte Tools wie API-Verwaltungsplattformen, um ihre API-Gateways effektiver verwalten und überwachen zu können.
Die folgende Liste ist nicht vollständig, aber einige der Elemente, die zur Komplexität des API-Gateways beitragen, sind:
- Konfigurationsmanagement : API-Gateways verfügen häufig über zahlreiche Konfigurationsoptionen und Einstellungen, die verwaltet und gewartet werden müssen, wie z. B. Routing-Regeln, Ratenbegrenzungen und Sicherheitseinstellungen. Die Verwaltung dieser Einstellungen kann komplex und zeitaufwändig sein, insbesondere wenn die Anzahl der zugrunde liegenden APIs und Clients wächst.
- Integration mit anderen Systemen : Die Gateways müssen in eine Vielzahl anderer Systeme integriert werden können, etwa in Authentifizierungs- und Autorisierungssysteme, Lastenausgleichsmodule und Datenbanken. Dies kann komplex sein, insbesondere wenn die zugrunde liegenden Systeme nicht gut integriert sind oder wenn das API-Gateway mehrere Protokolle oder Datenformate verarbeiten muss. Dies wird 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 sicherzustellen. Dies kann insbesondere bei der Verarbeitung einer großen Anzahl von Backend-Diensten und Clients eine komplexe Verwaltung sein.
- Sicherheit : Da es sich bei Sicherheits-API-Gateways um eine kritische API-Sicherheitskomponente handelt, müssen sie konfiguriert und verwaltet werden, um sicherzustellen, dass vertrauliche Daten geschützt und der Zugriff kontrolliert wird. Dies kann komplex sein und erfordert eine kontinuierliche Überwachung und Verwaltung.
- Versionierung : Mit der wachsenden Anzahl zugrunde liegender APIs und Clients kann es zunehmend schwieriger werden, unterschiedliche Versionen der API zu verwalten und sicherzustellen, dass die Clients auf die richtige Version zugreifen.
- Überwachung und Fehlerbehebung : API-Gateways können große Datenmengen sammeln und generieren. In einem großen Unternehmen können die Gateways über viele Standorte verteilt sein, was die Korrelation von Ereignissen, die sich auf den Gesamtzustand der Anwendung auswirken, und die Fehlerbehebung erschwert.
Ausbreitung von API-Gateways
Unter API-Gateway-Wildwuchs versteht man die Verbreitung 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 zur Handhabung dieser verschiedenen APIs führen kann. Verschiedene Teams können auch API-Gateways von verschiedenen Anbietern oder Lösungen verwenden, um unterschiedliche API-Typen zu verarbeiten.
Dies führt zur Bereitstellung mehrerer API-Gateways mit jeweils unterschiedlichen Funktionen.
Die Ausbreitung von API-Gateways bringt mehrere zusätzliche Herausforderungen mit sich:
- Skalierung der API-Gateway-Verwaltung : Das Vorhandensein mehrerer unabhängiger API-Gateways kann die Verwaltung und Wartung der Gateways erschweren, insbesondere wenn die Anzahl der zugrunde liegenden APIs und Clients wächst.
- Ineffizienzen im Ost-West-Verkehr : Mehrere Gateways können dazu führen, dass Anforderungen diese mehreren Gateways durchlaufen müssen, was zu längeren Latenzen und einer verringerten Leistung führt.
- Einheitlichkeit der Sicherheitsrichtlinien : Die Verwaltung mehrerer Gateways kann schwierig sein und zu inkonsistenten Sicherheitsrichtlinien führen. Dadurch wird es schwieriger, den Schutz vertraulicher Daten und die Zugriffskontrolle zu gewährleisten.
- Standardisierte Governance : Bei mehreren Gateways kann es schwierig sein, sicherzustellen, dass alle APIs ordnungsgemäß verwaltet werden und den Standards und Best Practices entsprechen.
- Erhöhte Kosten : Der Einsatz mehrerer Gateways kann zu höheren Kosten für Infrastruktur, Entwicklungsressourcen und Wartung führen.
- Verstärkte Integrationsherausforderungen : Das Vorhandensein mehrerer Gateways erschwert die Integration mit anderen Systemen und Technologien, beispielsweise anderen Datenbanken, Data Warehouses und Datenanalysetools.
Unternehmen sollten eine Zentralisierung ihrer API-Verwaltung und -Governance anstreben und einen einzigen API-Gateway-Typ verwenden. Dadurch werden zwar die oben genannten Herausforderungen der Ausbreitung von API-Gateways gemildert, eine vereinheitlichte Strategie für API-Gateways ist jedoch alles andere als einfach.
Herausforderungen bei der Standardisierung von API-Gateways in einem Unternehmen
Wenn Unternehmen organisch oder durch Akquisitionen wachsen, können interne Teams, die bestimmten Geschäftseinheiten (BUs) zugeordnet sind, bei der Auswahl der API-Gateway-Technologie oder des API-Gateway-Anbieters uneins sein. Hierfür können unter anderem die folgenden Gründe vorliegen:
- Technologie : Verschiedene Teams oder Geschäftseinheiten verfügen über unterschiedliche Technologie-Stacks oder bevorzugen unterschiedliche API-Gateway-Lösungen, was eine Standardisierung auf einen einzigen Gateway-Typ erschwert.
- Legacy-Systeme : Einige Teams verfügen über bestehende Systeme, die mit einem anderen Typ von API-Gateway erstellt wurden, und 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, um bestimmte Anforderungen zu erfüllen, und finden es schwierig, diese Anpassungen auf einem neuen Gateway zu replizieren.
- Wiederbeschaffungskosten : Das Ersetzen vorhandener API-Gateways durch ein neues, standardisiertes Gateway kann sowohl hinsichtlich der Entwicklung als auch der Wartung kostspielig sein.
- Schulungsentwickler : Die Teams verfügen über unterschiedliche Fachkenntnisse und müssen sich unter Umständen mit einer neuen Gateway-Technologie eines anderen Anbieters vertraut machen oder eine Schulung dazu absolvieren – ein Prozess, der sowohl zeitaufwändig als auch teuer sein kann.
- Begrenzte Ressourcen : Organisationen verfügen hinsichtlich Entwicklern, Budget und Zeit nur über begrenzte Ressourcen, um die Änderung vorzunehmen, was die Implementierung eines neuen Gateways erschwert.
- Anwendungsabhängigkeiten : Verschiedene Teams oder Geschäftseinheiten sind in unterschiedlichem Maße von ihren vorhandenen Gateways abhängig (z. B. durch die Integration in bestimmte Systeme oder andere benutzerdefinierte Integrationen), was die Umstellung auf ein neues Gateway erschwert.
- Lösungen von Drittanbietern : Teams, die in das Gateway integrierte Lösungen von Drittanbietern verwenden, werden Schwierigkeiten haben, auf eine neue Lösung zu migrieren, die diese Lösungen von Drittanbietern nicht unterstützt.
Wenn für eine vorhandene Anwendung also ein gut etabliertes und eigensinniges Team zuständig ist, wird dieses Team nicht auf ein anderes Bereitstellungsmuster umsteigen wollen, um Störungen seines Dienstes zu vermeiden.
Wir können daher den Schluss ziehen, dass ein neuer Ansatz erforderlich ist, der zahlreiche Einschränkungen der vorhandenen API-Infrastruktur berücksichtigt und gleichzeitig die Ausbreitung von API-Gateways als einen der wichtigeren Aspekte hervorhebt.
Designüberlegungen
Die folgende Liste ist nicht vollständig, sondern fasst einige der grundlegenden Designüberlegungen zusammen, die unserer Meinung nach beim Erstellen der Lösung berücksichtigt werden sollten:
- Koexistenz mit aktuellen Bereitstellungen : Da Unternehmen bestrebt sind, mit der sich ständig ändernden Technologielandschaft Schritt zu halten, ist es üblich, dass sie über eine Vielzahl unterschiedlicher API-Gateway-Bereitstellungen verfügen. Eine Aufspaltung der vorhandenen API-Infrastruktur ist nicht praktikabel, da hierdurch kritische Geschäftsabläufe gestört werden können. Daher muss jede neue Bereitstellung so konzipiert werden, dass sie mit der aktuell bereitgestellten Architektur koexistieren kann.
- Standardisieren Sie die API-Gateway-Funktionen : Das Hauptziel der API-Strategie eines Unternehmens sollte die Standardisierung der API-Gateway-Funktionalität sein, was angesichts der großen Bandbreite an APIs und der unterschiedlichen Anforderungen verschiedener Geschäftseinheiten eine anspruchsvolle Aufgabe sein kann. Dennoch ist diese Standardisierung von entscheidender Bedeutung für die Schaffung einer stabilen und sicheren Infrastruktur, die die digitale Transformation des Unternehmens unterstützen kann.
- Nutzen Sie Edge-Bereitstellungen : Die Edge-Infrastruktur verfügt nicht nur über das Potenzial, die Anzahl der APIs exponentiell zu erhöhen, sondern bietet Unternehmen auch die Möglichkeit, ihre Gateway-Akteure näher an den Rand zu verlagern. Dies ist möglich, da dieselbe Infrastruktur, die zum Erstellen von APIs verwendet wird, auch zum Erstellen verteilter Gateway-Akteure genutzt werden kann. Daher muss die Lösung die Nähe zur Edge-Infrastruktur für die Clients, die die API-Anfrage initiieren, voll ausnutzen.
- Transportunabhängig : Eine wichtige Überlegung bei der Implementierung der Architektur verteilter Gateway-Akteure besteht darin, 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 eine Messaging-Infrastruktur mit geringer Latenz nutzen möchte, muss die Lösung unabhängig vom Transportmechanismus sein. Dies ermöglicht eine größere Flexibilität und ermöglicht Unternehmen, den Transportmechanismus auszuwählen, der ihren spezifischen Bedürfnissen und Anforderungen am besten entspricht.
- GraphQL-Unterstützung : GraphQL erfreut sich aufgrund seiner zahlreichen Vorteile gegenüber herkömmlichen REST-APIs einer immer beliebteren Wahl für die API-Entwicklung. Ein wesentlicher Vorteil besteht darin, dass ein feingranularer Datenzugriff möglich ist, sodass Clients in einer einzigen Anfrage genau angeben können, welche Daten sie benötigen. Darüber hinaus kann GraphQL den Prozess der Datenaggregation aus mehreren Diensten vereinfachen und ist damit die richtige Architektur für die Zusammensetzbarkeit und Orchestrierung von Diensten. Dies kann den Netzwerk-Overhead reduzieren und die Leistung verbessern, insbesondere in einem verteilten System, in dem mehrere API-Dienste verwendet werden, um eine einzelne Anforderung zu erfüllen. Schließlich kann GraphQL mit seinem stark typisierten Schema und seiner Abfragesprache die Auffindbarkeit von APIs verbessern und eine einfachere Client-Entwicklung ermöglichen.
- Sicherheit ist ein Muss : Das wichtigste Designziel besteht darin, dass es die API-Sicherheitslage des Unternehmens ergänzt. Die Lösung könnte einige der Funktionen übernehmen, etwa die Möglichkeit zur Authentifizierung und Autorisierung von API-Anfragen, zur Implementierung von Zugriffskontrollen und zum 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 gefährden oder so erheblich verändern, dass sich die Angriffsfläche verändert. Indem Sicherheit als Designziel priorisiert wird, muss die Architektur eine sicherere Umgebung für die API-Kommunikation bieten und so das Risiko von Datenverletzungen und anderen Sicherheitsvorfällen verringern.
Aus diesen Designüberlegungen lassen sich konkrete Anforderungen ableiten, die wir in unsere Distributed Gateway Actors (DGA)-Lösung integriert haben.
Verteilte Gateway-Akteure
Nachdem wir nun API-Gateways vollständig erkundet haben, können wir die verteilte Gateway-Actor-Lösung erläutern.
Entwurf verteilter Gateway-Akteure
Das Entwurfsmuster der Distributed Gateway Actors (DGA) ist vom Edge Computing und von Computing, das in der Nähe eines Clients verfügbar ist, inspiriert. Der Kern der Idee besteht darin, jeden Gateway-Akteur so nah wie möglich am Client zu verteilen und den Gateway-Akteur nur für die Dauer der Transaktion existieren zu lassen, bevor diese am Ende gelöscht wird.
Annahmen
Hier sind einige der dieser Lösung zugrunde liegenden Annahmen.
Edge-Computing ist weiter verbreitet und wir können jetzt Computing-Typen finden, die geografisch näher am Client verfügbar sind. Die Gateway-Akteure können auf diesen Edge-Compute-Knoten instanziiert werden. Die Absicht besteht darin, eine Implementierung zu haben, bei der der DGA sehr leichtgewichtig und kurzlebig ist, sodass er auf jedem Edge-Computer 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 beinhaltet. Die Art der erforderlichen Infrastruktur hängt vom Anbieter bzw. Unternehmen ab und kann variieren. Beispielsweise kann eine große öffentliche Cloud ihr eigenes Backbone zum Ausführen des API-Transports verwenden. Eine andere Implementierung könnte ein Messaging-Bus mit geringer Latenz sein, der auf einem vorhandenen Netzwerk mit hoher Bandbreite und geringer Latenz in einem Unternehmensrechenzentrum aufgesetzt wird.
API-Gateway-Funktionen
Um es noch einmal zu wiederholen: 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 am selben Standort sind, beispielsweise in einem lokalen Netzwerk vor Ort oder in einer virtuellen privaten Cloud (VPC) innerhalb einer Verfügbarkeitszone. Doch wenn die Anzahl der APIs zunimmt, sie sich über eine hybride Infrastruktur verschieben oder einfach mobil werden, wird dieser Ansatz des API-Gateway-Designs ineffizient, komplex im Betrieb und teuer.
Auch wenn es unterschiedliche Ansichten darüber gibt, wie die in Abbildung 6 beschriebenen Funktionen zu klassifizieren sind, sind wir uns doch einig, dass die API-Verwaltungsinfrastruktur zu einer komplexen Bereitstellung vieler Komponenten geworden ist, die sorgfältig orchestriert werden müssen.
Abbildung 7 ordnet die verschiedenen Merkmale und Funktionen des API-Managements aus Abbildung 6 der Architektur der verteilten Gateway-Akteure zu. Diese Zuordnung veranschaulicht visuell, wie jedes Feature und jede Funktion auf den DGA-Ansatz abgestimmt ist, 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 darin, die Managementebene neu zu strukturieren, sondern, wenn möglich, bestimmte Funktionen zu entfernen.
Kernfunktionen des API-Gateways
Hierbei handelt es sich um Datenebenenfunktionen, die sich daher am besten in der API implementieren und mit den Anwendungsworkloads zusammenführen lassen. API-Gateways sind eine entscheidende Komponente der modernen Microservices-Architektur, die als Einstiegspunkt für den gesamten externen Datenverkehr dient. Wir haben seine Kernfunktionen wie Routing, Lastenausgleich, dynamisches Routing, Integritätsprüfung, Wiederholungsversuche und Fallbacks kategorisiert.
Ein API-Gateway leitet eingehende Anfragen an den entsprechenden Microservice weiter, verteilt den Datenverkehr auf mehrere Instanzen, unterstützt dynamisches Routing, überwacht den Zustand von Microservices und deren Instanzen, wiederholt fehlgeschlagene Anfragen und bietet Fallback-Antworten, wenn ein Microservice nicht verfügbar ist oder ausgefallen ist. Andere Funktionen wie Authentifizierung, Autorisierung, Ratenbegrenzung, Caching und Protokollierung können je nach den spezifischen Anforderungen des Systems auf die Edge- oder zentralisierten Funktionen verteilt werden.
Dieser modulare Ansatz ermöglicht eine flexiblere und optimierte Architektur und steht im Mittelpunkt unserer Empfehlung zur Vereinfachung, Modernisierung und Skalierung der Unternehmens-API-Infrastruktur.
Zusammengeführt
API-Gateway und API-Verwaltung werden von Anbietern häufig fälschlicherweise als Teil der API-Gateway-Funktion verwechselt. Tatsächlich handelt es sich jedoch um zwei unterschiedliche Funktionen, die getrennt behandelt werden sollten. Ein API-Gateway ist für die Weiterleitung von Anfragen von Clients an Back-End-Dienste verantwortlich, während die API-Verwaltung ein breiteres Spektrum an Funktionen wie Zugriffskontrolle, Ratenbegrenzung, Analyse und Verwaltung des Entwicklerportals umfasst.
Auch wenn manche 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 anhand ihrer spezifischen Anforderungen separat 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 für das Verständnis unserer Position zur Verteilung der API-Gateway-Funktionalität.
Gateway-Akteur – Inline-Funktionen
Die hier aufgeführten Features sind Kernfunktionen, die in den Datenpfad integriert sein müssen. In einem verteilten Gateway-Muster werden auch einige der Inline-Funktionen des API-Gateways verteilt. Zu diesen Funktionen gehören Zugriffskontrolle, Ratenbegrenzung, Anforderungsvalidierung, API-Analyse, Nutzungsberichte, Fehlerratenüberwachung, Warn- und Ereignisfunktionen, Authentifizierungsintegration, Drittanbieterintegration, Überwachungs- und Protokollierungsintegration, Edge-Caching und Komprimierung.
Das Verschieben dieser Funktionen in das verteilte Gateway-Muster bietet die folgenden Vorteile:
- Reduzierte Belastung des API-Gateways : Helfen Sie, die Belastung des zentralen API-Gateways zu reduzieren und die Leistung und Skalierbarkeit des Systems zu verbessern.
- Ermöglichen Sie schnellere Reaktionszeiten : Ermöglichen Sie schnellere Reaktionszeiten und geringere Latenzzeiten, indem Sie diese Funktionen näher an den Clients bereitstellen. Durch die Nutzung der Zwischenspeicherung der Daten und der Funktion können die am Edge gehosteten API-Gateways schnell auf eingehende Anfragen reagieren.
Beispielsweise können Zugriffskontrolle, Ratenbegrenzung und Anforderungsvalidierung von einem Edge-Gateway-Akteur übernommen werden, der näher an den Clients bereitgestellt wird. Dies kann dazu beitragen, die Anzahl der Anfragen zu reduzieren, die vom zentralen API-Gateway verarbeitet werden müssen, und so dessen Leistung und Skalierbarkeit zu verbessern. Ebenso können API-Analysen, Nutzungsberichte, Fehlerratenüberwachung, Warn- und Ereignismeldungen sowie die Überwachungs- und Protokollierungsintegration durch Edge-Gateways gehandhabt werden, die Daten von mehreren Mikrodiensten erfassen und aggregieren können.
Gateway-Akteure – GraphQL-Kandidaten
Heutzutage ist die Servicekomposition und -orchestrierung eine wichtige Funktion, die API-Gateways unterstützen. Dies kann zwar ziemlich komplex werden, es wäre jedoch problematisch, wenn diese Funktion nicht vom vereinfachten API-Gateway unterstützt würde. Wir glauben, dass GraphQL ein interessanter Ansatz zur Servicezusammenstellung sein kann und als eine Art Middleware für vorhandene APIs fungiert.
Aufgrund der Sichtbarkeit aller APIs wird das API-Gateway zu einem logischen Ort für die Durchführung der Servicekomposition. 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 Servicekompositionsschicht kombiniert werden können.
Die Servicekomposition in GraphQL wird durch die Verwendung eines stark typisierten Schemas ermöglicht, das die Form der für Clients verfügbaren Daten definiert. Clients können dieses Schema verwenden, um Abfragen zu erstellen, die genau die Daten angeben, die sie benötigen, unabhängig davon, welche Dienste oder Quellen diese bereitstellen. Resolver sind Funktionen, die Abfragen Datenquellen zuordnen. Sie werden verwendet, um Daten vom entsprechenden Dienst oder der entsprechenden Quelle abzurufen. Obwohl GraphQL eine bessere Sicherheit verspricht, ist es jedoch nur so gut wie der Entwickler, der den Code schreibt.
Weitere Merkmale und Funktionen
Es gibt noch einige verbleibende Funktionen, die in Abbildung 6 nicht hervorgehoben sind: API-Verwaltung und Infrastrukturfunktionen . Diese verbleibenden Features und Funktionen sind Kandidaten, die in einzelne Verwaltungs- und Betriebs- oder Datenebenenfunktionen verschoben werden können.
Wir verwenden bewusst den Begriff „Akteur“, um nicht den Eindruck einer bestimmten Implementierung oder Anbietertechnologie zu erwecken. Die Implementierung des Gateway-Akteurs könnte auf Methoden, Funktionen, Workern, Threads und Prozessen basieren, die mithilfe von Infrastrukturen auf Basis von VMs, Containern, Serverless oder anderen anbieterspezifischen Ansätzen implementiert werden.
Funktionen und Verhalten der Komponente
Der mit der DGA-Architektur (Distributed Gateway Actors) gewählte Ansatz vereinfacht die API-Gateway-Funktionen und verschiebt andere Inline-Funktionen entweder an den Rand oder auf die Steuerebene.
Steuerebene
Abgesehen von den API-Gateway-Funktionen empfiehlt die DGA-Architektur auch, Funktionen zu identifizieren, die besser in der Steuerebene als logisch zentralisierte Komponente bereitgestellt werden könnten, anstatt in einem monolithischen API-Gateway implementiert zu werden. Die Verwaltung und Steuerung der bereits vorhandenen API-Infrastruktur kann um diese zusätzliche Funktionalität erweitert und ausgebaut werden.
Vereinfachtes API-Gateway
Die Vereinfachung des API-Gateways wird somit zu einer Übung, um 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 die vorhandenen Bereitstellungen zu stören und ohne dass ein Forklift-Vorgang erforderlich wäre.
Verteilte Gateway-Akteure
Ein wichtiger Aspekt des DGA besteht darin, dass jeder Gateway-Akteur flüchtig ist und nur für die Dauer einer API-Sitzung instanziiert wird (d. h. ein Client tätigt einen API-Aufruf).
Ein verteilter Gateway-Akteur kann flexibler, skalierbarer und kostengünstiger sein als das herkömmliche API-Gateway. Anstatt sich bei der Aggregation und Verarbeitung des API-Verkehrs auf mehrere monolithische API-Gateways verschiedener Anbieter zu verlassen, ermöglicht der Gateway-Akteur Entwicklern, individuelle Gateway-Instanzen für jede API näher am Rand des Netzwerks anzugeben und bereitzustellen. Die APIs selbst könnten eine bessere Kontrolle und Anpassung an Ihre spezifischen Anforderungen bieten.
Dieser neue Ansatz ermöglicht außerdem eine größere Skalierbarkeit, da Entwickler die Gateway-Actor-Instanzen ganz einfach nach Bedarf hochfahren können, um den erhöhten Datenverkehr zu bewältigen, ohne sich um den Verwaltungsaufwand eines großen, zentralisierten Gateways kümmern zu müssen.
Neben seinen technischen Vorteilen bietet der Gateway-Actor auch Kosteneinsparungen im Vergleich zum herkömmlichen API-Gateway, da Unternehmen nur für die flüchtigen Gateway-Actor-Instanzen zahlen, die sie nutzen. Dieses Bereitstellungsmodell kann Möglichkeiten für zusätzliche Umsatzmodelle eröffnen.
Gateway-Schauspielerplatzierung
Durch die Nutzung einer API-Transportschicht entkoppeln die DGAs im Wesentlichen den API-Eintrittsort vom API-Gateway. Die DGAs können an den Rand verschoben werden, d. h. näher an den Client, der den API-Aufruf tätigt. Die APIs können in den DGAs enden und dann auf beliebige Weise transportiert werden. Dies unterscheidet sich von Abbildung 3: Legacy-API-Gateway-Architekturen , bei denen der Client-Verkehr topologisch neben den API-Gateways eintritt.
Abschluss
Unsere Absicht war es daher, einen anbieter- und einsatzunabhängigen Ansatz vorzuschlagen, da verschiedene Anbieter über ihr eigenes geistiges Eigentum verfügen können, um diese Komponenten zu erstellen und so ähnliche Ziele wie beschrieben zu erreichen.
In diesem Dokument haben wir unsere Erkenntnisse aus mehreren Bereichen der Erforschung von API-Wildwuchs , Edge 2.0 -Architekturen, der API-Ökonomie und Untersuchungen zu GraphQL zusammengefasst. Obwohl in Bezug auf die veraltete API-Infrastruktur noch ein Urteil gefällt werden muss, glauben wir, dass ein neuer Ansatz erforderlich ist.
Allein die Aussicht, weltweit in jedem einzelnen Gerät oder jeder Entität Mehrwert zu schaffen, ist Grund genug, einen neuen Ansatz zu erkunden. Wir müssen uns heute von der alten API-Infrastruktur verabschieden, denn obwohl sie verteilt aussieht, ist sie unter der Haube monolithisch.
Wir schlagen den verteilten, auf GraphQL basierenden Gateway-Actor-Ansatz als anbieterunabhängige Möglichkeit vor, das volle Potenzial der aufkommenden API-Wirtschaft auszuschöpfen.