Mit der richtigen API Management Architektur in die Cloud

Autor: Christian Sanabria

Bei vielen Unternehmen werden mit Hilfe von ipt aktuell Cloud Architekturen erarbeitet und Umsetzungen durchgeführt. Dazu gehört auch die Implementation von API Management in solchen Umgebungen. Der nachfolgende Blog zeigt auf, warum eine verteilte Architektur auch für API Management sinnvoll ist und wie eine solche Lösung aussehen könnte.

Wie ist eine API Management Lösung aufgebaut? 

Eine API Management Lösung besteht aus drei Hauptkomponenten:

• Management-Komponente (aka Admin Portal): Zentrale für API Management, Security- und API-Policies und API-Nutzungsmetriken (Analytics).
• Gateway-Komponente (aka API Gateway): Enforcement-Point für Security- und API-Policies. Liefert API-Nutzungsmetriken an die Management-Komponente. Bezieht die Konfiguration von der Management-Komponenten.
• Engagement-Komponente (aka Developer Portal): Portal für die Interaktion mit Entwicklern, welche APIs verwenden wollen. Bezieht die Daten von der Management-Komponente.

Insbesondere an die Gateway-Komponente werden hohe Anforderungen an Sicherheit, Verfügbarkeit und Performance gelegt. Skalierung ist hier essentiell während bei der Management- und Engagement-Komponente die Anforderung im Allgemeinen tiefer sind. 

Was sind Anforderungen an eine Lösung für die Cloud?

Einer der grössten Vorteile einer Cloud Umgebung mit Containern ist die Möglichkeit, Komponenten sehr einfach zwischen Cloud Umgebungen hin-und her zu verschieben, z.B. von einer Private Cloud in eine Public Cloud auf Amazon oder Google. Ebenso kann für die Skalierung einer Komponente der Container dynamisch gestartet, aber auch wieder gestoppt werden um Lastspitzen abzufangen.

Mit diesen zwei Vorteilen sollte eine neue API Management Lösung auf jeden Fall mit einer verteilten Architektur konzipiert werden, d.h. die einzelnen Komponenten sollen unabhängig in eigenen Containern installierbar und skalierbar sein. Im Fokus steht dabei hauptsächlich die Gateway-Komponente.

Da es sich bei einer solchen Lösung um ein verteiltes System handelt, spielt hier das CAP-Theorem eine Rolle.

Je nach Anforderungen an die API Management Lösung sieht die Architektur anders aus, insbesondere bei der Kommunikation zwischen der Gateway-Komponente und der Management-Komponente.

Liegt der Fokus auf Konsistenz, dann ist synchrone Kommunikation unerlässlich, was aber zu Abstrichen bei Verfügbarkeit oder Fehlertoleranz führt. Im Gegensatz dazu muss man Einschränkungen in der Konsistenz hinnehmen, wenn man hohen Wert auf Verfügbarkeit oder Fehlertoleranz legt. 

Warum sind klassische Lösungen ungeeignet für die Cloud? 

Klassische API Management Lösungen basieren oftmals auf zentralen API Gateways im Appliance Formfaktor, bei welchen eine zusätzliche Engagement-Komponente hinzugefügt wurde. Die API Gateways vereinen in diesem Fall die Gateway- und Management-Komponente. Skalierung geschieht meistens über das Hinzufügen von neuen Appliances, wobei Konfigurationen im Master / Slave Verfahren ausgetauscht werden. Ein solches Setup ist für eine verteilte Cloud Architektur ungeeignet.

Die meisten klassischen Appliances sind zwar inzwischen als Container verfügbar und lassen sich dementsprechend in der Cloud betreiben. Da diese aber immer noch auf alten Konzept basieren, können Vorteile wie dynamische Skalierung und hohe Verteilung nicht ausgenutzt werden. 

Zusätzlich sind API Gateways in vielen Unternehmen einem manuellen und langsamen Change Prozess unterworfen, was mit den DevOps Anforderungen der Engagement-Komponente bzw. der API Entwickler nur sehr schwer vereinbar ist.

Zwar bieten die meisten API Gateways selber APIs an für die Konfiguration, aufgrund der internen Architektur und der Historie sind diese aber grösstenteils sehr komplex und nur schwer in einen agilen Deployment Prozess zu integrieren. 

Wie könnte eine Lösung für die Cloud aussehen?

In einer idealen Welt könnte eine API Management Lösung wie folgt aufgebaut sein:

• Die Management-Komponente läuft als skalierbarer Container mit einer eigenen persistenten Datenbank. Die Komponente wird nicht verteilt betrieben.
• Die Gateway-Komponente läuft als skalierbarer Container ohne Abhängigkeiten zu Umsystemen. Die Komponente kann verteilt betrieben werden. Konfigurationen werden asynchron über einen Pull-Mechanismus von der Management-Komponente geholt. Informationen über API Benutzung (z.B. für die Limit-Rates) werden asynchron über einen Push-Mechanismus an die Management-Komponente geliefert.
• Die Engagement-Komponente läuft als skalierbarer Container mit einer eigenen persistenten Datenbank. Die Komponente kann verteilt betrieben werden (z.B. für Mandantenfähigkeit). Über einen asynchronen Synchronisationsmechanismus werden die Informationen bidirektional mit der Management-Komponente abgeglichen.
   

In dieser Architektur muss nur die Gateway-Komponente hochverfügbar und vollkommen autonom funktionieren. Wie bereits erwähnt hat dies potentielle Inkonsistenzen zur Folge, z.B. bei Analytics in der Management-Komponente, aber vor allem im Durchsetzen von Rate-Limits.

Ist man auf vollständige Konsistenz angewiesen, benötigt man synchrone Schnittstellen zwischen den einzelnen Komponenten. Als Folge davon muss die vollständige API Management Plattform mit allen Subkomponenten hochverfügbar ausgelegt sein, was gerade bei Persistenz nicht immer einfach ist.  

Wie geht es jetzt weiter?

Eine Cloud Strategie ist bei vielen Unternehmen im Fokus. Es ist ‚in‘ und man erhofft sich Einsparungen bei den Kosten und bei der Time-to-Market. Mit der Transformation in die Cloud und den damit einhergehenden verteilten Architekturen mit Containern oder Microservices, insbesondere in Kombination mit DevOps, bekommen Anforderungen wie Skalierbarkeit, Flexibilität beim Deployment und Automatisierung ein hohes Gewicht. Traditionelle API Management Ansätze mit zentralen Infrastrukturen sowie Anforderungen an Security müssen dabei neu überdacht werden.