Serverless Computing braucht moderne Datenbanken

Serverless Computing beschreibt das Prinzip, Applikationen unabhängig von der Server-Infrastruktur zu schreiben, auf der sie entwickelt und betrieben werden. Die Entwickler müssen sich nicht mehr um die Hardware-Ressourcen kümmern, auf denen ihre Apps laufen sollen. Server-Funktionen wie Verwaltung, Provisionierung, Skalierung oder Updates übernimmt der Provider. Die entsprechenden Compute- und Storage-Services werden stattdessen von Hyperscalern bereitgestellt.

Im Gegensatz zu Platform-as-a-Service (PaaS) werden bei Serverless Computing keine Cloud-Instanzen für bestimmte Microservices bereitgestellt, sondern ereignisgesteuert lediglich Ad-hoc-Ergebnisse für einzelne, hochparallelisierbare Funktionen zurückgegeben. Damit besitzt Serverless Computing ein nochmal höheres Abstraktions- und Virtualisierungsniveau als PaaS. Die App-Funktionen werden containerisiert und lauern so lange untätig im Hintergrund, bis sie eventgesteuert aufgerufen werden und nach Ausführung und Ergebnisausgabe wieder in den „Schlaf“-Modus gehen. Die dafür notwendigen Ressourcen werden dynamisch zugewiesen. By the way: Serverless-Apps und Microservices können auch kombiniert werden, sozusagen als hybride Mischform.

Für Serverless Computing werden drei Dinge gebraucht: API Gateways, FaaS (Function as a Service) und Backend-as-a-Service (BaaS). Das API Gateway ist die Verbindung und der Kommunikations-Layer zum Frontend. Aktuell übernimmt das Gateway auch das Mapping der Funktionen mit den REST APIs und macht sie so als REST-Interface, etwa für Java-Applikationen, nutzbar. Da keine konkreten Server angesprochen werden entfällt zudem die Notwendigkeit von Load Balancern. Auch deren Funktion wird vom Compute Service des Cloud-Providers übernommen. Im FaaS-Layer einer Serverless-Architektur wird eventgesteuert die in Containern bereitgestellte Business Logik der Applikation ausgeführt, sobald über das Gateway eine entsprechende Aktion ausgelöst wird.

Die bekanntesten FaaS-Provider sind AWS Lambda, Azure Functions, Google Cloud Functions und IBM Cloud Functions. Sie unterscheiden sich zwar in Funktionsumfängen ihrer Services. Letztlich ist es jedoch egal, bei welchem Cloud Provider die App gehostet wird. In der Praxis ist allerdings eine gewisse Abhängigkeit von dem einmal gewählten Cloud-Provider durch den Kontrollverlust über Teil der IT-Infrastruktur nicht auszuschließen (Vendor Lock-in). Ein Provider-Wechsel kann zudem umfangreiche Code-Änderungen erforderlich machen.

Bei den prädestinierten Einsatzszenarien für Serverless Computing taucht oft der kurzfristige Datenaustausch von Web- und Business-Anwendungen in der Cloud auf. Nicht zuletzt daher kommt der Datenbank eine elementare Rolle zu. Das Datenmanagement erfolgt in einer Serverless-Struktur als Database-as-a-Service (DBaaS). DBaaS ist dabei funktional ein Teil des BaaS-Layers. Serverless Computing ist per Definition Cloud-native – eigentlich sogar Cloud-native im Quadrat, da es abgesehen von den bereits erwähnten Einschränkungen, prinzipiell Cloud-agnostisch arbeitet. Allein diese Cloud-Affinität spricht bereits dafür, für Serverless Computing eine NoSQL-Datenbank zu nutzen. Das Cloud-native NoSQL-Datenmodell arbeitet nicht mit der starren Tabellen-Struktur (Zeilen-Spalten-Schemata) relationaler SQL-Datenbank-Systeme, sondern mit JSON-Dokumenten. Zudem sind NoSQL-Datenbanken keine monolithischen Systeme. Durch das flexible Datenmodell und die verteilte Architektur können sie die nochmals gesteigerten Anforderungen nach Agilität und Skalierbarkeit bei Serverless Computing leichter erfüllen. Zudem reduziert das Cloud-basierte Distributionsmodell die Kosten für die Datenbank-Administration. Trotzdem ist es auch in diesem Kontext sinnvoll, wenn die NoSQL-Datenbank die Arbeit mit SQL-Statements gestattet. Diese standardisierte Abfragesprache ist aufgrund ihrer langen „Lebensdauer“ die mit überwältigendem Abstand verbreitetste. Entsprechendes Know-how kann also in diesem Fall auch für den Datenbank-Einsatz bei Serverless Computing weiterhin genutzt werden.

Eine Serverless-Datenbank entbindet den Entwickler von der Kapazitätsplanung, der Provisionierung und dem Management der Infrastruktur. Die Skalierung von Compute- und Storage-Ressourcen nach oben und unten erfolgt on Demand, stufenlos und – zumindest theoretisch – unendlich. Sobald eine Applikation mehr Ressourcen benötigt, wird automatisch und feingranular skaliert. In PaaS-Umgebungen dagegen erfolgt die Skalierung der Instanzen in Stufen, die meist nicht voll ausgeschöpft, aber trotzdem voll bezahlt werden müssen. Bei Serverless Computing wird dagegen nur die echte Ressourcen-Nutzung abgerechnet. Eine wichtige Eigenschaft von Serverless-Datenbanken ist auch die Multitenant- oder Mandantenfähigkeit.

Für Entwickler ist Serverless Computing ein Segen, denn es reduziert den Aufwand für das Handling komplexer Server-Operationen drastisch. Das verkürzt die Entwicklungszeit neuer Applikationen. Gleichzeitig senkt es die Betriebskosten, da nur für die tatsächliche Nutzungszeit von Storage- und Compute-Ressourcen für die Funktions-Container bezahlt wird. Dabei darf nicht vergessen werden, dass die Implementierung von Serverless Computing aufwändig sein kann und viel spezifische Expertise benötigt. Aber es lohnt sich.

Gregor Bauer ist Senior Solutions Engineer Central Europe bei Couchbase