Serverless Functions auf Kubernetes – Welche Open-Source Lösung ist die richtige?

Die Entwicklung einer Applikation soll immer schneller und kostengünstiger werden und genau dort setzt Serverless-Computing an. Serverless bedeutet jedoch nicht das Fehlen eines Servers, sondern hebt hervor, dass die Infrastruktur des Servers für den Nutzer abstrahiert ist. Entwickler konzentrieren sich alleinig auf die Entwicklung und müssen keine Zeit in das Aufsetzen oder die Konfiguration des darunterliegenden Systems aufwenden. Da Serverless auf einer herkömmlichen Public-Cloud aber viele Limitierungen (z.B. Vendor Lock-In oder schlechte Portabilität) mit sich bringt, gibt es dazu mehrere Alternativen. Sogenannte Open-Source Serverless Platform Frameworks wirken den Limitierungen entgegen – im speziellen auf dem Container-Orchestrierungswerkzeug Kubernetes.

Serverless auf Kubernetes als Abhilfe

Ein beträchtlicher Nachteil von Serverless in der Public-Cloud ist der sogenannte Vendor Lock-in. Cloud-Umgebungen basieren alle auf einer unterschiedlichen Implementierung des Serverless Konzeptes und stellen unterschiedliche Programmiersprachen bereit. Wie der Name Vendor Lock-in schon suggeriert, wird dadurch eine direkte Abhängigkeit mit dem Cloud-Provider eingegangen und die produzierte Businesslogik kann nicht ohne weiteres in beispielsweise eine neue Cloud portiert werden. Auch ein Bereitstellen in einer Private-Cloud oder On-Premise ist durch eine Public-Cloud limitiert. Festgesetzte Konfigurationen wie die maximale CPU-Leistung, maximale Speicherleistung oder maximal gleichzeitig ausgeführte Funktionen verhindern zusätzlich bestimmte Anwendungsfälle. [3]

Dieser Beitrag soll darstellen, wie man die bestehenden Lösungen und Funktionen vergleichen kann, um das jeweils passende Framework für sich auszuwählen.

Welche Kubernetes Lösung ist die richtige?

Um diese Frage zu beantworten, haben wir uns die fünf größten Frameworks, die aktiv weiterentwickelt werden, angeschaut:

• Knative
• OpenWhisk
• OpenFaaS
• Fission
• Kubeless

Für diese haben wir dann ein Bewertungskonzept entwickelt, um objektiv und nachvollziehbar Open-Source Serverless Platform Frameworks zu vergleichen. Über eine Expertenbefragung wurden neun Bewertungskriterien identifiziert (siehe Abbildung 1 – Liste der Bewertungskriterien).

Das gesamte Bewertungssystem ist so konzipiert, dass beliebig Kriterien und Gewichtungen an den Projekt-/Kundenkontext angepasst werden können. Beim Vergleich der Frameworks auf Basis dieser Kriterien kristallisierte sich heraus, dass diese sich im Wesentlichen durch drei Merkmale voneinander differenzieren:

1. Entwicklung – Programmiersprachen:

Auf den ersten Blick bewegen sich alle fünf Frameworks auf einem ähnlichen Reifegrad, was Entwicklungsfunktionen angeht. So unterstützen alle jeweils mindestens sieben unterschiedliche Sprachen für die Entwicklung und sind auch alle erweiterbar durch eigene Anbindung einer Programmiersprache (ein Auszug ist in Tabelle 1 zu sehen). Der Unterschied liegt hier allerdings im Detail. So sind nicht immer alle Runtimes in der gleichen Reife unterstützt. Fission beispielsweise unterstützt auf dem Papier die .Net Core Sprache, aber diese nur in der Version 2.0 und erlaubt beispielsweise nur über Umwege das Anbinden von eigenen NuGet-Repositories. Aber in der Zahl unterscheiden sich die verschiedenen Lösungen nur gering und schneiden dabei alle gleich ab.

Tabelle 1 – Auszug aus Runtimes der Kandidatinnen und Kandidaten

2. Skalierung – Scale to Zero:

Eine der Schlüsselmerkfunktionalitäten einer Serverless Function ist es, die Funktion komplett herunter zu skalieren, sodass keine Instanz läuft. Dadurch werden Ressourcen und Geld eingespart, da der Verbrauch nicht bezahlt werden muss. OpenFaaS und Kubeless aber unterstützen diese Funktionalität gar nicht bzw. nur als Enterprise Funktion. Die restlichen Frameworks setzen das Skalierungsprinzip jeweils um. Dies sollte bei der Wahl der geeigneten Lösung auf jeden Fall in Betracht gezogen werden. Hier wird jedoch der Nachteil von einer theoretischen Analyse deutlich. Zum Zeitpunkt der Analyse beinhaltete Fission eine Performance Limitierung, ausgelöst durch die Scale to Zero Funktionalität, die erst bei der Analyse anhand eines praktischen Anwendungsfalls deutlich wurde. Wie in Abbildung 2 zu sehen, sind dabei die Antwortzeiten von Fission enorm höher als bei beispielsweise Azure Functions.

3. Community:

Auch in der Größe der Community bzw. der Mitwirkenden-Anzahl bilden sich große Diskrepanzen zwischen den einzelnen Lösungen. OpenFaaS ist dabei, wie in Tabelle 2 zu sehen, mit einem großen Abstand das beliebteste Framework, wobei Knative die meisten Mitwirkenden hat. Vor allem OpenFaaS punktet hier als die verbreitetere Lösung, auch unterstützt durch die Marketingarbeit der OpenFaaS Ltd. und mehreren Vorträgen auf Konferenzen und Workshops.

Tabelle 2 – Anzahl der Mitwirkenden und Sterne der jeweiligen Lösungen

Das Gesamtergebnis unseres Vergleichs ist in Tabelle 3 dargestellt. Das Framework Fission ist mit dem höchsten Gesamtnutzwert bewertet worden und geht damit als Sieger hervor. Fission ist eine relativ neue Lösung auf dem Markt und bietet im Gegensatz zu den anderen Kandidaten, durch das Injizieren des Funktionscodes in einen Environment-Container, zusätzlich einen gänzlich anderen Ansatz zur Bereitstellung der Funktionen an. Fission profitiert davon, dass es mehrere Kriterien besser als die Vergleichslösungen umsetzt. Dazu gehört die nutzerfreundlichere Dokumentation und der für den Entwickler intuitive Umgang mit dem Command Line Interface (CLI). Wobei zu beachten ist, dass die vorhandene Dokumentation zwar übersichtlich und detailliert ist, aber der Umfang noch zu wünschen übriglässt. Fission bietet effiziente Ansätze und Konfigurationsmöglichkeiten, um auf ein breites Spektrum von möglichen Anwendungsgebieten zu passen. Dadurch hebt es sich in der theoretischen Analyse von den anderen Frameworks ab.

Quellen: