Dabei ist nicht außer acht zu lassen, dass Serverless Architecture wesentlich mehr FaaS Funktionen und BaaS Services verwendet. Die FaaS-Technologie senkt die Fehleranfälligkeit des Microservice-Modells, denn die Verantwortung für den Infrastruktur- und Skalierungs-Overhead liegt beim Plattformanbieter. Darüber hinaus bieten die meisten FaaS-Plattformen Möglichkeiten zur Funktionskomposition. Das sorgt dafür, dass die Kommunikation zwischen den einzelnen Services vereinfacht wird. Ein Beispiel ist das Open Whisk-Programmiermodell: es setzt für Kommunikations- und Koordinationsaufgaben Sequenzen und Leitungen ein.
Dennoch sorgt eine steigende Anzahl an Micro- oder Nanoservices auch für eine gesteigerte Systemkomplexität. Das wird auch in der oberen Grafik deutlich. Die “Übeltäter” sind zumeist zusammenhängende Funktionen und Abhängigkeiten. Eine Serverless Architecture erfordert mehr Aufwand und spezielle Werkzeuge. Gerade bei sich schnell entwickelnden Systemen darf der Entwickler nicht den Überblick verlieren.

Eigenschaften von Serverless Architecture

Die serverlose Architektur baut hauptsächlich auf Funktionen, die auf FaaS-Plattformen gehostet werden. Verschiedene BaaS-Dienste, wie Datenbanken, API-Gateways und Speicheroptionen, ergänzen diese Funktionen.
Zum einen kann FaaS zur Erweiterung bereits bestehender Microservices verwendet werden. Dazu “klebt” ein Code die einzelnen Services zusammen. FaaS kann auf diese Weise mehrere Dienste verbinden oder Nachrichten weiterleiten. FaaS kann auch verwendet werden, um seltene, ereignisbasierte Anwendungen effizient zu ersetzen, das wird in der Literatur häufig als “hybrides Modell” bezeichnet. Zum anderen entstehen Architekturen, die komplett auf serverlosen Funktionen aufbauen. Diese Systeme schöpfen die Vorteile von Serverless Architecture voll aus. Serverless Architecture bringt die folgenden Eigenschaften mit:

Ereignisgesteuert

FaaS ist ereignisgesteuert, deshalb ist es Serverless Architecture auch. Das ist ein großer Vorteil für Entwickler, denn so werden Ereignisse erzeugt, erkannt und konsumiert. Außerdem können Services eigenständig auf Events reagieren.

Feine Service-Granularität

Eine weitere wichtige Überlegung bei "cold starts" ist die Service Granularität. Umso mehr einzelne FaaS-Funktionen vorhanden sind, desto häufiger kommt es zu "cold starts". Hier findet sich ein Argument gegen die vorab diskutierten Vorteile von mehreren kleinen Services.

Pay what you get

Serverless Architecture rechnet, im Gegensatz zu traditionellen Cloud-Architekturen, nach tatsächlichem Nutzen ab. Die Berechnungsgrundlage besteht aus Nutzungsdauer und Speicherbelegung. Bei der Kostenoptimierung muss also jede Komponente einzeln betrachtet werden.

Asynchrone Funktionsaufrufe

Asynchrone Funktionsaufrufe sind die erste Wahl. Ansonsten besteht die Gefahr der doppelten Abrechnung. Denn anfragende Funktionen werden abgerechnet, während sie lediglich auf eine Antwort warten. Noch bedeutender ist das bei eventuellen "cold starts".

Stateless Service

Zustandslosigkeit ist ein wesentliches Merkmal von serverloser Architektur. FaaS Funktionen weisen starke Einschränkungen bei langanhaltenden Anwendungen auf. Deshalb sollten BaaS-ähnliche Datenbanken oder Netzwerkspeicher verwendet werden.

Kein zentraler Vermittler

