trahko - stock.adobe.com
Das API-Management an die Serverless-Architektur anpassen
Es ist wichtig zu verstehen, was mit älteren APIs passiert, wenn man zu einer Serverless-Architektur wechselt. Das API-Management muss angepasst werden.
Wenn man bereits eine stabile API-Infrastruktur aufgebaut hat, wird man nicht einfach alles umschmeißen und neu beginnen wollen. Schließlich kann der Begriff Legacy auch so gedeutet werden, dass es Dinge gibt, die bereits gut funktionieren. Aber wenn man eine Serverless-Architektur einführt, muss einiges geändert werden. Es stellt sich die Frage: Wie kann man eine bestehende API mit möglichst wenig Aufwand an eine Serverless-Architektur anpassen?
Die gute Nachricht ist: Es gibt viele Tools, die einem dabei helfen, APIs Stück für Stück zu konvertieren. Auf diese Weise lassen sich einzelne Teile der APIs überwachen und ersetzen, während man auf eine Serverless-Architektur umsteigt.
Mit dem Umstieg beginnen
Ein traditionelles API-System basiert auf Schichten. Daher verfügt man möglicherweise über ein Authentifizierungselement, das die Anmeldeinformationen zum Beispiel mit einem Active Directory (AD) abgleicht, und eine Abfrageoberfläche, die Benutzereingaben in SQL umwandelt. Möglicherweise wird auch eine Middleware verwendet, die zum Beispiel rohe HTTP-Header verarbeitet und in systemspezifische Formate konvertiert. Man kann jedes Element auf eine Serverless-Architektur überführen. Allerdings wird man eine Reihe von Tests erstellen wollen, die sicherstellen, dass die Umstellung korrekt abläuft.
API-Transitions sind perfekt geeignet für die testgetriebene Entwicklung. Zunächst sollten Sie versuchen, die unkompliziertesten APIs zu ersetzen. Diese dürften am einfachsten zu testen sein, und man bekommt auf diese Weise ein Gefühl für die API-Migration. Es ist auch wichtig sicherzustellen, dass Sie eine Änderung einfach zurücknehmen und bei Bedarf auf die alte API-Version zurückgreifen können.
Beispielsweise möchten Sie wahrscheinlich die DNS-Einträge (Domain Name System) nicht mit einer Time-to-Live (TTL) von einer Woche aktualisieren. Das würde nämlich bedeuten, dass es bis zu einer Woche dauert, eine Änderung zu aktualisieren und zurückzusetzen. Stattdessen sollten Sie die TTL für das DNS reduzieren und die Transitions beispielsweise auf fünf Minuten einstellen. Sie können auch einen API-Proxy oder Load Balancer verwenden, um den Datenverkehr nach Bedarf weiterzuleiten.
Ein gängiger Migrationsansatz besteht darin, den Datenverkehr auf eine neue API zu replizieren. Dabei sollten Sie alle Seiteneffekte, wie zum Beispiel die Belastung einer Kreditkarte, deaktivieren, damit Sie die neue API mit echten Benutzerdaten testen können. Wenn Sie identische Daten sowohl an die alte als auch die neue API senden, können Sie überprüfen, ob die Ausgabe beider APIs übereinstimmt – und Sie können die Probleme identifizieren, die der Wechsel verursachen könnte.
Der nächste Schritt ist die Verlagerung des Traffic oder A/B-Routing, das über ein API-Gateway durchgeführt werden kann. Lassen Sie das Gateway den Großteil des Datenverkehrs an die alte API senden und einen kleineren Anteil des Datenverkehrs an die neue API. Achten Sie auf ungewöhnliche Aktivitäten und auf Benutzerbeschwerden. So stellen Sie sicher, dass die neue API ohne negative Auswirkungen auf den Kunden funktioniert.
APIs versionieren
Wenn Sie öffentliche APIs haben, ist es immer eine gute Idee, diese zu versionieren. Arbeiten Sie mit einer alten SOAP API, möchten aber eine ereignisbasierte REST API anbieten, können Sie für einen bestimmten Zeitraum beide gleichzeitig anbieten, während Benutzer auf die neue API wechseln.
Die API-Versionierung beinhaltet typischerweise das Hinzufügen eines Versionspräfix zu einer URL – wie zum Beispiel mycompanyapi.com/v1/users. Entwickler können aber auch separate Endpunkte wie v1.mycompanyapi.com/users erstellen. Verschiedene Formate von API-Antworten verwenden typischerweise Suffixe wie users.json oder users.xml. Das Wichtigste ist, den Endbenutzern den Übergang mitzuteilen und sie die neuen APIs testen zu lassen. Gleichzeitig sollten Sie aber trotzdem den Zugriff auf die alten APIs gewähren, falls etwas schief geht.
Es ist außerdem wichtig, ein Monitoring Tool zu installieren. Dieses sollte alle Benutzer oder internen Anwendungen identifizieren, die noch die alten APIs verwenden. Im Allgemeinen sollten Sie diese Benachrichtigungen mindestens sechs Monate bis ein Jahr vor Abschaltung der alten API beziehen, vorausgesetzt, es gibt keine kritischen Sicherheitsprobleme.
Adapter erstellen
Offene APIs müssen nicht unbedingt geändert werden, selbst wenn sich die zugrunde liegende Architektur ändert. Sie können die API weiterhin in eine Serverless-Architektur verschieben und müssen die offene API nicht ändern, wenn sich die Implementierung ändert. Selbst wenn die API einen WebSocket freigibt, können Sie einen separaten Adapter auf einer Amazon Elastic Compute Cloud (EC2) Instanz betreiben. Sie können dies auch über den Amazon EC2 Container Service laufen lassen, indem Sie den AWS Fargate Launch Type verwenden. Dieser gibt einfach die WebSocket API frei, nutzt unter der Haube aber die neue Serverless API.
Adapter auf einer API bieten dem Anwender eine einfache Möglichkeit, auf die API in gewohnter Weise zuzugreifen. Wenn Ihre API zum Beispiel nur JSON-Ausgaben erzeugt, Ihre Benutzer aber eine SOAP-Antwort wünschen, können Sie einen speziellen SOAP-Adapter erstellen. Dieser konvertiert Anfragen im SOAP-Format in das JSON-REST-Format.
Was soll ich ausrangieren?
Es wird immer bestimmte Teile einer alten API-Architektur geben, die sich nicht richtig in Serverless-Architekturen konvertieren lassen. Das können zum Beispiel Lock Files oder lokale Dateien sein. Alles, was eine sequentielle Ordnung erfordert, zum Beispiel eine automatische ID, die mit jedem neuen Kauf um eins erhöht wird, funktioniert nicht gut mit webbasierten Datenbanken. Andererseits sind Elemente wie Single Sign-On (SSO) gut geeignet für Serverless Computing.
Wenn Ihr Authentifizierungsprozess die Arbeit blockiert, weil er nur sechsstellige Passwörter zulässt, ist es an der Zeit, diesen zu entfernen. Authentifizierung und Autorisierung sind die wichtigsten Bestandteile jeder API, können gleichzeitig aber auch das größte Hindernis sein. Caching kann helfen, aber wenn der eigentliche Prozess für die Anmeldeverifizierung ein paar Minuten dauert, dürfte Ihre API defekt sein. Sie sollten deshalb erwägen, einen alten Authentifizierungsdienst wie AD gegen ein modernes SSO-System auszutauschen. Oder Sie integrieren einen Social Media Login, mit dem sich Kunden einfach anmelden und einloggen können.
Nicht alles muss auf Serverless migriert werden
Das Wichtigste bei einer Serverless-Migration ist, dass nicht alles migriert werden muss. Wenn 90 Prozent Ihrer Anfragen darauf ausgelegt sind, ständig eine Liste von Produkten zu lesen, ist es sinnvoll, auf Serverless zu migrieren. Wenn Sie nur ein neues Produkt pro Monat anlegen, macht es keinen Sinn, auf Serverless umzustellen. Implementieren Sie stattdessen eine Backend-SQL-Datenbank. Diese sollte dann Änderungen an Amazon DynamoDB in einem Format synchronisieren, das die Serverless-API lesen, aber auf das die API nicht schreiben kann.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
