Christian Sanabria
Principal Architect, Director
API Management liegt im Trend, Cloud ist en vogue und Container sind ein Hype. Doch wie kombiniert man diese Konzepte erfolgreich miteinander?
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.
Eine API Management Lösung besteht aus drei Hauptkomponenten:
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.
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.
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.
In einer idealen Welt könnte eine API Management Lösung wie folgt aufgebaut sein:
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.
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.