Was ist ein föderiertes Gateway?

In zentralisierten Systemen bearbeitet ein einziges Gateway (das selbst mit mehreren APIs verbunden und für deren Verwaltung zuständig ist) alle Client-Anfragen. Bei der Gateway-Föderation hingegen kann ein Unternehmen ein verteiltes Netzwerk von API Gateways verwenden, von denen jedes für seine eigenen Dienste zuständig ist.

In einem föderierten Gateway-System können Teams bedarfsgerecht Dienste hinzufügen, ohne das gesamte System zu beeinträchtigen. Dies ermöglicht eine effiziente Ressourcennutzung und Verkehrsverwaltung. Zudem können verschiedene Abteilungen unterschiedliche Protokolle zur Verwaltung ihrer jeweiligen Gateways verwenden. Das Framework gibt den Teams den Spielraum für die Verwaltung ihrer eigenen APIs und verbessert so die Flexibilität, die betriebliche Ausfallsicherheit und mehr.

Dieser Ansatz hilft auch bei der Vermeidung von Traffic-Engpässen und anderen Problemen, die mit zentralisierten API-Gateways verbunden sind, und kann durch die Bereitstellung von Gateway-Funktionen näher am Endbenutzer zu Leistungsvorteilen führen. Gateway-Föderationsstrategien können auf verschiedene API-Architekturen und Protokolle angewandt werden, darunter REST, gRPC und SOAP, die jeweils ihre eigenen Vor- und Nachteile haben.

Aus der IT-Perspektive ist ein föderiertes Gateway von Vorteil, da DevOps-Teams so ihre eigenen APIs entwickeln und bereitstellen können, während sie gleichzeitig die unternehmensweite API-Plattformverwaltung, Governance und Sicherheitsrichtlinien beachten. Die Teams können schnell und unabhängig Projekte in ihrem Bereich abschließen (was die Innovation fördert und die Markteinführung beschleunigt) und gleichzeitig unternehmensweite Standards beibehalten. So entsteht ein Gleichgewicht zwischen der Autonomie der Teams und einer zentralen Aufsicht.

GraphQL Federation ist ein alternatives Konzept und ein architektonischer Ansatz, mit dem eine einheitliche GraphQL-API erstellt wird. Es basiert auf GraphQL, einer Abfragesprache, die Ressourcen von mehreren Diensten mit einer einzigen API-Abfrage präzise ansprechen kann.

Die GraphQL-Föderation verbindet verschiedene Dienste (so genannte Subgraphen) – jeder mit seinem eigenen Schema, das die von ihm verwalteten Daten definiert – zu einem einheitlichen Schema, dem so genannten Supergraphen. Ein einziges Gateway macht dieses Supergraph-Schema für Client-Anwendungen zugänglich, vereint mehrere zugrunde liegende Dienste und Felder und leitet alle API-Anfragen weiter. Im Gegensatz dazu verbindet eine Gateway-Föderation mehrere API-Gateways über eine zentrale Steuerungsebene, wobei jedes Gateway seine eigenen Abfragen durchführt.

Federation ist ein allgemeiner Ansatz zur Systemverwaltung, der autonome Komponenten über eine gemeinsame Steuerungsebene verbindet.

In einem zentralisierten Gateway-System fließen alle Clientanforderungen über ein einziges Gateway, das Funktionen wie Routing, Authentifizierung, Autorisierung und Überwachung verwaltet. Im Gegensatz zu föderierten Architekturen werden diese Aufgaben nicht auf mehrere Instanzen verteilt.

Dieser Ansatz kann die Protokollierung, die Verwaltung des Traffics, die Durchsetzung der Sicherheit und andere Aufgaben optimieren, da jeder dieser Prozesse über das Gateway läuft. Unternehmen können außerdem Rollouts von einem einzigen Punkt aus initiieren, wodurch die Notwendigkeit entfällt, Updates über mehrere Gateways und Dienste hinweg zu versionieren.

Bei Unternehmen mit zentralisierten Frameworks ist es jedoch wahrscheinlicher, dass sie auf Engpässe stoßen, insbesondere wenn sie ihren Betrieb ausbauen. Als einziger Passthrough-Punkt des Systems kann das Gateway leicht überlastet werden. Darüber hinaus stellt es einen Single Point of Failure dar. Tritt ein Fehler auf, wirkt sich dieser auf das gesamte System aus.

Im Gegensatz zu zentralisierten Systemen bestehen föderierte Gateway-Architekturen aus mehreren Gateways, die jeweils für einen bestimmten Satz von Diensten und zugehörigen APIs verantwortlich sind. Die Gateways funktionieren unabhängig, werden jedoch jeweils von einer zentralen Steuerebene verwaltet.

Im Vergleich zu zentralisierten Frameworks fördern föderierte Systeme Flexibilität und Autonomie, indem sie Entwicklungsteams ein höheres Maß an Kontrolle über ihre jeweiligen Bereiche geben. Dieses dezentrale Layout macht auch föderierte Systeme widerstandsfähiger gegen Ausfälle und Systemausfälle.

Verbundsysteme sind jedoch operativ komplexer und können zu Governance-Unterschiede und Missverständnissen zwischen den Teams führen. Rollouts können länger dauern und die Wartung kann kostspieliger sein, da jedes Gateway separat verwaltet und aktualisiert werden muss.

Es gibt mehrere Gründe, warum sich ein Unternehmen für ein föderiertes Gateway-System entscheiden könnte.

Zum einen wird die Gateway-Föderation häufig bei Fusionen und Übernahmen eingesetzt, bei denen ein Unternehmen unterschiedliche Stacks und API-Management-Systeme von den akquirierten Unternehmen übernimmt. Anstatt mehrere separate Architekturen – jede mit unterschiedlichen Sicherheitsprotokollen, technischen Standards und Governance-Strukturen – einzeln zu verwalten oder zu versuchen, erworbene Systeme mit vorhandenen Unternehmensystemen nachzurüsten, greifen Unternehmen auf die Gateway-Föderation zurück. Dieser Ansatz ermöglicht es Unternehmen, bestehende API-Gateways und die ihnen zugrunde liegenden Systeme in die von der zentralen Steuerungsebene bereitgestellte übergeordnete Struktur zu integrieren.

Ebenso werden in Umgebungen mit vielen Microservices, die von verschiedenen Teams entwickelt und über verschiedene Umgebungen verteilt sind, oft mehrere Gateways verwendet. Ein Unternehmen könnte sich auch aufgrund von Leistungsvorteilen für ein verbundenes System entscheiden.

Stellen Sie sich beispielsweise ein Logistikunternehmen mit mehreren Niederlassungen auf der ganzen Welt vor, die jeweils eine bestimmte Region bedienen. Indem Gateways, Server, Dienste und andere Ressourcen näher an den auf sie zugreifenden Clients platziert werden, kann das Unternehmen die Optimierung von Latenz- und damit verbundene Leistungsfaktoren durchführen.

Beim Gateway-Verbund übernimmt die zentrale Kontrollebene die Verwaltung, Überwachung und Steuerung, ist aber für Clients in der Regel nicht zugänglich. API-Nutzer interagieren direkt mit den Gateways, aus denen das Verbundsystem besteht (sie fragen den Endgerät ab, der für die entsprechenden Dienste verantwortlich ist), fragen aber nicht die Kontrollebene selbst ab. Die Ebene empfängt Metadaten und Protokolle erst, nachdem bereits ein API-Aufruf erfolgt ist.

Dieser Ansatz kann zwar zu einer gewissen operativen Komplexität führen, fördert aber auch die Unabhängigkeit. So können Plattformteams beispielsweise ihre eigenen Gateways und Services nach ihren spezifischen Anforderungen konfigurieren, ihre eigenen Protokolle auswählen und Rollouts selbst bereitstellen. Föderierte Architekturen sind außerdem widerstandsfähiger gegen Fehlkonfigurationen und Sicherheitsverletzungen, da Fehler auf das Gateway beschränkt werden, von dem sie stammen, und sich wahrscheinlich nicht auf andere Gateways im Netz ausbreiten.

Bei der GraphQL-Föderation hingegen werden die Schemata von mehreren unabhängigen Diensten (Subgraphen) zu einem einheitlichen Supergraphen-Schema zusammengefasst. Ein einziger Gateway oder Router stellt einen einzigen Einstiegspunkt für Client-Anfragen dar und bietet eine einheitliche API-Erfahrung.  

Der Router teilt Abfragen intelligent in kleinere Unteranfragen auf, ruft relevante Informationen aus mehreren Untergraphen ab und stellt sie zu einer zusammenhängenden Antwort für Clients zusammen.

Stellen Sie sich eine Gesundheitsplattform mit separaten Diensten für:

• Patienten: Verwaltung von Patientendaten, Kontaktinformationen und Krankengeschichten
  
  
• Terminplanung: Planung und Verfolgung anstehender Besuche
  
  
• Abrechnung: Umgang mit Rechnungen und Abrechnungsbenachrichtigungen

Anstatt jeden dieser Endgeräte mit einem separaten API-Aufruf abzufragen, bietet die GraphQL Federation eine einheitliche Schnittstelle, die es Kunden – in diesem Fall einer App oder einem Dashboard für Ärzte oder Patienten – ermöglicht, auf die Krankengeschichte einer Patientin zuzugreifen, ihren nächsten Termin zu identifizieren und ihre ausstehenden Salden mit einem einzigen API-Aufruf anstatt durch drei separate Anfragen zu bearbeiten.

Die GraphQL Federation bietet eine Möglichkeit zum Aufbau einer skalierbaren GraphQL-API in einer verteilten Umgebung. Das Framework ermöglicht die unabhängige Entwicklung und Bereitstellung von Services und bietet gleichzeitig ein einheitliches Frontend für Kundenanfragen. Allerdings kann die GraphQL Federation anfällig für Kosten- und Komplexitätsherausforderungen, Sicherheitslücken, Überlastungen und Redundanzen sein.

Der 2019 eingeführte Apollo-Föderation ist eine einzelne Implementierung der GraphQL Federation, die spezielle Anweisungen (wie @key oder @extends) innerhalb der GraphQL-Schemadefinitionssprache verwendet, um Beziehungen zwischen verschiedenen Typen in Teilgraphen zu definieren.

Obwohl Apollo eine gängige Lösung ist, ist es nicht die einzige verfügbare Option für GraphQL Federation. Zu den gängigen Alternativen gehören Hive, Mesh, Indigo und WunderGraph Cosmo, die jeweils unterschiedliche Anpassungsstufen bieten. 

Während im Jahr 2024 weniger als 5 % der Unternehmen GraphQL-Systeme integriert hatten, wird diese Zahl nach Angaben des Forschungsunternehmens Gartner bis 2027 voraussichtlich 30 % erreichen. Große Cloud-Provider wie Amazon Web Services (AWS) und Microsoft Azure sowie Code-Repositorys wie GitHub unterstützen auch GraphQL-APIs mit integrierten Observability- und Validierungstools.

Die GraphQL Federation bietet mehrere entscheidende Vorteile, insbesondere im Hinblick auf die Möglichkeit, den API-Zugriff für Kunden zu optimieren. Teams können ein gewisses Maß an Unabhängigkeit bewahren, indem sie ihre eigenen Teilgraphen bereitstellen, verwalten und skalieren.

Als zentralisiertes Framework ist die GraphQL Federation jedoch anfälliger für Sicherheitslücken, Überlastungsprobleme und Leistungsineffizienzen. Es ist auch an GraphQL-Schemas gebunden, während der API-Gateway-Federation mit mehreren Protokollen kompatibel ist.

Bei der Entwicklung einer API-Strategie entscheiden Unternehmen, ob sie ein GraphQL-API-Framework verwenden oder einen anderen Architekturtyp, wie REST, für ihre APIs verwenden.

Letztendlich könnten sich Unternehmen dafür entscheiden, sowohl die GraphQL Federation als auch andere Architekturtypen in ihre Systeme zu integrieren, wobei jeder für die Abwicklung unterschiedlicher Funktionen zuständig ist. In einer gängigen Konfiguration verwendet ein Unternehmen GraphQL intern (mit strengen Leitplanken, um Sicherheits-, Kosten- oder Komplexitätsprobleme zu minimieren) und verwendet einen anderen Architekturstil wie REST (der ein höheres Maß an Kontrolle und einfachere Übernahme bieten kann) für externe APIs. In diesem Szenario könnte auch ein föderiertes API-Gateway verwendet werden, um diese verteilten Architekturstile über die zentrale Steuerungsebene zu vereinheitlichen.

