Serverless Computing, Teil 1: Theorie und Praxis
Seite 3: Komposition versus Orchestrierung
Das Beispiel verdeutlicht, dass die Ablaufsteuerung der Anwendung nicht explizit durch eine zentrale Stelle gesteuert wird, sondern sich implizit durch die ausgelösten Events und die zugehörigen Event-Listener, also die für das Event registrierten Funktionen, ergibt. Es findet demnach eine dynamische, selbstorganisierte Komposition und keine statische Orchestrierung statt. Der Vorteil einer solchen eventgetriebenen Architektur liegt darin, dass sich durch die starke Entkopplung der einzelnen fachlichen Komponenten neue Business-Logik einfach hinzufügen und bestehende Business-Logik problemlos ändern lässt. Als Schnittstelle dient das Event beziehungsweise dessen Payload. Solange diese stabil oder abwärtskompatibel bleibt, lassen sich die einzelnen Funktionen unabhängig voneinander ändern.
Problematisch wird es immer dann, wenn sich ein Event im Aufbau so ändert, dass die Funktionen es nicht mehr verarbeiten können. Das betrifft weniger die durch die Cloud-Komponenten ausgelösten Standard-Events als vielmehr die selbstdefinierten Custom-Events, wie das gezeigte zur Signalisierung, dass ein neues Bild im Image-Manipulation-Service abgelegt wurde.
Im vorliegenden Beispiel ist es noch einfach, den Überblick über die verwendeten Events und deren zugeordneten Funktionen zu behalten. In einem deutlich komplexeren Szenario dagegen stellt das eine nicht zu unterschätzende Herausforderung dar. Das ist aber weniger ein Problem des Serverless-Ansatzes als vielmehr eine allgemeine Herausforderung ereignisgetriebener Architekturen.
Das Tor zur Cloud: API Gateway
Im Beispiel wird stillschweigend davon ausgegangen, dass die erste Serverless-Funktion uploadImageToCloud durch einen RESTFul API Call des Clients ausgelöst wird. Wer allerdings einen Blick auf die Methodensignatur des ersten Quellcodebeispiels wirft, findet dort nichts, was auf eine RESTful-Schnittstelle hinweist. Wie kommt es also zur Verbindung zwischen Client und Funktion?
Beim Anlegen der Serverless-Funktion lässt sich ein Trigger für diese definieren. Er kann zum Beispiel das Anlegen, Ändern oder Löschen eines Objekts in der Dateiablage, ein neuer Eintrag im Cloud-Log oder ein selbstdefiniertes Custom-Event sein. Zusätzlich besteht die Möglichkeit, einen HTTP-Aufruf eines API Gateways – im Beispiel handelt es sich um das AWS API Gateway – als Trigger zu verwenden. Es übernimmt dabei die Aufgabe, den RESTful Call des Clients entgegenzunehmen und gemäß vorgegebener Konfiguration in ein FaaS-konformes Event beziehungsweise einen entsprechenden Request zu transformieren. Gleiches gilt für die umgekehrte Richtung und somit für eine mögliche Response der Funktion. Das Gateway fungiert dabei als eine Art Schleuse zwischen Client und Cloud-Backend und garantiert so eine starke Entkopplung beider Welten. Die Schnittstellen der Funktionen lassen sich ändern, ohne dass Anpassungen an den Clients durchzuführen sind. Sogar ein Austausch von Funktionen ist so möglich.
Neben der beschriebenen Transformation kann ein API Gateway noch weitere wichtige Aufgaben übernehmen, wodurch seine Verwendung zu einem wichtigen Design Pattern für Cloud-Anwendungen wird. Zum Beispiel können innerhalb des Gateways zentrale Security-Checks (Authorization, Authentication, DDoS & Injection) stattfinden. Auch ein Test auf API-Schlüssel und ein damit verbundenes Limitieren von Zugriffen auf die Services und Funktionen im Cloud-Backend ist möglich. Weiterhin bietet sich die Umsetzung nichtfunktionaler Aspekte wie Logging oder Response-Chaching an. Es kann durchaus auch sinnvoll sein, das API Gateway zur Aggregation von Ergebnissen mehrerer Services und Funktionen des Cloud-Backends zu nutzen, um so teure Client-Server-Roundtrips über das langsamere LAN einzusparen (s. Abb. 5).
