© StonePictures/Shutterstock.com
API-Gateway oder doch nur Service-Mesh-Werkzeug?

It depends...


Große Softwaresysteme existieren in der Regel nicht allein und haben normalerweise viele Schnittstellenpartner. Die Anzahl der Partnersysteme kann dabei ganz schnell im zweistelligen Bereich liegen. Je kleiner die Services geschnitten werden – was derzeit in den Projekten tendenziell passiert –, desto höher wird naturgemäß die Anzahl der Partnersysteme, die aufgerufen werden müssen. Es etabliert sich somit ein umfangreiches Kommunikationsnetz: ein sogenanntes Service Mesh.

Dem Thema Schnittstelle kommt heute noch mehr Bedeutung zu als in der Vergangenheit, denn die Fehler aus früheren Zeiten will und darf man heute nicht noch einmal machen. Direktzugriffe in die Datenbank eines anderen Service sind heute zum Glück nicht mehr auf der Liste der Projektverantwortlichen oder der Softwarearchitekten. Stattdessen entstehen mehr und mehr Schnittstellen als APIs nach dem REST Maturity Model von Richardson [1]. Gleichzeitig steigt der Wunsch nach einem koordinierten, kontrollierten und verwalteten Zugriff auf die Schnittstellen, was in Anbetracht der steigenden Anzahl von Schnittstellen auch nicht sehr verwunderlich ist.

Die Überlegung, in einer ersten Reaktion ein API-Gateway zur Verwaltung dieser Schnittstellen zu verwenden, ist vollkommen verständlich. Doch bei genauerem Hinsehen stellt sich oft die Frage, welche Funktionen des API-Gateways genutzt werden sollen. Oft sind die Anforderungen an die Verwaltung und den Betrieb der APIs geringer als der Funktionsumfang, den API-Gateways bieten. Auf der anderen Seite sollte man zur Verwaltung des Service Mesh über den Einsatz eines geeigneten Werkzeugs nachdenken. Ab einer bestimmten Größe des Service Mesh oder einer gewissen Komplexität des Kommunikationsverhaltens der Services führt kein Weg mehr daran vorbei. Istio wäre hier ein Vertreter der Service-Mesh-Werkzeuge, die sich auf den Betrieb auf einer Cloud-Plattform spezialisiert haben.

Der Trend zur Betriebsführung der Services in der Cloud wurde auch von den API-Gateway-Herstellern aufgegriffen. Sie verändern gerade ihre Systeme weg von monolithischen Gateways hin zu sogenannten Micro-Gateways, die mehr dem Cloud-Gedanken entsprechen.

Somit stellt sich im Grunde die Frage, ob man die Anforderungen an den Betrieb und die Verwaltung der Schnittstellen mit einem mehr oder weniger klassischen API-Gateway erfüllen will oder ob man besser gleich auf ein Service-Mesh-Werkzeug wechseln sollte. Oder ist ein Mix der beiden Werkzeuge der bessere Lösungsansatz?

Funktionsumfang klassischer API-Gateways

An dieser Stelle soll kein Produktvergleich von verschiedenen API-Gateways erfolgen, aber alle gängigen Vertreter dieser Zunft, wie zum Beispiel Google Cloud Apigee, Red Hat 3scale, MuleSoft, Kong oder WSO2 bieten i. d. R. nachfolgende Funktionalitäten an.

API-Applikationen: Hierunter versteht man das logische Gruppieren verschiedener APIs zu einer gemeinsamen Applikation, die dann als Gesamtheit administriert und betrieben werden kann.

Rate Limiting und Throttling: Damit wird festgelegt, wie viele API-Aufrufe innerhalb eines gewissen Zeitintervalls erfolgen dürfen. Beim Überschreiten dieses Limits wird der Aufruf mit einer Fehlermeldung abgewiesen. In den meisten Fällen wird ein HTTP-Statuscode 429 („Too Many Requests“) an den Aufrufer gesendet. Die Limitierung ist technischer Natur, um das aufgerufene System nicht zu überlasten. Das Throttling passiert dadurch, dass in dem vorgegebenen Zeitintervall nach Überschreitung des Limits keine Requests mehr zugelassen werden. Erst nach Ablauf dieses Intervalls sind weitere Requests wieder zugelassen.

API Quota: Sie betrachtet eher den kaufmännischen Aspekt eines API-Zugriffs. In der Regel wird hier das Aufruflimit für einen längeren Zeitraum vereinbart als beim Rate Limiting. Man legt beispielsweise fest, dass das API pro Monat nur tausendmal aufgerufen werden darf. Außerdem wird diese Limitierung pro Aufrufer getrennt festgelegt und führt dann oft auch zur Möglichkeit der getrennten Abrechnung von Aufrufkosten pro Konsument (Billing). Manche API-Gateways erlauben es, diese Quotas auf API-Applikationen zu definieren.

Load Balancing mit Failover: Da jeder Request auf ein API durch das API-Gateway geleitet wird, sind diese somit auch in der Lage, ein mehr oder weniger umfangreiches Load Balancing mit integriertem Failover anzubieten. Dabei sollte genau analysiert werden, ob das API-Gateway in der Lage ist, dynamisch auf Änderungen in der Laufzeitverfügbarkeit der Services zu reagieren, oder ob es nur eine statische Konfiguration der vorhandenen API Endpoints ermöglicht.

Access Control: Kein produktives System kommt heute mehr ohne Security und Access Control aus. Klar, dass API-Gateways das auch anbieten. Für verschiedene API Applications können unterschiedliche Securityeinstellungen definiert werden, um die Zugriffsmöglichkeiten der verschiedenen Nutzergruppen auf die APIs zu regeln. Eine Anbindung an gängige OAuth- oder OpenID-Connect-Server ist mittlerweile State of the Art. Auch das Setzen oder Manipulieren des HTTP-Headers gehört hierbei zur Grundausstattung der Gateways.

Logging: Jeder Request, der durch die Gateways gesteuert wird, muss natürlich auch protokolliert werden. Logging mit höherem oder niedrigerem Detaillierungsgrad ist in jedem API-Gateway möglich.

Management GUI: Zur Verwaltung der APIs bieten die gängigen API-Gateways alle eine grafische Oberfläche an. Eine technische Schnittstelle für eine automatisierte Konfiguration der APIs ist jedoch nicht in jedem der API-Gateways vorhanden. Ein Deployment von neuen oder geänderten...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang