Functions as a Service mit OpenWhisk
Funktional verquirlt
OpenWhisk liegt eine ereignisgesteuerte Architektur zugrunde. Die lokal installierbare Cloud-Plattform führt Code als Antwort auf Ereignisse oder Aufrufe aus.
Functions as a Service (FaaS) haben sich in der letzten Dekade von einem Forschungsthema zu einer etablierten Kategorie von Cloud-Diensten entwickelt. Branchengrößen wie Amazon mit dem Dienstangebot Lambda, Microsoft mit Azure Functions, Google mit Cloud Functions und IBM mit Cloud Functions haben zur Verbreitung dieses Cloud-Dienstkonzepts beigetragen. Die Bereitstellung von Funktionen in der Cloud hat zu einer Entwicklung weg von der Einrichtung von Infrastrukturen geführt und den Fokus wieder zurück auf den fundamentalsten Baustein eines jeden Cloud-Dienstes gelegt, nämlich den Quellcode.
Ein freies und leistungsfähiges Framework zur Realisierung eines eigenen FaaS ist das von der Apache Software Foundation betreute und von IBM propagierte OpenWhisk. Es zeichnet sich durch Skalierbarkeit, eine robuste Architektur, umfangreiche Dokumentation und die Unterstützung zahlreicher Programmiersprachen aus. Hauptaufgaben von FaaS-Software sind die Entwicklung und der Betrieb skalierbarer Microservices. OpenWhisk übernimmt dabei die Skalierung und Koordination der Funktionsaufrufe.
Unabhängig bleiben
Ein großes Problem bei der Nutzung öffentlicher Dienstangebote ist die potenzielle Gefahr des Vendor-Lock-in. Hierbei kommt es zu einer Abhängigkeit zwischen Dienstnutzer und -anbieter, bei der der Kunde nicht oder nur um den Preis des Verlusts seiner Infrastruktur und seiner Daten zu einem anderen Anbieter wechseln kann. Denkbare Szenarien sind Preiserhöhungen oder eine Insolvenz des Anbieters. Die Gefahr des Lock-in ist immer dann gegeben, wenn die eingesetzten Dienste nicht kompatibel zu anderen Anbietern sind und es keine Möglichkeit zum Datenexport (bei gleichzeitigem Fehlen eines lokalen Datenabbildes) gibt. Weitere Gründe, die dem Einsatz öffentlich zugänglicher Cloud-Dienste im Weg stehen können, sind der Datenschutz beim Verarbeiten personenbezogener Daten (etwa im medizinischen Bereich) und Sicherheitsbedenken bei wertvollen Daten im industriellen und forschungsbezogenen Umfeld. OpenWhisk ist freie Software. Die öffentlichen Dienstangebote IBM Cloud Functions und Adobe I/O Runtime basieren darauf. Es besteht bei einer Ausrichtung der eigenen Arbeit auf OpenWhisk keine Gefahr für ein Lock-in.
Das OpenWhisk-Framework unterstützt interpretierte Sprachen wie JavaScript, Python, PHP, Ruby oder Swift. In diesen Sprachen geschriebene Programme können als Quellcode in OpenWhisk importiert werden.
Kompilieren oder nicht
Der Einsatz kompilierter Programmiersprachen wie Go, C oder C++ erfordert es, den Quellcode für die Hardwarearchitektur der genutzten OpenWhisk-Plattform vor dem Hochladen zu kompilieren. Bei IBM Bluemix und der Mehrheit der heutzutage eingesetzten Serversysteme ist das x86-64, im Linux-Umfeld als AMD64 bezeichnet. Auch Java-Programme müssen vor dem Hochladen kompiliert und als Java Archive (JAR-Datei) verpackt werden. Die Architektur der Zielplattform spielt dabei keine Rolle.
Die Programmiersprache Swift nimmt eine Sonderstellung ein. Obwohl eine kompilierte Programmiersprache, kann sie als unkompilierter Quellcode in OpenWhisk geladen werden.
Eine erstmalig gestartete Funktion – in OpenWhisk Aktion genannt – bewirkt die Kompilierung von Quellcode. Dieser Kaltstart lässt sich umgehen, indem Entwickler den Quellcode von Programmen in Swift lokal kompilieren und als ausführbare Datei hochladen.
Wie OpenWhisk aufgebaut ist
Die Architektur von OpenWhisk ist auf eine hohe Anzahl von Aufrufen ausgelegt und bietet eine hohe Verfügbarkeit (Abbildung 1). Zu diesem Zweck enthält OpenWhisk einen nginx-Webserver. Dieser Webserver dient als Reverse Proxy und nimmt alle HTTP(S)-Aufrufe entgegen. Er reicht die Anfragen an den Controller weiter, der eine REST-Schnittstelle bereitstellt. Dabei stellt der Controller fest, um was für eine Art von Aufruf es sich handelt, und leitet darauf basierend weitere Schritte ein. So führt eine POST-Anfrage eine Aktion im Service aus. Der Controller integriert einen eigenen Load Balancer, der die Funktionsaufrufe an eine geeignete Instanz weiterleitet. Bevor er zum Einsatz kommt, erfolgt eine Anfrage an die Datenbank CouchDB.