In Standard-API-Gateway-Konfigurationen verarbeitet ein einziges Gateway den gesamten Benutzerdatenverkehr, das Routing und die Analysen. Während dieser Ansatz zur Rationalisierung einfacherer Einrichtungen beiträgt, kann er in komplexeren Umgebungen schnell zu Engpässen führen.

Föderierte Gateways basieren nicht nur auf einem einzigen API-Gateway, sondern auf einer ganzen Reihe davon. Jedes Gateway wird zum Verwalten von API-Aufrufen an einen bestimmten Satz von Diensten verwendet und die Gateways sind mit der Steuerebene verbunden, die für die Verwaltung und Governance zuständig ist.

Service Meshes werden unterdessen als Ost-West-Konfigurationen betrachtet, weil sie Verbindungen zwischen Microservices verwalten, aber nicht mit den Benutzern selbst kommunizieren. Service Meshes erleichtern in erster Linie die Kommunikation und Observability innerhalb einer einzelnen Umgebung oder eines Clusters. Varianten, die als Hybrid Cloud Meshes bezeichnet werden, sind jedoch für die Ausführung von Funktionen wie Verschlüsselung, Lastausgleich und Authentifizierung über mehrere Cluster und Umgebungen hinweg optimiert (einschließlich Multicloud-, Hybrid Cloud- und On-Premises-Umgebungen). 

Unternehmen können verschiedene Strategien anwenden, um die Vorteile der verteilten Architektur eines föderierten Gateways zu nutzen und gleichzeitig einige der mit föderierten Systemen verbundenen betrieblichen Komplexitäten und Wartungskosten zu reduzieren. Diese Verfahren helfen bei der Erhaltung der Autonomie der Teams und sorgen gleichzeitig für offene Kommunikationswege und eine einheitliche Aufsicht zwischen den Teams.

Unternehmen sollten klare Unterscheidungen zwischen den Teams treffen, um Unklarheiten darüber zu beseitigen, welche Dienste jedes Team aufbauen und pflegen soll. Diese Praxis fördert die Verantwortlichkeit und schützt die Teams davor, die Arbeit ihrer Kollegen versehentlich zu duplizieren oder falsch zu konfigurieren. Darüber hinaus kann dieser Ansatz die Produktivität steigern, da die Teams ihre Ziele und Verantwortlichkeiten genau kennen (und die Freiheit haben, danach zu handeln).

Die inkonsistente Umsetzung von Sicherheits- und Compliance-Protokollen und -Standards über Gateways und APIs hinweg kann Sicherheits-, Rechts- und Reputationsrisiken bergen. Die Aufrechterhaltung von Standards für Protokollierung, Verschlüsselung, Authentifizierung und andere Sicherheitsimplementierungen über Gateways hinweg muss in einem verteilten System Priorität haben. Dadurch wird sichergestellt, dass die zentrale Verwaltungsebene genutzt werden kann, um effizient auf Vorfallsberichte zu reagieren, umfassende Audits durchzuführen und zukünftige Angriffe zu verhindern, unabhängig davon, von welcher Domain eine Bedrohung ausgeht.

Lücken in der Observability eines verteilten Systems können zu Sicherheitsrisiken und Leistungsproblemen führen. Es ist von entscheidender Bedeutung, dass die zentrale Verwaltungsebene die umfassende Transparenz bietet, die die Teams zur Überwachung von Systemzustand und -leistung benötigen. Diese Fähigkeit ermöglicht eine rasche Behebung von Problemen sowie proaktive Verbesserungen auf der Grundlage von Sicherheits- und Leistungskennzahlen.

Einheitliche Entwicklerportale fungieren als zentrale Drehscheiben, über die Entwickler auf jede API im System zugreifen und mehr darüber erfahren können, unabhängig davon, wo sie gehostet werden oder wie sie strukturiert sind. Sie sind besonders bei föderierten Systemen wichtig, da sie Richtlinien, Dokumentationen und Codierungsbeispiele bereitstellen, um DevOps-Teams ein klares Framework für die Erstellung, Bereitstellung und Wartung ihrer APIs zu geben.

