Serverlos durch die Nacht

Serverless: Grundlagen, Best Practices & Anwendungsfälle

Frank Pientka

©iStock/INGREYPX0835

Durch die Cloud und die Virtualisierung lassen sich enorme Fortschritte beim Betrieb von Infrastrukturen erzielen. Erst leichtgewichtige Container machen Microservices möglich. Der nächste logische Schritt ist dann, Services ohne Server umzusetzen. Denn wie der CTO von Amazon Werner Vogels so treffend sagte, ist kein Server einfacher zu managen als gar kein Server. Statt sich weniger um die Infrastruktur zu kümmern, kann man sich mehr auf die Fachwissenschaft konzentrieren. Trotz allem gibt es beim Serverless Computing einiges zu beachten und den passenden Anwendungsfall zu finden.

Als bei Amazon 2006 die ersten drei Amazon Web Services veröffentlicht wurden, hätte niemand gedacht, wie weit sich das Thema Cloud-Dienste entwickeln würde. Inzwischen sind allein bei AWS daraus über neunzig Dienste geworden, sodass es immer schwieriger ist, darüber einen Überblick zu gewinnen oder deren Details zu kennen. Die klassischen Grenzen zwischen Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) verschwimmen spätestens mit der Verwendung von Container as a Service (CaaS). Gleiches gilt für die Dienste der Alternativanbieter, wie Microsoft Azure, IBM Bluemix oder Google Cloud.

Abb. 1: Wie entwickelt sich die Computerinfrastruktur weiter?

Abb. 1: Wie entwickelt sich die Computerinfrastruktur weiter?

Acht Jahre nach dem Start der Amazon Web Services wurde 2014 AWS Lambda vorgestellt und damit der Begriff des Serverless Computings populär gemacht. Inzwischen hat die Beratungsfirma ThoughtWorks das Thema „Serverlos“ in ihrem Technologieradar aufgenommen und in einem Grundlagenartikel von Mike Roberts beschrieben.

Was ist eine serverlose Datenverarbeitung?

Serverlos bedeutet nicht, dass für die Ausführung von Funktionen gar keine Server mehr benötigt werden. Doch wie bei den anderen XaaS-Modellen verschiebt sich bei dem zugrunde liegenden FaaS-Modell (Function as a Service), was Wartung oder Skalierbarkeit betrifft, die komplette Verantwortung auf den Anbieter des Diensts. Die Hauptanbieter von FaaS sind neben Amazon Microsoft (Azure Functions) Google (Functions) und IBM (OpenWhisk). Insofern runden FaaS-Angebote das bestehende IaaS-, PaaS- und CaaS-Angebot der Provider ab und bauen massiv auf deren Ökosystem auf.

Abb. 2: Container, Platform, Function as a Service: die Grenzen verschwimmen

Abb. 2: Container, Platform, Function as a Service: die Grenzen verschwimmen

Der Entwickler kann sich bei Serverless rein auf das Erstellen der fachlichen Funktion konzentrieren. Damit eine serverlose Funktion gut skalieren und auf Ereignisse reagieren kann, gibt es einige Randbedingungen zu beachten. Als Erstes kann so eine Funktion keinen eigenen Zustand haben, sondern muss dazu weitere Backend-Dienste nutzen. Auch die Codegröße, der genutzte Speicher und die Ausführungszeit sind begrenzt. Was die unterstützten Ereignisse und Programmiersprachen betrifft, gibt es bei den verschiedenen Anbietern Unterschiede. Der grundsätzliche Vorteil von FaaS ist, dass wirklich nur der reine Verbrauch abgerechnet wird und nicht schon ein Grundpreis für die Bereitstellung wie bei den anderen XaaS-Angeboten. Oft wird man jedoch mit einem Mischpreis konfrontiert, da FaaS auch andere Dienste nutzt, die meist anders abgerechnet werden. Je nach Nutzung, ist FaaS dann auch nicht immer die günstigste Variante, sondern es hängt ganz vom Anwendungsfall und dessen Nutzungsprofil ab. Ein weiterer Vorteil von FaaS ist auf jeden Fall, dass man sich auch nicht um Wartung, Aktualisierung oder Skalierung dieser Dienste kümmern muss.

