Serverless FaaS

Die meisten haben wahrscheinlich schon von Serverless oder Function as a Service (FaaS) gehört. Aber was ist das jetzt genau und wieso sollte ich es einsetzen und vor allem: ist es sicher?


Aus Sicht von Developers

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.


Kosten

Dementsprechend sind die Services auch günstig, denn die drunterliegende Compute-Instanz hat nur während ein paar hundert Millisekunden oder Sekunden gearbeitet.

Bei AWS Lambda z.Bsp. sind die ersten 1 Million an Requests (inkl. 400.000 GB-Sekunden Ausführzeit) gratis. Danach zahlt man pro Million Requests $0,20 und pro GB-Sekunde $0,00001667.
Die Preise bei Azure sind ähnlich tief.

AWS Lambda Pricing:

AWS Lambda Pricing

Quelle: https://aws.amazon.com/lambda/pricing/ (abgerufen am 10. April 2019)

Azure Functions Pricing:

Azure Functions Pricing

Quelle: https://azure.microsoft.com/en-us/pricing/details/functions/ (abgerufen am 10. April 2019)


Wie setzt man FaaS ein?

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.


Die Cloud selber cloud-native steuern

Functions sind auch ideal, um Events in der Cloud selber zu steuern. Mann kann z.B. Log-Einträge nach gewissen Stichworten durchsuchen und bei einem Treffer eine weitere Funktion aufrufen, die diese Daten mit bereits gespeicherten Daten der letzten 60 Minuten korreliert. Wenn eine positive Korrelation herauskommt, kann die Funkion einen Alert auslösen, ansonsten kann sie die Einträge die älter als 24 Stunden sind wieder löschen.


Und wie sieht es mit der Security aus?

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).


Vertiefend

Unter Serverless versteht man nicht nur FaaS (Function as a Service) sondern auch BaaS (Backend as a Service). Von der zweiten Modalität haben wir hier gar nicht gesprochen, aber bei einem späteren Blog-Eintrag werde ich das Thema genauer anschauen.

Übrigens, im Cloud-Bereich gibt es zahlreiche wichtige Bereiche zu schützen. Bei AVANTEC evaluiere ich gerade diverse Lösungen. Mehr Infos zu den verschiedenen Bereichen, die geschützt werden müssen: www.avantec.ch/themen/cloud-security.


Abschliessend (TLDR*)

Also, wieso, weshalb und warum Serverless oder FaaS? Weil damit die Infrastruktur vollständig abstrahiert wird. Die effektiven Kosten sind sehr tief, die Skalierung ist Event-gesteuert (pay only what you use) und die Performance ist (meistens) sehr hoch.

*TLDR: Too lazy, didn’t read.

Der Beitrag Serverless – wieso, weshalb, warum? erschien zuerst auf Tec-Bite.