Bei Serverless Architecture gibt es keinen zentralen Prozessvermittler. Stattdessen wird Choreografie der Orchestrierung vorgezogen. Mehr Eigenverantwortung also, auch bei den Entwicklungsteams. Dennoch müssen zusätzliche Einschränkungen aus gängigen FaaS-Anwendungen, wie Laufzeitbeschränkungen oder Speicherbegrenzung berücksichtigt werden.

Patterns bei Serverless Architecture

Da Serverless-Architecture und FaaS einige technische und konzeptionelle Herausforderungen bereithalten, empfiehlt sich die Arbeit mit Patterns, also Mustern. Im World W e Web lassen sich bereits einige Erfahrungen und Ansätze finden. Die meisten dieser Beiträge beziehen sich jedoch auf einen bestimmten Anwendungsfall. Trotzdem können sie in diesem Beitrag dabei helfen, praktische Überlegungen hervorzuheben. Bei der Anwendung von Patterns müssen neben Vorteilen auch ihre Nachteile berücksichtigt werden. Denn jede Medaille hat zwei Seiten.
In der Literatur lassen sich bisher wenige Einordnungen von Patterns finden. Taibi et al. schlagen die folgende Unterteilung vor:
“Orchestration and Aggregation”
“Event Management”
“Availability”
“Communication”
“Authorization”

Nachfolgend werden nun einige Patterns beispielhaft erläutert.

Warmhalter

Wie bereits erwähnt, ist das Kaltstartverhalten ein wichtiger Aspekt bei Serverless Architecture. FaaS Plattformen verwerfen die Laufzeitumgebung ungenutzter Funktionen, damit sie Ressourcen besser auszunutzen können. Dabei passiert es jedoch nicht selten, dass sie “cold starts” auslösen. Der Funktionswärmer bzw. “function warmer” verhindert das, indem er regelmäßig gewünschte Funktionen auslöst. So werden die Services nicht unbrauchbar.
Das verhindert “cold starts” zwar, aber jeder Aufruf des “function warmers” verursacht Kosten. Dieses Muster wird auch als “funktion pinging” bezeichnet. Die folgende Abbildung stellt eine solche Implementierung bildlich dar. Dabei hält der “Cronjob” die Funktionen warm. Wie bei einem Lagerfeuer, das nicht erlöschen darf.

Übergroße Funktionen

Auch das Vergrößern von Funktionen ist ein Muster. Die meisten FaaS-Plattformen nehmen eine lineare Zuweisung der CPU-Leistung vor. Diese orientiert sich in der Regel an der Speicherkonfiguration. Sollte die physische Rechenleistung einmal nicht ausreichen, gibt es nur eine Möglichkeit mehr CPU-Leistung zu erhalten: die Speicherkapazität erhöhen. Selbst, wenn der Speicherplatz ausreicht, stellt diese Vorgehensweise die einzige Möglichkeit dar, die Verarbeitung zu beschleunigen.
Die Kosten für Serverless Architecture hängen maßgeblich von der Ausführungsdauer und dem genutzten Speicher ab. Die richtige Balance zwischen Speicher und Leistung ist also wichtig, um die Gesamtkosten überschaubar zu halten.

Router

Ein eigenes API-Gateway ist unter Umständen schwer zu konfigurieren. Eine leichtere Alternative bietet die Erstellung einer speziellen Funktion. Diese sollte Anfragen empfangen und sie, basierend auf der Nutzlast und unter Verwendung von Kompositionstechniken, weiterleiten. Das vereinfacht die exponierte Schnittstelle. Auch dabei kommt es jedoch zu einer doppelten Abrechnung, denn die Routing-Funktion ist so lange aktiv, bis die Zielfunktion einsetzt.

Aggregator

Das Aggregator-Pattern funktioniert ganz ähnlich wie das Router-Pattern, jedoch kann es eher als Erweiterung betrachtet werden. Das Aggregator-Muster ruft jede Funktion einzeln auf und gibt eine einzige Antwort an den Auftraggeber. Anstatt mehrere Ergebnisse zu teilen, wird nur die Aggregator-Funktion bereitgestellt.
Auch in diesem Fall erfolgt eine doppelte Abrechnung, denn der Aggregator stellt den Single Point of Failure dar.