Der typische Aufbau einer Serverless-Computing-Architektur zeigt Abbildung 3. Es gibt eine Funktion, die aufgrund eines Ereignisses in einem bestimmten Kontext gestartet wird und Geschäftslogik oder andere Backend-Dienste (Backend as a Service) aufruft. Dessen Ergebnis wird dann asynchron zurückgeliefert. Es kann jedoch auch nur der Start eines Batchprogramms sein. Wer sich noch an Stored Procedures und Trigger bei relationalen Datenbanken erinnert, wird hier einige Ähnlichkeiten, aber auch entscheidende Unterschiede feststellen. Selbst wenn serverlose Daten in derselben Programmiersprache erstellt werden, sind sowohl die genutzten APIs, die Events als auch die Deployment- und Überwachungsprozesse von der jeweiligen Plattform abhängig.

Abb. 3: PaaS = FaaS + BaaS

Abb. 3: PaaS = FaaS + BaaS

Anwendungsfälle für serverlose Datenverarbeitung

Grundsätzlich lässt sich FaaS für alle Anwendungsfälle einsetzen, zu denen es bereits Dienste in der Cloud gibt. Sie bieten sich jedoch für spezialisierte Webdienste, z. B. zum Umcodieren von Inhalten und für die Anbindung der Backend-Dienste für mobile oder Internet-of-Things-Anwendungen an. Sie lassen sich auch gut mit kognitiven Diensten kombinieren, wie Sprach- oder Bilderkennung, da diese eh nur mit und in der Cloud sinnvoll einsetzbar sind.

Eine wichtige Voraussetzung ist, dass die Events zum Aufruf oder zum Anstoßen von weiteren Funktionen unterstützt werden. Hier deckt AWS Lambda durch die hohe Reife von AWS das größte Spektrum ab. Mit AWS Lambda, Amazon API Gateway, Amazon S3, und Amazon DynamoDB kann man serverlose Webanwendungen und Backends erstellen und so Web-, Mobil-, IoT- und Chatbot-Anfragen bearbeiten. In folgendem Beispiel werden vier Lambda-Funktionen verwendet, um eingehende und ausgehende Daten vorzuverarbeiten und auf entsprechende Ereignisse zu reagieren. Die eigentliche Arbeit machen dann die PaaS-Dienste von AWS, wie S3 für die Ablage von Medieninhalten, DynamoDB zum Speichern der Daten, Simple Notification Service (SNS), um abhängig von bestimmten Bedingungen Push-Nachrichten für die jeweiligen mobilen Geräte zu erzeugen, und abschließend Cloud Search, das neue Daten indiziert und über Suchabfragen wieder zur Verfügung stellt. Das API-Gateway ist das zentrale Element, das alle eingehenden und ausgehenden Anfragen verwaltet, bis auf die SNS-Nachrichten. Ein weiteres Einsatzgebiet ist die Echtzeitverarbeitung von Big Data Streams oder auch die Batchverarbeitung mit MapReduce-Jobs. Mit AWS Lambda, Amazon Kinesis, Amazon S3 und Amazon DynamoDB kann man verschiedene Echtzeit-Datenverarbeitungssysteme erstellen.

Abb. 4: Die Referenzarchitektur eines Serverless-Mobile-Backends mit AWS Lambda (Quelle: AWS)

Abb. 4: Die Referenzarchitektur eines Serverless-Mobile-Backends mit AWS Lambda (Quelle: AWS)

Die Cloud und die kleinen Geräte: Edge Computing

Der nächste größere Schritt beim Cloud-Computing ist Edge Computing. Zunächst war mit Content Delivery Networks (CDN) das Ziel, statischen Content möglichst nah und schnell an den jeweiligen Aufrufer auszuliefern. Dadurch, dass die kleinen Geräte immer leistungsfähiger werden, können sie dazu genutzt werden, Daten vor der Übertragung entsprechend aufzubereiten, oder auch eine gewisse Zeit ohne Netzverbindung weiterzuarbeiten. Damit lassen sich auch bestimmte Sicherheitsanforderungen erfüllen, welche die personenbezogene Weiterverbreitung und Übertragung von sensiblen Daten in der Cloud verbietet. Edge Computing ist also eine gute Ergänzung zur klassischen serverorientierten Cloud-Verarbeitung. Gerade für eine datenintensive, datensensible und zeitkritische Verarbeitung vor Ort lässt sich Edge Computing gut einsetzen. Kein Wunder, dass einige Anbieter wie Microsoft, IBM oder Amazon entsprechende erste Entwicklungs- und Ablaufumgebungen für die lokale Entwicklung und Verarbeitung anbieten.

