Function as a Service

Das Thema Function as a Service (FaaS) im Rahmen von Serverless Computing und als Weiterführung von Microservices ist nach wie vor ein vieldiskutiertes Thema. Dieser Artikel soll dem Leser Grundlagenwissen zur FaaS-Thematik vermitteln. Anschließend soll er einschätzen können, für welche Projekte und Teile eines Projektes es sich möglicherweise lohnen könnte, auf Functions as a Service zu setzen.

Einordnung von Function as a Service

Function as a Service (FaaS) reiht sich als weiteres Abstraktionsmodell in die bestehende Reihe aus Software as a Service (SaaS), Backend as a Service (BaaS), Platform as a Service (PaaS) und Infrastructure as a Service (Iaas), sowie On-Premises Systemen ein. Dies ist in der folgenden Abbildung visualisiert. Die hellblauen Elemente werden dabei vom Kunden selbst verwaltet, während die weißen Elemente an den *aaS-Anbieter ausgelagert werden.

Function as a Service - Einordnung

Function as a Service – Einordnung

Während bei On-Premises der gesamte Stack von Hardware und Netzwerkumgebung bis zur Business Logic vom Kunden selbst verwaltet wird, wird bei Infrastructure as a Service (beispielsweise Amazon EC2) alles unterhalb der Betriebssystemebene abstrahiert und an den IaaS-Anbieter ausgelagert.

Bei Platform as a Service (z. B. Heroku) werden OS und Runtime ebenfalls abstrahiert, bei Backend as a Service wird sogar die Datenschicht (z. B. Datenbank) vom BaaS-Anbieter verwaltet.

Bei Function as a Service (etwa AWS Lambda) bleibt nur noch die reine Business Logic in Form der Funktionen selbst zu managen. Als Abgrenzung zu PaaS gilt, dass hier nicht mehr ganze Anwendungen deployed werden, sondern nur noch einzelne Komponenten (Functions) einer Anwendung. Dies ist vergleichbar mit Microservice-Architekturen, bei denen eine monolithische Anwendung auch in mehrere kleinere Services unterteilt wird. FaaS ist nicht dafür gedacht, für jede Anfrage die gesamte Anwendung zu starten und sie nach Abarbeitung derselben wieder zu beenden.

Schließlich gibt es noch Software as a Service, bei der das gesamte Produkt als fertige Dienstleistung verkauft wird. Beispiele für Software as a Service sind Salesforce oder Microsoft Office 365.

Eigenschaften von FaaS

Wie aus der oberen Abbildung zu entnehmen ist, läuft eine FaaS-Anwendung serverless. Das bedeutet keineswegs, dass kein Server existiert, sondern nur, dass die Verwaltung des Servers an den FaaS-Anbieter ausgelagert wird. Des Weiteren ist eine mit FaaS umgesetzte Anwendung stateless.

Um auch Daten persistieren oder zumindest temporär halten zu können, kann ein Datensytem wie eine Datenbank, ein Out of Process Cache (z. B. Redis) oder ein Netzwerkdateisystem angebunden werden. Bei AWS Lambda, dem FaaS-Dienst von Amazon, kann beispielsweise eine DynamoDB oder ein S3-Filestorage direkt von Amazon angebunden werden.

Das Kernfeature von FaaS ist allerdings die einfache Skalierbarkeit. Da die einzelnen Functions in sich abgeschlossen und stateless sind, wird vom FaaS-Anbieter für jede Anfrage eine Instanz der entsprechenden Funktion erzeugt. Es wird also horizontal skaliert. Je nach erforderlicher Kapazität wird also automatisch dynamisch mitskaliert. Damit können Lastspitzen relativ einfach abgefangen werden und Kapazitäten bei geringer Nutzung automatisch reduziert werden. Da die meisten FaaS-Anbieter mit ihren Kunden pro Funktionsaufruf abrechnen, lassen sich an dieser Stelle auch die Kosten optimieren.

Bei FaaS geht es darum, ausschließlich die Anwendungsfunktionalität als solche in Form der Funktionen in abgeschlossenen Einheiten zu modellieren. Das heißt, der Kunde muss sich genau wie bei PaaS nicht um die Administration des Netzwerks, des Servers oder des Betriebssystems kümmern. Zusätzlich wird neben der Datenbank (wie bei BaaS) auch die Anwendung als solche ausgelagert. Dadurch kann die Auslastung des Gesamtsystems optimiert werden, da es aus Sicht des Kunden keine dauerhaft laufenden Serverprozesse und keinen dadurch entstehenden Overhead gibt.