Funktionskette

Kompositionstechniken werden verwendet, um die Plattform-Timeout-Schwelle zu umgehen. In der Praxis erfolgt häufig eine Aufteilung der Funktionen. Das dient dazu, die von der FaaS-Plattform definierte maximale Ausführungsdauer zu verlängern. Bei der Funktionskette übergibt die erste Funktion den Anfangsparameter und das vorläufige Ergebnis an die Nächste. Das wiederholt sich, bis die letzte Funktion beendet ist. Bei diesem Muster findet eine starke Kopplung zwischen den Funktionen statt, das führt zu einer erhöhten Komplexität.

Fan-Out und Fan-In

Auch das Fan-Out- und Fan-In-Pattern erweitert den Schwellenwert für die Ausführungsdauer. Dieses Pattern teilt die Arbeitslast in mehrere Prozesse, anstatt sequenzielle Funktionsaufrufe auszuführen. Die hohe Skalierbarkeit von FaaS bietet hier einen entscheidenden Vorteil: das parallele Aufrufen von Funktionen. Um die einzelnen Ergebnisse zu sammeln, empfiehlt sich die Verwendung eines Speicherdienstes. Dabei sollte eine weitere Funktion die Konsolidierung anstoßen.
Ein Vorzug des Patterns ist die Reduzierung der Rechenzeit und die Vermeidung der doppelten Abrechnung. Das Fan-Out-/Fan-In-Pattern nutzt die Parallelität aus, deshalb beschränkt sich die Anwendung auf parallelisierbare Arbeitslasten.

Externalisierung

Das Externalisierungs-Muster verwendet externe Speicherdienste. Ein Beispiel ist Redis als Key-Value-Store, um den Zustand funktionsübergreifend zu speichern und zu nutzen. Dieses Pattern wird häufig verwendet, die Entwickler müssen sich jedoch bewusst sein, dass es zu einem latenten Overhead und einer hohen Kopplung kommt.

Caching

Ein Cache überwindet nachgelagerte Einschränkungen und die daraus resultierende Latenz. Dieses Pattern konzentriert sich also auf leselastige Aufgaben und vereinfacht sie durch die Aufnahme im Zwischenspeicher. Hinsichtlich der Datenspeicherung gibt es zwei wesentliche Ansichten:
Materialisierte Sichtweisen häufig verwendeter Daten in Datenbanken erstellen.
Häufige Antworten, die mit einer Funktionseingabe verknüpft sind, mithilfe von BaaS-Caching-Services, wie zum Beispiel AWS Elasticache, speichern.

Das Fazit

Serverless Architecture ist für Entwickler, Architekten und Softwarebetreiber eine Möglichkeit Kosten zu senken und die Entwicklung effizienter zu gestalten. Neben den Vorteilen verbergen sich aber auch Herausforderungen: die Komplexität und der Bedarf nach einer “Überwachung” und einer besseren Visualisierung. Patterns und bereits etablierte Praktiken unterstützen die Entwickler bei Serverless Architecture. Dennoch müssen sich diese den Herausforderungen bewusst sein.
Abhilfe könnte beispielsweise das Projekt OpenWhisk Visualizer (OWVIS) schaffen. OWVIS ist ein metaphernbasiertes Visualisierungswerkzeug einer Functions-as-a-Service-Architektur. Sie wird auf Apache OpenWhisk eingesetzt, um die Komplexität zu reduzieren. OWVIS macht beispielsweise Vorschläge zur Verbesserung einer Function-as-a-Service-Architektur in Bezug auf die Erfüllung serverloser Architekturmuster.

Insgesamt lässt sich also sagen, dass Serverless Architecture Vorteile und Herausforderungen mit sich bringt. Wer Serverlose Architektur anwendet muss sich dessen bewusst sein. Bei richtiger Anwendung in einem passenden Umfeld ist Serverless Architecture sehr vielversprechend. Es sorgt für gebündelte Entwicklerproduktivität und überschaubare Kosten.