Diese universellen Standards tragen zusammen mit API-Schlüsseln und anderen Zugriffskontrollen dazu bei, dass Entwickler dem System nahtlos APIs hinzufügen und ihre eigenen Gateways verwalten können, während gleichzeitig Sicherheit und Konsistenz gewährleistet sind.

Da jedes Team mit einem gewissen Grad an Autonomie agiert, sind offene Kommunikationslinien für den Austausch von Best Practices und die Aufrechterhaltung eines nachhaltigen Netzwerks unerlässlich. Dashboards und andere Tools für die Zusammenarbeit können Teams dabei helfen, sich über gemeinsame Ziele und Verfahren abzustimmen, insbesondere wenn eine Änderung in einem Bereich Auswirkungen auf verwandte Dienste haben könnte.

Umfassende Berichtsmechanismen ermöglichen es DevOps-Teams, Latenzzeiten, Serviceunterbrechungen und andere Anomalien schnell zu erkennen und zu beheben, was zu einer reibungsloseren Benutzererfahrung beiträgt. Leistungsmetriken können auch die Skaleneffizienz verbessern, indem sie aufzeigen, welche Teile des Systems an der Kapazitätsgrenze liegen und welche nicht leistungsfähig sind.

Moderne DevOps-Ansätze wie Infrastructure-as-Code (die Verwendung von Code zur Automatisierung von IT-Prozessen, die andernfalls eine manuelle Überwachung und Bereitstellung erfordern würden) und AIOps (die Verwendung von KI zur Rationalisierung des IT-Betriebs) können den Betrieb föderierter Gateways effizienter gestalten. Techniken der Automatisierung tragen darüber hinaus zu einem widerstandsfähigeren Netzwerk bei, da sie die Wahrscheinlichkeit menschlicher Fehler verringern und den IT-Teams die nötige Bandbreite für komplexere Aufgaben geben.

Der Gateway-Föderation kombiniert die Flexibilität und Anpassungsmöglichkeiten dezentraler Architekturen mit einer zentralisierten Governance-Struktur und kann gegenüber traditionellen Architekturen mehrere Vorteile bieten.

Die Föderation gibt Teams die Kontrolle über ihre eigenen Gateways und ermöglicht es ihnen, Laufzeitkonfigurationen anzupassen, Updates zu verwalten und Codierungsumgebungen so zu gestalten, dass sie den Anforderungen ihrer Kunden und Dienste am besten entsprechen. Wenn ein Team beispielsweise das Ratenlimit einer API in einem zentralisierten System anpassen möchte, müsste es eine Anfrage über den einzigen Gateway des Unternehmens stellen. Föderierte Systeme ermöglichen es den Teams, die Anpassung unabhängig und in Echtzeit vorzunehmen, ohne andere Gateways im Netzwerk zu beeinträchtigen.

Die zentrale Ebene sorgt dafür, dass mehrere Gateways trotz ihrer eigenen Konfigurationen gemeinsame Kompatibilitäts- und Sicherheitsstandards einhalten. Die Teams haben die Flexibilität, Parameter eigenständig anzupassen und profitieren gleichzeitig von der externen Kontrolle durch die Steuerungsebene.

Föderierte Ansätze haben erkannt, dass Entwicklungsteams oft die beste Vorstellung davon haben, wie sie ihre eigenen Domänen verbessern und pflegen können. Den Teams wird die Autonomie eingeräumt, ihre APIs oder Dienste anzupassen, sobald sie ein auftretendes Problem erkennen, wodurch Anpassungsfähigkeit und Agilität verbessert werden. 

Teams können sogar in verschiedenen Programmiersprachen arbeiten und dabei die Beziehung ihres Dienstes zur zentralen Steuerungsebene beibehalten. Und schließlich können Abteilungen problemlos Aktualisierungen einspielen, anstatt sich auf eine zentrale Instanz für die Genehmigung von Änderungen zu verlassen. Und das wiederum verkürzt die Zeit bis zur Markteinführung neuer Funktionen und vereinfacht Workflows.