Durch die oben erwähnte Abgeschlossenheit der einzelnen Functions lassen sich, wie bei anderen Systemen mit Microservicearchitektur auch, einzelne Module mit begrenztem Aufwand aktualisieren und redeployen. Der Vorteil hierbei ist, dass die Änderungen sich quasi instantan ausrollen lassen, da ja ohnehin für jede Anfrage eine neue Instanz der Function gestartet wird. Dafür muss nur eine neue Version des Quellcodes für die entsprechende Function beim FaaS-Anbieter hochgeladen werden.

Üblicherweise bieten die meisten FaaS-Anbieter polyglotte Schnittstellen für die Programmierung der Functions an. Dabei werden meist Programmiersprachen wie JavaScript, Python und JVM-Sprachen wie Java oder Scala unterstützt. Für detaillierte Informationen zu den unterstützten Programmiersprachen sollten die Websites der entsprechenden Anbieter konsultiert werden. Als weitere Ebene über den Funktionen werden von den FaaS-Anbietern API-Gateways angeboten, mit denen sich beispielsweise bestimmte Web-Requests automatisch auf bestimmte Functions routen lassen.

Natürlich lassen sich die Functions durch unterschiedlichste Trigger auslösen. Etwa kann eine Function durch eine HTTP-Anfrage gestartet werden. Alternativ kann ein meist händlerspezifischer Event-Bus angebunden werden oder auf Dateievents auf einem angebundenen Dateisystem (z. B. S3) gehorcht werden. Auch ein zeitbasiertes Scheduling von Functions ist möglich.

In der Praxis

Wofür eignet sich FaaS denn nun? Zunächst wären da einmal die einfachen, abgeschlossenen Funktionen. „Alexa, wie wird morgen das Wetter in Mannheim?“. Eine abgeschlossene Anfrage, die stateless zu verarbeiten ist und serverless beispielsweise auf AWS Lambda deployt werden kann. Alexa-Skills sind übrigens in AWS-Lambda realisiert und von Amazon deployt. Wer also einen eigenen Alexa-Skill entwickeln möchte, wird um FaaS und AWS Lambda nicht herumkommen.

Neben Amazon mit AWS Lambda bieten auch Google (Google Cloud Functions), Microsoft (Azure) und Oracle (Oracle Cloud Fn) FaaS-Dienstleistungen an.

Neben den Alexa-Skills lassen sich auch Single-Page Apps mit weniger komplexer Business Logic gut in der FaaS-Architektur abbilden.

Des Weiteren können gegebenenfalls rechenintensivere Komponenten, die stateless ausführbar sind und besonders skalieren sollen, aus einem bestehenden System ausgebaut und an einen FaaS-Anbieter ausgelagert werden. Beispiele dafür sind die On-Demand Bild-/Video-Verarbeitung oder die automatische Generierung von PDF-Dateien.

Als dritten Punkt bieten sich zeitlich gesteuerte Aufgaben an, etwa ein bestehendes S3-System aufzuräumen oder auf Basis von Datenbankwerten einmal täglich Email-Benachrichtigungen zu verschicken.

Ob die Umsetzung eines gesamten Enterprisesystems auf Basis einer FaaS-Architektur oder gar der Umbau eines bestehenden Systems wirtschaftlich wäre, ist allerdings zu bezweifeln. Viel mehr geht es hier um kleinere Systeme oder einzelne Subsysteme von komplexen Systemen.

Eine Schwäche von FaaS offenbart sich beim sogenannten Vendor lock-in, wie er in der folgenden Abbildung illustriert ist.

AWS Lambda Vendor Lock-In

AWS Lambda Vendor Lock-In

Wer seine FaaS-Anwendung erst einmal bei AWS Lambda aufgesetzt hat und diese an eine DynamoDB von Amazon, sowie ein AWS Kinesis und ein S3-Filesystem, ebenfalls von Amazon, angebunden hat, wird Probleme bekommen, das Projekt beispielsweise zu Microsoft Azure zu portieren. Als Lösung für dieses Problem gibt es OpenSource-FaaS-Frameworks, etwa OpenWhisk. Damit lässt sich der FaaS-Stack, der normalerweise vom FaaS-Anbieter gehostet wird, auch On-Premises betreiben. Dabei geht natürlich der Vorteil der „unbegrenzten“ Skalierbarkeit verloren.

Ein weiteres Problem offenbart sich, wenn beispielsweise Java zur Programmierung der Functions verwendet wird. Dann können bei unregelmäßigen Funktionsaufrufen und extremen Leistungsspitzen Wartezeiten entstehen, da die JVM möglicherweise einen Moment zum Hochfahren benötigt.

