Serverless – wieso, weshalb, warum?

Softwareentwickler (oder Developer) wollen sich eigentlich nicht um die Infrastruktur kümmern, worauf ihre Applikationen laufen. Sie würden gerne Applikationen schreiben und die Server, das Netzwerk, die Security usw. jemand anderem überlassen.

Bei der Evolution von VM’s hin zu Containern (Docker, Kubernetes, etc.) ist ein Grossteil der Hardware-Eben schon abstrahiert. Der Developer kann bei so einer Umgebung die nötigen Definitionen in einem YAML File auflisten (das ist er sich gewohnt) und das Orchestrierungs-System übernimmt dann den Rest.

Und Serverless geht jetzt eben noch einen Schritt weiter. Der Developer kann einen Teil seines Codes (oft einen Algorithmus, eine Berechnung – deswegen auch «Function») in einem File ablegen, und dann definieren, unter welchen Umständen dieser Code ausgeführt wird.

In solchen Umgebungen ist das Event-getrieben. Konkret bedeutet das z.B. dass ein User auf einem Front-End seine Daten eingibt und diese dann abschickt. Das Abschicken der Daten ist ein Event und kann jetzt eine Funktion triggern. Die Funktion nimmt die Daten vom User und bearbeitet sie, berechnet z.B. den Preis basierend auf den Daten, die der User eingegeben hat.

Der Output dieser Funktion wird z.B. in eine Datenbank und zurück zum Front-End geschickt, damit der User den Preis bekommt. Sobald die Funktion die Berechnung abgeschlossen hat und sie weitergeschickt hat, wird der Code beendet (wenn es eine VM oder ein Container wären, dann würden diese nachher heruntergefahren oder geschlossen werden). Meistens führt die «Function» ihre Funktion in Millisekunden aus.

Kann man mit FaaS oder Serverless jetzt ganze Applikationen ersetzen? Dies wäre zwar wahrscheinlich möglich, ist aber nicht der Sinn der Sache. Wenn man jetzt nämlich 600 Funktionen untereinander verlinken will, dann kann man genauso gut eine Micro-Service Applikation schreiben.
Functions kommen z.B. dann zum Zuge, wenn man immer wieder etwas berechnen oder ausführen will, aber das nicht kontinuierlich macht. Oft werden Functions auch bei IoT Anwendungen eingesetzt, weil die Event-basierte Natur von IoT sehr gut mit Serverless zusammenpasst.

Man kann sich das gut an einem Beispiel vorstellen:

Eine Sonde misst den Inhalt eines Dieseltanks und schickt über MQTT Daten zum AWS IoT Message Broker. Sobald ein neuer Wert hochgeladen wird, schickt der Message Broker diese Daten an AWS Lambda (wo unsere Funktion lebt). Durch diesen Event wird die Funktion aufgerufen. Sie ist so programmiert, dass sie neue Daten immer auf S3 ablegt, aber wenn ein Mindestwert erreicht ist, muss sie einen Alert auslösen (damit der Tank rechtzeitig wieder gefüllt werden kann).

Die Kosten sind dabei äusserst gering, bei einer Messung pro Minute, kann man mit 525’600 Messungen im Jahr rechnen, was zu etwas über einer Million Events pro Jahr führt, ca. $0,20.

So etwas ist nicht mit einer VM Instanz oder einem Container vergleichbar.

Erledigt der Cloud Provider denn nicht auch die Security bei Serverless? Genau gleich wie bei anderen Cloud-Services sind AWS, Azure und Co. für die Sicherheit der Infrastruktur zuständig, in diesem Fall also für die Sicherheit der FaaS Plattform (AWS Lambda oder Azure Functions). Für die Sicherheit der Applikationen und Daten ist der Benutzer weiterhin zuständig. Was kann denn schon passieren bei einer Funktion die nur alle 15 Minuten für weniger als 1 Sekunde aufgerufen wird? Unter Umständen eben einiges, jemand könnte sie unendlich lange laufen lassen und damit kosten verursachen. Oder die Funktion könnte so angepasst werden, dass sie nie einen Alert versendet, was zu einem leeren Tank führen könnte. Oder die Funktion versendet jede 2 Stunden einen Alert und ein Tanklastwagen wird unnötigerweise zu einem noch vollen Tank versendet.

Na gut, wie schütze ich mich dann vor Missbrauch solch einer Funktion? Auf der einen Seite sollte das Image der Funktion wie jedes andere Image vor dem Deployment gegen Vulnerabilities gescannt werden. Und die Images, die im Registry abgelegt sind sollten auch regelmässig gescannt werden, denn eine Vulnerability kann auch nach einem Deployment auftauchen.

Wenn man die Funktion während der Ausführung (runtime) überwachen möchte, dann kommt man nicht darum herum, sie mit einem weiteren Stück Code zu ergänzen. Dieser Security-Code kann als Firewall, als Proxy oder als ein Log-Melder wirken. Damit kann man einschränken mit wem die Funktion kommunizieren darf, worauf die Funktion Zugriff hat, wie lange sie ausgeführt werden sollte (wobei ein Alert ausgelöst werden kann, wenn die Länge der Ausführung einen Grenzwert überschreitet) und ob das Resultat innerhalb des erwarteten Rahmens liegt. Ein Baselining der Funktion über einen gewissen Zeitrahmen hinweg erlaubt auch eine gute Detection von Anomalien (dafür würde am effizientesten ein ML-Algorithmus eingesetzt).