Föderierte Systeme können eine effizientere Ressourcenbereitstellung ermöglichen, da Teams ihre eigene Leistung überwachen und Ratenbeschränkungen und Verkehrsverteilungen entsprechend anpassen können. Unternehmen können nur die Dienste und Funktionen hochskalieren, die zusätzliche Kapazitäten benötigen, indem sie Ressourcen von weniger genutzten Diensten oder Regionen auf solche mit einer höheren Nachfrage umleiten.

Da API Gateways außerdem unabhängig sind, ist es für Schwachstellen schwieriger, von einem Gateway zum anderen zu übergehen. Infolgedessen sind föderierte Systeme im Allgemeinen widerstandsfähiger gegen Angriffe und Betriebsunterbrechungen, da Ausfälle wahrscheinlich nur ein einzelnes Gateway und nicht das gesamte System betreffen.

In föderierten Systemen übernehmen einzelne DevOps-Teams den Betrieb und die Wartung ihrer eigenen Gateways. Mit weniger Verantwortlichkeiten kann sich das zentrale Team auf übergeordnete Themen konzentrieren, wie z. B. die Durchsetzung von Compliance-Vorschriften, die Erleichterung der Kommunikation zwischen den Teams und die Verbesserung der Systemarchitekturen.

Silos sind weitaus unwahrscheinlicher, da ein föderiertes Gateway die Leistung analysieren und domänenübergreifende Leitplanken durchsetzen kann. Gateway-übergreifende Metriken können einen ganzheitlicheren Überblick darüber bieten, wie sich ein bestimmter Service auf verwandte Produkte und Services auswirkt.

Dezentrale Eigentümerschaft und Flexibilität können zu verschiedenen Herausforderungen führen, insbesondere wenn es zu Störungen in der Governance oder Beobachtbarkeit kommt. Zu den Herausforderungen, die föderierte Gateways mit sich bringen, gehören:

Die Autonomie der Teams kann zwar dazu beitragen, Innovationen voranzutreiben, erhöht aber auch die architektonische Komplexität des Systems, was die Kosten für Infrastruktur und Rechenleistung in die Höhe treibt. Föderierte Systeme erfordern aufgrund ihrer dezentralen Struktur tendenziell auch mehr Wartung und Sicherheitsressourcen.

Da Metriken und Protokolle über mehrere API Gateways verteilt sind, kann es für Unternehmen schwieriger sein, ein zusammenhängendes Bild der gesamten Systemleistung zu erstellen. Datenquellen können fragmentiert und vom breiteren Netzwerk abgekoppelt werden, was die Identifizierung und Fehlerbehebung potenzieller Fehlkonfigurationen erschwert. Unternehmen können dieser Herausforderung mit starken Standardisierungsprotokollen und -prinzipien sowie mit Observability-Tools begegnen.

Während einzelne Teams nach eigenem Ermessen Aktualisierungen vornehmen können, können unternehmensweite Rollouts möglicherweise länger dauern als in zentralisierten Umgebungen. Anstatt eine einzelne zentrale Codebasis zu aktualisieren, müssen föderierte Gateways Updates auf mehrere Domänen verteilen, wobei jedes Team für die unabhängige Genehmigung und Integration dieser Änderungen verantwortlich ist.

Die Aufrechterhaltung konsistenter Konfigurationen und Richtlinien über verteilte Gateways hinweg kann eine Herausforderung darstellen. Wenn Teams Protokolle, Rollout-Zeitpläne und Datenformate übernehmen, die von den Governance-Standards des Unternehmens abweichen, können Inkompatibilitäten und Sicherheitslücken auftreten. Wenn hingegen die Standards und Governance-Richtlinien zu streng sind, laufen Unternehmen Gefahr, Experimente zu ersticken und das Tempo der Innovation zu verlangsamen. In einem föderierten System ist das Gleichgewicht entscheidend.

Wenn Unternehmen in einem föderierten System wachsen und sich weiterentwickeln, riskieren sie, neue Ineffizienzen einzuführen, wie etwa das Überangebot an APIs, wenn mehrere Teams unbeabsichtigt redundante APIs entwickeln. Wenn dieses Problem eskaliert, können Gateways unüberschaubar werden, da die zentrale Ebene Änderungen nicht mehr verfolgen kann. Dieses Problem kann durch effiziente Governance entschärft werden.