Auch das Tooling und die Möglichkeiten zum Debugging sowie Monitoring waren zum Zeitpunkt der Veröffentlichung dieses Artikels noch eher rudimentär, werden sich aber möglicherweise im Laufe der Zeit verbessern.

Security stellt je nach Anwendungsfall ein weiteres Problem da, welches auch bei SaaS-Lösungen weit verbreitet ist: Durch die sogenannte Mandatenfähigkeit (Multitenancy; mehrere Benutzer auf der gleichen physischen Maschine) seitens der FaaS-Anbieter hat man als Kunde keine Kontrolle über die korrekte Isolation seiner Daten und denen von anderen Kunden. Ein Angreifer, der das System des FaaS-Anbieters überlistet, hat somit möglicherweise gleich Zugriff auf alle Daten aller Kunden des Anbieters. Da besonders große Anbieter auch viel Angriffsfläche bieten und ein gesteigertes Interesse seitens der Angreifer hervorrufen, kann man nur hoffen, dass die Sicherheitsexperten des FaaS-Anbieters ihr System auf derartige Fälle ausreichend vorbereitet haben.

Fazit

Wenn es also um kleine abgeschlossene Funktionen oder einfache zeitgesteuerte Aufgaben geht, sowie um einzelne Komponenten größerer Systeme, könnte der Einsatz einer FaaS-Architektur dafür sondiert werden. Sofern der mögliche Vendor Lock-In und die Sicherheitsbedenken kein Problem darstellen, bietet FaaS eine hervorragende Möglichkeit, noch schneller als bei PaaS ein Produkt an den Markt zu bringen und bei einem Erfolg des Produktes auch mit begrenztem Aufwand zu skalieren. Im Kontrast zu beispielsweise provisionierten EC2-Instanzen muss sich der FaaS-Kunde weniger Gedanken um die korrekte Skalierung machen und kann die Kosten dank Abrechnung einzelner Funktionsaufrufe sogar noch feingranularer optimieren, als bei der Abrechnung von Rechenzeit der EC2-Instanzen.

Quellen:
1: Fowler
2: Heise
3: Informatik aktuell
4: Wired.com
5: Stackify

Short URL for this post: https://wp.me/p4nxik-2YC
This entry was posted in Java Runtimes - VM, Appserver & Cloud and tagged , , , , , , , , , . Bookmark the permalink.

2 Responses to Function as a Service

  1. mugwump64 says:

    Schöne Übersicht, Danke dafür!

    Aber steckt da auch nicht noch etwas anderes dahinter? Ändern sich nicht auch die Architekturen drumherum, in denen das “serverless function” nur ein Teil ist? Jetzt mal abgesehen davon, dass es für kleinere Sachen wirklich schick ist, keinen Server zu brauchen. Das verschiebt doch unsere Wahrnehmung davon, was alles “Boilerplate” ist doch ganz gehörig…

    Aber wenn man auch mal den Shift in den Architekturen zum “reactive” dazu nimmt, dann ist doch in ein paar Jahren alles asynchron, nichts gibt mehr eine Antwort, alles ist nur noch “eventually consistent”. Und ich weiß nicht, ob wir das alle schon so ganz realisiert haben, was das bedeutet und ob CQS und Event-Sourcing nicht langsam zu dominanten Patterns werden – und dann machen “serverless functions” schon irgendwie mehr Sinn und nicht mehr nur noch für “kleinere Sachen”…

    Ich find’ das momentan ein spannendes Thema, weil sich hier an vielen verschiedenen Fronten gleichzeitig was verändert: die Client-Architekturen ändern sich ja gerade auch, so wird z.B. Redux immer wichtiger, Amazon pusht Lambda ziemlich, dann gibt’s aber mittlerweile auch schon verschiedene “remedies” die die verschiedenen Issues von serverless functions angehen (z.B. serverless, http://serverless.com, die das deployment-problem angehen, oder Apaches OpenWhisk, http://openwhisk.incubator.apache.org, mit der man “serverless” auch on premise laufen lassen kann).

    PS: Das Coldstart/Latenzproblem der JVM scheint zumindest Amazon ganz gut im Griff zu haben, diese Performance-Tests hier fand ich sehr interessant: https://read.acloud.guru/comparing-aws-lambda-performance-when-using-node-js-java-c-or-python-281bef2c740f, vor allem weil es mit Java nicht nur gute Werte, sondern weniger Varianz in der Performance im Vergleich zu z.B. node hat. Aber n “Hello World” ist immer noch einfacher und kleiner in node :)

  2. Pingback: Serverless Computing I - Cryptiot

Leave a Reply