IBM hat OpenWhisk unter dem Apache-Dach veröffentlicht. Als einziges der FaaS-Angebote ist es nicht nur unter einer Open-Source-Lizenz veröffentlicht, sondern basiert auch ausschließlich auf Open-Source-Produkten, wie Docker, Consul, CouchDB, nginx und Kafka. In Zukunft soll auch Kubernetes unterstützt werden. Dadurch ist es möglich, OpenWhisk auch ohne Cloud On-Premises selbst zu betreiben und anzupassen. Mag das für die Entwicklung Vorteile bringen, da man nicht von langsamen Netzen abhängig ist, so muss man sich dann wieder um die Verwaltung der FaaS-Umgebung kümmern. Gerade bei Daten, die einen hohen Datenschutzbedarf haben, ist sicher auch die Kombination zwischen lokaler und entfernter Verarbeitung sinnvoll.

Abb. 5: OpenWhisk nutzt Open-Source-Produkte

Abb. 5: OpenWhisk nutzt Open-Source-Produkte

Ein ähnliches Einsatzgebiet unterstützt seit Kurzem Azure Functions Runtime. Diese läuft als Hyper-V-Container unter Windows Server 2016 oder Windows 10 mit dem SQL Server oder auch auf dem On-Premises Azure Stack. Für Kubernetes gibt es mit Fission ein eigenes kleines Serverless Framework, das Node.js, Go, C# und PHP unterstützt. Ebenso gibt es mit Spring Cloud Function, das auf Spring Boot basiert, Adapter für Apache OpenWhisk und AWS Lambda, die es auch mit Spring ermöglichen, lokal serverlose Anwendungen zu entwickeln und dann in die Cloud zu deployen. Eine Spring Cloud Function kann entweder ein HTTP-Endpunkt oder ein Stream-Prozessor für Messaging-Syteme wie RabbitMQ, Apache Kafka oder ein anderer JMS-Anbieter sein.

In der hybriden Cloud wächst vieles zusammen

Das zeigt, dass Private und Public Cloud immer mehr zusammenwachsen und miteinander kombinierbar sind. Jedoch hat diese Heterogenität ihren Preis, sodass man sich oft auf den kleinsten gemeinsamen Nenner einigen muss und in einer On-Premises-Umgebung trotz Containertechnik immer noch einen Verwaltungsaufwand hat und auch bei der Elastizität schnell an Ressourcengrenzen stoßen kann.

Für eine lokale Entwicklung unterstützt AWS neben der CLI-Schnittstelle auch die Entwicklungsumgebungen Eclipse mit einem eigenen Plug-in. Die Funktionen müssen jedoch in AWS Lambda deployt werden, um dort ausgeführt und getestet zu werden. Da so auch AWS-Dienste lokal nicht genutzt werden können, gibt es inzwischen einige Erweiterungen, die zumindest die Simulation mit Mocks eingeschränkt ermöglichen.

Das bekannte Serverless Framework, das ursprünglich unter dem Namen JAWS für AWS-Dienste entwickelt wurde, erleichtert das Deployment und Testen von Lambda-Diensten. Dadurch, dass das Serverless Framework erweiterbar gestaltet ist, gibt es einige nützliche Erweiterungen, wie das Serverless Offline Plugin oder das Serverless simulation plugin, welche die Entwicklung von Lambda-Funktionen erleichtern. Das Serverless Framework unterstützt nicht nur AWS Lambda, sondern auch Azure Functions, OpenWhisk und Google Functions. Da jedoch die Anfänge bei AWS lagen, hinkt die Unterstützung der anderen Plattform in der Funktionalität etwas hinterher. Es ist jedoch möglich, das Deployment bei der Verwendung von mehreren FaaS-Plattformen etwas zu erleichtern. Eine große Hilfe, gerade was die Definition und die Konfiguration der genutzten AWS-PaaS-Dienste betrifft, ist das AWS Serverless Application Model (SAM), das auf AWS CloudFormation beruht. Damit wird das Deployment nicht nur der Lambda-Funktion, sondern aller von ihr benötigten Dienste erleichtert und erst eine Automatisierung ermöglicht.

Grenzen und Best Practices

