Functions as a Service

Höchst wolkig

Jan Bundesmann

Bei Stack Overflow ergab eine Umfrage unter den dort aktiven Entwicklern, dass Serverless derzeit höchst angesagt ist, da es erlaubt, sich auf das Dev in DevOps zu konzentrieren. Darin liegt allerdings nicht der einzige Nutzen, Serverless lässt sich auch im Rahmen des Internet of Things oder für Big-Data-Anwendungen verwenden.

Exakte Abrechnung nach Verbrauch und eine Infrastruktur, um die sich externes Personal kümmert – Merkmale von Cloud-Angeboten. In diesem Sinne erfüllt Serverless Computing den Cloud-Anspruch in höchstem Maße. Denn darin vereinen sich die Aspekte Skalierbarkeit und bedarfsgenaue Abrechnung. Gleichzeitig fällt zwar nicht der Server selbst, wohl aber die Administration der Infrastruktur weg. Anwender laden einzelne Funktionen hoch. Die Abrechnung erfolgt nach verwendeten CPU-Zyklen und benötigtem Übertragungsvolumen.

Den Begriff „Serverless“ machte Amazon 2014 mit der Einführung seines Angebots AWS Lambda populär [1]. Das Konzept ist allerdings bereits älter. Iron.io verwendete den Term bereits 2011 (siehe „Alle Links“ am Ende des Artikels). Der Name ist etwas irreführend, sind die Server letztendlich doch nicht wegzudenken. Andere Firmen wählen dafür die Bezeichnung „Functions as a Service“ (FaaS). Auch Webhook-Dienste fallen letztlich in diese Kategorie.

**Tabelle: Marktübersicht Plattformen für Serverless Services**

Der Markt präsentiert sich uneinheitlich. Auf der einen Seite steht Manta von Joyent. Dabei handelt es sich primär um einen Objekt-Store. Die gespeicherten Daten können direkt darin verarbeitet werden, wobei Manta ein breites Spektrum an Sprachen und Werkzeugen zur Verfügung stellt. Das andere Ende stellen Dienste wie hook.io oder Fission dar: in erster Linie Empfänger für Signale (Storage-Events, HTTP-Anfragen), die das Ausführen einer Funktion anstoßen. Die Komponente Speicher ist kein Bestandteil mehr, sondern von den Nutzern manuell hinzuzufügen.

Ebenfalls unterschiedlich sind die Bezugsmethoden. Einige Dienste lassen sich aus der Public Cloud beziehen, manche aber auch lokal im eigenen Rechenzentrum installieren. Nur als gehostete Variante gibt es AWS Lambda, Google Functions, hook.io und Webtask.io. Alle anderen gibt es auch für die Private Cloud – allerdings mit unterschiedlichen Schwierigkeitsgraden bei der Installation. Joyents Manta etwa läuft in der hauseigenen Cloud-Infrastruktur Triton, die wiederum im OpenSolaris-Derivat SmartOS zu Hause ist. Azure Functions erfordert den vollen Azure Stack. Fission von Platform9 setzt Kubernetes voraus und ist somit kompatibel zu allen Systemen, die das Microservice-Orchestrierungstool beherbergen können.

AWS Lambda

Wo sind die Server?

Gerade Administratoren könnte der Begriff „Serverless“ sauer aufstoßen, denn Server braucht es auch bei diesem Dienst. Die Kunden kommen damit aber nicht mehr in Berührung. Dass dies auch bei anderen Cloud-Angeboten der Fall ist, ändert nichts an der Tatsache, dass die meisten Nutzer inzwischen wissen, was mit dem Term gemeint ist. Schuld daran dürfte auch sein, dass Branchenführer Amazon sich für den Begriff entschieden hat. Stack Overflow hat in seiner alljährlichen Umfrage gerade festgestellt, dass Serverless als Plattform Platz 2 auf der Beliebtheitsskala erreicht hat. Beliebter ist nur Linux, aber es liegt knapp vor Amazon AWS.

Alternative Bezeichnungen lauten „Functions as a Service“ (FaaS) oder „Event-triggered Microservices“ – die Übersicht zeigt aber auch, dass die Angebote sich nicht beliebig miteinander vertauschen lassen. FaaS ist wahrscheinlich der kleinste gemeinsame Nenner, schließlich müssen Anwender in jedem Fall eine Funktion zum Dienst hochladen, die sie später unter bestimmten Bedingungen aufrufen können. Bei AWS Lambda oder Joyents Manta allerdings ist die Verbindung mit dem jeweiligen Objektspeicher (auf dem dazugehörigen Server) deutlich, während auf der anderen Seite die reinen Webdienste oder die Kubernetes-Applikationen einen eher flüchtigen Charakter haben.

Den Begriff „Serverless“ trug Amazon mit der Einführung seines Dienstes AWS Lambda in die Öffentlichkeit. Seither hält sich der Name hartnäckig (siehe Kasten „Wo sind die Server?“), obwohl natürlich die Administratoren der Dienstanbieter sich weiterhin mit Servern auseinandersetzen.

Lambda-Funktionen kennen Programmierer als Funktionen, die nur über Referenzen oder Zeiger angesprochen werden. Sie sind flüchtig und werden zum Beispiel im Zuge von Garbage Collection gelöscht. Functions as a Service verhalten sich in gewisser Weise ähnlich: Sie belegen Ressourcen lediglich während des Aufrufs, danach stehen Speicher und CPU wieder anderen Diensten zur Verfügung. So bietet sich das Konzept für Cloud-Provider an, die ihre Server maximal auslasten wollen.

Bei Amazon verknüpfen Anwender eine Lambda-Funktion zuerst mit einem Trigger. Das kann ein HTTP-Endpoint sein oder ein Event in einem anderen AWS-Dienst. Häufig ziehen Beispiele die Schnittstelle des Objektspeichers S3 heran. Dieser meldet etwa, wenn Dateien hochgeladen wurden, und eine Lambda-Funktion könnte im Fall von Bildern automatisch Thumbnails erstellen. Weitere Trigger können von der Management-Schnittstelle CloudWatch, von DynamoDB oder von Kinesis kommen. Speziell in der Region Europa (Irland) stehen noch Alexa Skills als Trigger zu Auswahl (siehe auch „Sehr gesprächig“ auf S. 44), um ein Backend für Amazons Sprachassistenten Alexa zu erstellen.

Die Funktionen können in Node.js, Java, C# oder Python geschrieben werden. Zur Eingabe gibt es ein Webformular. Alternativ lassen sich ZIP-Archive mit den benötigten Modulen hochladen oder eine Datei aus S3 wählen.

AWS erlaubt eine feinkörnige Rechtevergabe. Darüber lässt sich steuern, auf welche internen Schnittstellen die Lambda-Funktion zugreifen darf, und andererseits, welche Dienste die Funktion aufrufen dürfen.

Nutzer können bis zu eine Million Aufrufe und bis zu 400 000 GByte-Sekunden Datenverarbeitungszeit jeden Monat kostenlos nutzen. Dieses Angebot langt eventuell während des Ausprobierens und für Privatanwender. Die Zeitkosten berechnen sich nach dem Arbeitsspeicher, den eine Funktion zugewiesen bekommen hat, und der tatsächlichen Ausführungszeit – hier ist also darauf zu achten, nicht unnötig viel Speicherbedarf zu veranschlagen. Weitere Rechenzeit kostet 0,001667 Cent pro GByte und Sekunde sowie 20 Cent für eine Million Aufrufe. Zusätzlich weist Amazon auf die möglichen Kosten für Datenübertragung und Storage beziehungsweise Datenbankkapazität hin.

Azure Functions

Microsoft integriert einen Funktionendienst über Azure Functions in der Public Cloud. Mit der in Aussicht gestellten Private- und Hybrid-Variante Azure Stack soll sich das Angebot auch lokal installieren lassen.

Einrichten lässt sich eine Azure Funktion über das Azure Dashboard: New | Compute | Function App oder direkt über functions.azure.com. Dieser Prozess läuft in der Regel über das GUI, ein Kommandozeilen-Interface existiert bisher lediglich für Windows, obwohl Microsoft bereits angekündigt hat, es auch für andere Plattformen bereitzustellen. In der Eingabemaske zum Einrichten wählen Anwender zuerst Sprache und Szenario, also die Art der Trigger. Zur Verfügung stehen C#, F#, JavaScript, Bash, Batch, PowerShell, PHP und Python. Die einfachste Steuerung erfolgt über Timer oder über manuellen Aufruf per GUI. Ebenfalls lassen sich Webhooks, HTTP-Requests oder spezielle GitHub-Webhooks wählen. Letzteres zielt auf eine Nutzung als Continuous-Integration-Werkzeug. Blobtrigger reagieren auf das Hinzufügen von Dateien in einen Azure-Storage-Container. Im Dashboard können Azure-Kunden über den Menüpunkt „Internet of Things“ Events definieren, die als Trigger dienen. Außerdem lassen sich Jobs in Queues einfügen.