Tatsächlich ist der Begriff etwas irreführend, denn ohne irgendwelche Server geht es natürlich nicht. Treffender ist da schon eher das Synonym Functions-as-a-Service (FaaS). Wie Microservices ist dieser Ansatz kein Allheilmittel, das alle Probleme in der Softwareentwicklung lösen wird. Fernab vom Hype gibt es jedoch einige interessante Anwendungsfälle, für die sich ein zweiter Blick darauf lohnen könnte.
Was ist serverless?
Mittlerweile bieten die meisten großen Cloud-Anbieter die Möglichkeit, „kleine“ Funktionen zu hinterlegen, die bei bestimmten Ereignissen aufgerufen werden. Wobei die Größe weniger die Anzahl der Codezeilen meint, sondern eher den Fokus der Funktion. Sobald eine solche Funktion zu viele Aufgaben übernehmen soll, wird es schnell unhandlich und Fehler lassen sich nur noch schwer identifizieren. Der Anbieter bestimmt, welche Programmiersprache dabei verwendet werden kann. JavaScript und Python zählen hier zu den Favoriten. Meist lassen sich aber auch Binaries zu einer Funktion ablegen und von der Funktion aus aufrufen. Das hat zwei Vorteile: erstens lassen sich so auch vorhandene und eventuell closed-source Programme einbinden, zweitens kann man Programmiersprachen verwenden, die einen geringeren Speicherverbrauch oder bessere Performance aufweisen.
Wie der Name vermuten lässt, findet die Ausführung der Funktionen nicht auf gebuchten Serverinstanzen statt, sondern in Containern der Cloud-Plattform. Als Entwickler muss ich mich nicht darum kümmern. Im Gegenzug habe ich aber auch keinerlei Einfluss darauf, wann ein solcher Container gestartet und wieder gestoppt wird oder wie viele Container gleichzeitig ausgeführt werden. Das entscheidet alleine die Plattform. Damit das funktionieren kann, muss eine solche Funktion zustandslos sein. Alle Daten, die sie zum Arbeiten braucht, müssen ihr entweder übergeben oder bei jedem Durchlauf von anderen Ressourcen geladen werden. Meist eingebettet in ein Cloud-Portfolio des Anbieters, kann das z.B. eine Datenbank oder ein verteiltes Dateisystem sein.
Ereignisse, die letztlich zur Ausführung einer Funktion führen, werden ebenfalls von anderen Dienste des Anbieters ausgelöst. Eine Nachricht in einem Messaging-System, ein HTTP-Aufruf, eine neue Datei im Dateisystem oder ein neuer Datensatz in der Datenbank sind nur ein paar Beispiele für mögliche Ereignisse.
Und wozu ist das gut?
Der große Vorteil von „Serverless“-Funktionen liegt darin, dass man als Kunde nur für die Zeit bezahlt, die eine Funktion tatsächlich ausgeführt wird. Anstatt also große Serverinstanzen zu buchen, um bestimmte Lastspitzen erfolgreich meistern zu können, kann man z.B. rechen- oder speicherintensive Teile seiner Anwendung damit auslagern.
In meinem aktuellen Projekt z.B. entwickeln wir eine Anwendung, die auf AWS in vergleichsweise kleinen EC2-Instanzen lauffähig ist. Die Anwendung braucht für das Bewältigen der Business-Logik kaum Rechenpower und nur wenig Speicher. Durch die von Amazon zur Verfügung gestellte Autoskalierung kann steigenden Benutzerinteraktionen mit mehreren kleinen Instanzen begegnet werden, während die meiste Zeit aber nur eine Instanz benötigt wird. Zu der Fachlichkeit der Anwendung gehört auch das Hochladen von Dateien. Diese werden von der Anwendung selber nicht bearbeitet, sondern direkt bei Amazon im Simple Storage Service (S3) abgelegt. Hierbei handelt es sich um große CAD-Dateien, die teilweise konvertiert werden müssen. Selbst das Konvertieren einer einzigen Datei kann dabei so speicherintensiv sein, dass wir den EC2-Instanztyp mindestens verdoppeln müssten. Allerdings wird die Anwendung nur zu bestimmten Tageszeiten verwendet, sodass sich die Instanzen die meiste Zeit langweilen würden. Bezahlen müsste man für sie aber dennoch.
Dies ist ein Paradebeispiel für FaaS: Bei jeder hochgeladenen Datei wird unsere AWS-Lambda-Funktion aufgerufen. Diese prüft zunächst anhand der Metadaten der Datei, ob eine Konvertierung notwendig ist. Falls ja, wird die Datei von S3 in das temporäre Dateisystem der Lambda-Funktion geladen. Anschließend ruft die Funktion ein statisch gelinktes C/C++-Linux-Binary auf, das zusammen mit der JavaScript-Funktion deployt wurde und die Konvertierung übernimmt. Das Ergebnis wird dann wieder zu S3 hochgeladen. Damit können zu Stoßzeiten theoretisch beliebig viele Benutzer gleichzeitig große Dateien hochladen, und die Anwendung selber kommt dennoch mit nur ein paar wenigen Serverinstanzen aus.
Amazon beschreibt in ihrer Dokumentation einen ähnlichen Anwendungsfall, bei dem es um das Generieren von Thumbnails für hochgeladene Bilder geht. Darüber hinaus hat mein innoQ-Kollege Michael Vitz bereits letzten Sommer einen sehr ausführlichen Artikel zum Thema veröffentlicht.
Ausblick
Dank FaaS und der teils hervorragenden Integration ins Portfolio der Anbieter kann man tatsächlich ohne Server auskommen. Dort findet man angefangen von Lösungen für Authentifizierung und Authorisierung über API-Schnittstellen bis hin zu Datenbanken und Messaging-Systemen alles, was das Entwicklerherz begehrt. Gerade im noch jungen IoT-Umfeld sieht man immer häufiger Unternehmen, die so sehr schnell gewinnbringende Lösungen anbieten können. Das liegt nicht zuletzt daran, dass Cloud-Anbieter sich auch vermehrt auf die Anbindung von internetfähigen Kleinstgeräten fokussieren. Mit MQTT-Schnittstellen und Schattengeräte buhlen sie um die Gunst der Kunden. Nicht zu vergessen der neuste Geniestreich, seine Geräte durch gut funktionierende Sprachbedienung für Kunden noch interessanter zu machen. Dennoch wird man in der Regel als Softwareentwickler weiterhin Anwendungen schreiben, die später auf Servern betrieben werden. Es schadet aber sicherlich nicht, Functions-as-a-Service in seiner Werkzeugkiste zu haben und gezielt einzusetzen.