Acht Serverless-Entwurfsmuster für die Softwareentwicklung

Serverless-Anwendungstypen und -anbieter

Das erste, was zu tun ist, ist die Art der Serverless-Anwendung festzulegen, die benötigt wird. Weiter muss festgelegt werden, welcher Anbieter am besten geeignet ist, diese zu hosten.

Serverless Computing führt Codekomponenten aus, die als Microservices, Funktionen oder Lambdas bezeichnet werden. Um Verwirrung zu vermeiden, wird in diesem Beitrag durchgehend der allgemeine Begriff Funktion verwendet. Typische Serverless-Anwendungen sind entweder eine Ereignisbehandlung (Event-Handling) oder eine Web-Frontend-Applikation.

In einer Event-Handling-Anwendung lösen extern oder intern erzeugte Ereignisse eine Serverless-Funktion aus. In einer Web-Frontend-Anwendung löst ein Benutzer eine Funktion über eine Browser- oder Mobile-App-Interaktion aus. Bevor Entwickler ihre Serverless-Entwurfsmuster auswählen, sollten sie wissen, welchem Modell sie folgen.

Die Serverless-Plattform der Anwendung ist ebenfalls ein wichtiger Faktor. Während es allgemeine Regeln für den Bau von Serverless-Funktionen gibt, muss die spezifische Technik auch in das Framework des Cloud-Anbieters passen. Dies ist besonders wichtig, wenn man plant, die Orchestrierungs-Tools des Cloud-Anbieters zum Aufbau von Workflows zu verwenden.

Diese Tools sind zum Beispiel: AWS Step Functions, Microsoft Azure Logic Apps oder ähnliche Workflow-Techniken, die in der Google Cloud Platform verfügbar sind. Wenn man einen bevorzugten Cloud-Anbieter hat, sollte man prüfen, wie sich Serverless-Anwendung darauf betreiben lassen.

Entwurfsmuster für das Event-Handling

Bei ereignisgesteuerten Anwendungen hat ein Basis-Entwurfsmuster normalerweise einen einfachen Namen. Diese Art von Muster sollte davon ausgehen, dass ein einzelnes Ereignis die Serverless-Funktion auslöst, und dass entweder keine weiteren Ereignisse erzeugt werden, oder dass die Verarbeitung eines Ereignisses ein anderes selektiv auslöst.

Dieses Ereignis kann extern auftreten, von einem IoT-Sensor erzeugt werden oder auftreten, weil ein Cloud-Webservice eine zu bearbeitende Aufgabe in die Warteschlange gestellt hat, wie zum Beispiel Text-, Bild- oder Videoverarbeitung.

Eine komplexere Ereignisverarbeitung erfordert eine zustandsabhängige (stateful) Ereignisbehandlung. Das bedeutet, dass ein Mechanismus vorhanden sein muss, um den Zustand im Anwendungsdesign zu kontrollieren, ohne Serverless-Funktionen zustandsabhängig zu machen – was sie nicht sein können, da sie nicht persistent sind. Der hier verwendete spezifische Mechanismus hängt fast ausschließlich vom gewählten Cloud-Provider ab.

AWS Lambda verwendet sein Entwurfsmuster zum Beispiel für den Event Workflow. Komplexe Ereignisse müssen es vermeiden, synchrone – Call and Wait for Result – Praktiken zu verwenden. Diese sind in einem zustandsabhängigen Framework schwer zu orchestrieren. Ein allgemein nützliches Modell ist ein State-Machine-Entwurfsmuster, das in den Serverless-Funktionsumfang des jeweiligen Providers integriert ist.

Entwurfsmuster für Web-Frontends

Für das Webmodell ist das Basis-Entwurfsmuster ein Microservices- oder Services-Entwurfsmuster. Dieses Entwurfsmuster verwendet eine Funktion, um den erforderlichen Link zu einem oder mehreren verwandten HTTP-Ereignissen bereitzustellen. Die Ereignisse stellen einen gemeinsamen HTTP-Endpunkt dar.

In diesem Anwendungsfall wird die Funktion von einem API-Gateway oder Service-Broker Front-seitig gesteuert. Dabei wird die Funktion durch das HTTP-Ereignis –- get/post – aufgerufen und greift dann häufig auf einen externen Datenspeicher zu. Dieses Architekturmuster ist wie ein Storefront-Entwurfsmuster, das für Serverless angepasst ist.

Ein komplexeres Modell für die Web- und Mobile-Unterstützung ist das Webhook-Entwurfsmuster. Webhooks basieren auf einem Publishing-/Abonnment-Modell. Webhooks-Absender benachrichtigen Empfänger über Ereignisse, indem sie Anfragen mit einigen Informationen zu den Ereignissen an Empfängerendpunkte senden.

Hier ein Beispiel: Eine Anwendung, die als Abonnent (Subscriber) auftritt, möchte sich über Ereignisse eines Publisher informieren lassen. Aus diesem Grund registriert sich der Abonnent unter Angabe einer URL beim Publisher. Immer, wenn beim Publisher ein Ereignis auftritt, ruft er diese URL auf. Er benachrichtigt dann den Abonnenten und übersendet Informationen über das aktuelle Ereignis. Je nach Implementierung können Abonnenten auch angeben, dass sie nur über bestimmte Ereignisse informiert werden möchten. Dieses Entwurfsmuster funktioniert in jeder Cloud, passt die Implementierung jedoch an die Umgebung des Cloud-Anbieters an.

Zwei Architekturmuster im Zusammenhang mit Webhooks sind ebenfalls noch erwähnenswert. Eines davon ist das First-In-, First-Out- (FiFo-) Entwurfsmuster. Dieses Muster wird verwendet, wenn eine Warteschlange in dieser bestimmten Reihenfolge verarbeitet werden muss. Bestimmte Verarbeitungsreihenfolgen sind in der Regel erforderlich, wenn die Ausgabe mehrstufig und zustandsabhängig ist, wie es bei vielen Transaktionen der Fall ist.

Die andere Option ist das Request-Router-Entwurfsmuster. Dieses Muster verwendet eine Funktion, um den Input zu untersuchen und leitet ihn – abhängig von der Anforderung – an eine andere Funktion weiter. Diese Methode funktioniert nur bei asynchronen Funktionen. Sie verwendet eine Frontend-Warteschlange, um Eingaben zu speichern, die entweder nicht sofort gesendet werden können oder die Funktionsverarbeitung überfordern.

Serverless-Entwurfsmuster verwenden

Serverless-Entwurfsmuster sind zunächst nutzlos. Erst wenn man die Zielanwendung entweder als ereignisgesteuert oder als web- oder applikationsorientiert klassifiziert, entfalten die Entwurfsmuster ihr Potential. Dieser Schritt hilft auch, die am besten geeigneten Muster zu identifizieren. Ereignisgesteuerte Muster sind in den meisten Fällen entweder einfach oder zustandsabhängig, und Webmodelle sind Variationen eines Storefront-Musters.

Man sollte sich auf den Dokumentationsseiten des ausgewählten Providers informieren, und überprüfen, welche spezifischen Tools und Funktionen er anbietet, um den Betrieb der App zu unterstützen. Die Tools und Funktionen eines Serverless-Anbieters umfassen zum Beispiel Warteschlangen-Tools, Datenbankwerkzeuge und sogar API- oder ServiceBroker. Es ist sinnvoll, die Verwendung von Funktionen und Serverless Features in diese Tools zu integrieren. So kann man die Entwicklung vereinfachen und die Skalierbarkeit der resultierenden Anwendung optimieren.

Man sollte aber auch bedenken, dass alle diese Webservice-Tools etwas kosten. Wenn man Geld sparen möchte, muss man möglicherweise ein anderes Architekturmuster finden, das dieses ersetzen kann. So kann beispielsweise das Request-Router-Entwurfsmuster in einigen Situationen ein proprietäres Angebot wie die AWS Step Functions ersetzen.

Bei der Entwicklung der Anwendung ist zu beachten, dass sich Serverless-Entwurfsmuster von anderen Mustern unterscheiden, die die meisten Entwickler typischerweise in herkömmlichen Anwendungen verwenden. Entwickler sollten sich Serverless eher als eine Methode zum Laden von Cloud-Diensten vorstellen, und nicht als eine Architektur, die bestimmte Praktiken vorschreibt. Als solches kann es mit dem entsprechenden Aufwand auf nahezu jedes Softwareprojekt angewendet werden.

Da Serverless noch eine junge Technologie ist, haben verschiedene Cloud-Anbieter Plattformen dafür auf unterschiedliche Weise eingeführt. Es gibt noch kein ordentliches und etabliertes Kochbuch für Entwurfsmuster. In der Zwischenzeit sollte man die anerkannten Entwurfsmuster verwenden – und sich immer über Änderungen in der Serverless-Technologie auf dem Laufenden halten.