Inzwischen gibt es bei den meisten Cloudanbietern die Möglichkeit kleine Codeteile als sogenannte Functions zu hinterlegen. Durch eingerichtete Trigger werden Parameter übergeben und die eigentliche Ausführung ausgelöst. Manchmal wird dieses Konzept auch als Serverless bezeichnet. Das ist etwas irreführend, denn zur Ausführung werden natürlich Server benötigt. Nur muss man sich als “Anwender” nicht im eigentlichen Sinne um eine Ablaufumgebung, also eine VM Instanz oder deren Skalierung, kümmern. Das übernimmt der Service selbst. Da kein expliziter Server existiert, fallen Kosten nur an, wenn die Function auch aufgerufen wird. Das spart Kosten. (siehe auch den Artikel meines Kollegen: Serverless ). Aber auch sonst bieten Functions eine sehr interessante Abstraktion, deren Vorteile man auch innerhalb eines Kubernetes Clusters sehr gerne nutzen würde (die Kosten eines Aufrufs spielen in diesem Fall natürlich keine Rolle).

Kubernetes

Wer FaaS auf Kubernetes realisieren will, kann derzeit zwischen einigen (mehr oder weniger erwachsenen) Projekten auswählen:

Alle drei Frameworks sind Kubernetes native. Das heißt, sie bedienen sich der Kubernetes-Ressourcen, um eine Ablaufumgebung für Functions (in Form von Containern) zur Verfügung zu stellen, sie zu skalieren und zu verwalten. Der Anwender erstellt und konfiguriert seine Functions ausschliesslich per Command Line Interface und/oder Webinterface. Im folgenden beziehen sich die Angaben im Wesentlichen auf Fission.

Functions

Functions bestehen aus Sicht des Anwenders nur aus dem Quellcode selbst. Unter Angabe der Quelldatei werden Functions sehr einfach erzeugt und damit deployed.

Charakteristik einer Function

In ihrer Charakteristik sind Functions grundsätzlich Zustandslos und existieren nur während der Ausführung ihres Codes. Dabei sind unterschiedliche Programmiersprachen möglich. Im Falle von Fission sind dies zum Beispiel: Bash, Binary Executables, Node.js, Go, Python, PHP, etc. Gestartet wird eine Function durch einen sogenannten Trigger. Davon stehen mehrere zur Verfügung: Messages, Timer, HTTP oder auch Kubernetes Events. Aber egal welcher Trigger auch verwendet wird, die Functions haben stets dasselbe Interface und müssen somit nicht abgepasst werden, wenn man einen anderen Trigger verwenden möchte.

Entwicklungsumgebung

Functions haben bereits bei der Entwicklungsumgebung einige Vorteile. Denn Functions sind nur Quellcode (der aber auch durch ZIP Files oder Packages zusammengefasst werden kann). Es muss weder ein gesonderter Build-Schritt implementiert werden, noch ein Build-System vorhanden sein. Ebenso müssen üblicherweise keine Container gebaut oder durch eine Registry verwaltet werden.

Laufzeitumgebung

Die Verwaltung der Functions und der Laufzeitumgebung im Cluster, erfolgt durch das Framework. Daraus ergibt sich:

Anwendungsfälle

Bei der Entwicklung von Anwendungen sind Functions orthogonal zu einem allgemeinen Architekturprinzip wie z.B. Microservices. Allerdings stellen sie eine weitere Option zur Modularisierung von Geschäftslogik oder zur Implementierung von kleinen Actions (als Reaktion auf einen Trigger) dar. Da sich mehrere Functions auch über Events miteinander verketten lassen, sind auch ereignisgetriebene Workflows möglich.

Für welche Anwendungsfälle setzt man Functions auf einem Cluster mit Kubernetes ein? Ein paar Beispiele:

Ausblick

Kubernetes ist noch jung, FaaS als Kubernetes Native Framework ist noch jünger. Dennoch scheinen sich die o.g. Projekte in Richtung Produktiveinsatz zu bewegen oder sie werden bereits eingesetzt. Sie sorgen dafür dass, neben z.B. einer Cloud Native Storage oder den Operators (für etcd, Prometheus, ElasticSearch etc.), weitere Teile der Infrastruktur der großen Cloudanbieter in den eigenen Cluster geholt werden können. Ein wichtiger Schritt in Richtung Unabhängigkeit und Flexibilität.

Wer in seinem Projekt die oben genannten Anwendungsfälle vorfindet, sollte sich also eins der FaaS Projekte unbedingt ansehen.

TAGS