Doch wo Licht ist, da ist auch Schatten. Durch die Einschränkung der Ressourcennutzung sind erst kurze Reaktions- und Verarbeitungszeiten möglich. Dadurch, dass die serverlosen Funktionen keinen eigenen Zustand halten, bedeutet es, dass andere Backend-Dienste sich gegebenenfalls darum kümmern müssen. Sollen Funktionen wirklich nur einmal in Abhängigkeit vom Ergebnis einer anderen Funktion aufgerufen werden, braucht man Verfahren, um damit umzugehen. Bereits aus der asynchronen Nachrichtenverarbeitung sind uns hier Muster und Protokolle bekannt, um mit Ausfällen umzugehen, eine Mehrfachauslieferung zu vermeiden oder eine bestimmte Reihenfolge einzuhalten. Beim Bau von serverlosen Architekturen können die fünf im Buch „Serverless Architectures on AWS“ von Peter Sbarski beschriebenen Muster für Command, Messaging, Priority Queue, Fan-out, Pipes und Filter hilfreich sein [1].

Ein Nachteil gerade für Kunden, die eine hybride oder Multi-Cloud-Strategie fahren, ist gewiss, dass sie sich, egal für welche FaaS-Lösung sie sich entscheiden, abhängig vom jeweiligen Anbieter machen. Obwohl die Produkte unter einer Open-Source-Lizenz stehen, ist es, bis auf Apache OpenWhisk, nicht möglich, sich an der Weiterentwicklung zu beteiligen oder den Code bei einem anderen Anbieter wiederzuverwenden. Denn je mehr und je tiefer Dienste von einem Anbieter genutzt werden, umso schwieriger wird ein späterer Wechsel. Ein wenig fühlt man sich dabei an den Rocksong der Eagles „Hotel California“ erinnert. Der erste Einstieg ist schnell erledigt, doch wer einmal eincheckt, der kommt nie wieder oder nur sehr schwer wieder raus.

Einen interessanten Ansatz für IoT-Anwendungen geht Amazon mit AWS Greengrass. Damit können speziell einige kompatible IoT-Geräte AWS-Lambda-Funktionen in Python lokal unter Linux ausführen. AWS Greengrass besteht aus der Ablaufumgebung Greengrass Core und dem erweiterten AWS IoT Device SDK für C++. Neben OpenSSL wird auch das MQTT-Protokoll unterstützt. Als lokale Datenbank wird SQLite verwendet. So lassen sich Datenverarbeitungs-, Messaging-, Caching- und Synchronisierungsfunktionen lokal ausführen.

Ausblick

Serverlose Funktionen sind oft preislich eine gute Ergänzung zu bestehenden Cloud-Diensten. Backend-Dienste werden immer noch benötigt. Besonders geeignet sind serverlose Funktionen in neuen Anwendungsbereichen, wie IoT, Big Data oder künstlicher Intelligenz. Da solche Anwendungsfälle meist eh in und mit der Cloud stattfinden, bietet es sich an, auch fachliche Erweiterungen dort umzusetzen. Dadurch, dass alle Anbieter inzwischen auch die Möglichkeit anbieten, serverlose Funktionen zusätzlich zur Cloud, in Teilen auch lokal in selbst kontrollierten Umgebungen ablaufen zu lassen, erschließt sich die Cloud mit Edge Computing neue Einsatzbereiche. Viele IoT-Anwendungsfälle lassen sich ohne lokale Verarbeitungskomponenten gar nicht umsetzen. Das gilt sowohl aus technischen als auch aus rechtlichen und finanziellen Gesichtspunkten. Trotz des jungen Alters haben serverlose Funktionen eine große Reife erreicht, auch wenn sie vielleicht nicht so eine große öffentliche Aufmerksamkeit haben. Sie haben ein großes Potenzial. Insofern ist es sinnvoll, sich mit deren Stärken und Grenzen zu beschäftigen und sie in geeigneten Anwendungsfällen einzusetzen. Welchem Anbieter man den Vorzug gibt, hängt sicher damit zusammen, bei wem man bereits die meisten Dienste laufen hat und wo man das meiste Know-how und Potenzial für die eigene Zukunft sieht. Insofern sind serverlose Funktionen eine logische und sinnvolle Erweiterung der bestehenden Cloud-Angebote. Gerade durch den IoT-Bereich wachsen Cloud- und Edge Computing immer mehr zusammen, sodass jeder seine spezifischen Stärken ausspielen kann. Erst dadurch werden neue Anwendungsfälle umsetzbar und bezahlbar.

Geschrieben von
Frank Pientka
Frank Pientka
  Frank Pientka ist Senior Architect bei der MATERNA GmbH in Dortmund. Er ist seit mehreren Jahren im Bereich Java EE tätig. Seine Schwerpunkte sind Applikationsserver, Portalserver und Datenbanken. Dazu hat er auch schon mehrere Fachartikel und ein Buch über Geronimo veröffentlicht.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: