Serverless Architekturen – Chancen und Risiken

Serverless-Computing - ein beinahe paradoxer Begriff. Ein genauer Blick zeigt jedoch, dass es sich hier lediglich um eine Abstraktionsebene handelt. Serverless bedeutet nicht, dass Server verschwinden, sondern lediglich, dass man sich nicht aktiv mit ihnen beschäftigen muss. Die Containerisierung hat die IT-Welt bereits im Sturm erobert. In den letzten Jahren hat sich gezeigt, dass das Serverless-Konzept zumindest das Potenzial hat, noch einen Schritt weiterzugehen. Allerdings müssen in der Architekturplanung ein paar grundlegende Konzepte beachtet werden.

Die Cloud verspricht nahezu unbegrenzte Rechen- und Speicherkapazität. Dieses Versprechen ist auf den beiden Säulen "Automatisierung" und "Abstraktion" aufgebaut. Zum einen können Ressourcen durch API-Calls automatisch angefordert und freigegeben und somit lange Beschaffungsprozesse gespart werden. Zum anderen bieten Cloud-Anbieter Infrastrukturen auf verschiedenen Abstraktionsstufen an, die einem unterschiedlich viel Arbeit und Verantwortung, aber auch Kontrolle abnehmen.

Der Begriff Serverless wird üblicherweise im Kontext der Anwendungsentwicklung verwendet. Nach einer Definition von IBM [1] handelt es sich um ein "Entwicklungs- und Ausführungsmodell, welches die Entwicklung von Anwendungen ohne Provisionierung oder Management von Infrastruktur ermöglicht". Dieser griffige Satz stellt bereits ein wichtiges Merkmal heraus: Die Entwickler:innen müssen sich keine Gedanken mehr um Server machen. Das geht aber noch nicht weit genug. Beispielsweise würde so auch das gemanagte Kubernetes-Angebot von Google (GKE) dazu gehören, bei dem wir uns allerdings über die Anzahl verfügbarer Knoten und Kapazitäten Gedanken machen müssen.

Zur Beurteilung, ob es sich bei einem Cloud-Service um ein Serverless-Angebot handelt, hat sich eine Reihe weiterer Kriterien etabliert. Der "Lackmustest für Serverless" von Khawaja Shams und Kirk Kirkconnell von Momento fasst sie sehr gut zusammen [2]:

1. Keine Provisionierung oder Verwaltung. Ein Serverless-Service muss nicht aktiv hochgefahren werden. Die Verwaltung und Wartung übernimmt der Cloud-Anbieter. Es muss auch keine Kapazität im Voraus angefordert oder automatische Skalierung konfiguriert werden.
2. Nutzenbasierte Abrechnung ohne Grundkosten. Der Service verursacht Kosten in Abhängigkeit von der tatsächlichen Nutzung - also z.B. tatsächliche Ausführungszeit von Code, Lese-/Schreib-Operationen, verbrauchter Speicherplatz. Es gibt keine Grundgebühr und man bezahlt auch nicht für ungenutzte Rechenressourcen.
3. Bereitstellung über einen API-Call. Eine vom Service angebotene Ressource kann durch einen einfachen programmatischen API-Aufruf angefordert werden.
4. Keine geplante Downtime. Es gibt keine geplanten Wartungsfenster - alles, was hinter den Kulissen zur Wartung der zugrunde liegenden Infrastruktur notwendig ist, erledigt der Cloud-Anbieter im Hintergrund ohne Einfluss auf die Kunden.
5. Keine Instanzen. Das Wort "Instanz" ist meist nur eine sehr dünne und direkte Abstraktion auf einen zugrunde liegenden Server. Kapazität oder Skalierung ist keine Fragestellung für die Entwicklung oder den Betrieb mehr, sondern der Cloud-Anbieter kümmert sich darum.

Diese Kriterien verdeutlichen, dass es bei Serverless um ein "Mindset" in der Anwendungsentwicklung geht. Serverless-Architekturen ermöglichen Entwickler:innen einen Fokus auf die Anwendungslogik: In der extremsten Ausprägung schreibt man nur noch die Logik und der Cloud-Anbieter übernimmt dann das Verpacken, Deployen und Verwalten. Als Serverless-Entwickler:in ist man bestrebt, die Benefits der obigen Kriterien bestmöglich mit seiner Architektur zu erschließen.

Serverless ermöglicht eine Fokussierung auf das Wesentliche: die Entwicklung von Geschäfts- und Integrations-Logik. In klassischen IT-Umgebungen gibt es üblicherweise eine Betriebsabteilung, deren Aufgabe das Sicherstellen einer störungsfreien Verfügbarkeit der eigenen Anwendungen ist. Serverless-Angebote reduzieren die Aufgaben des klassischen Betriebs, der sich nun nicht mehr um Betriebssystemupdates, Skalierung und Infrastruktur kümmern muss. Die freiwerdenden Ressourcen können nun anderweitig, beispielsweise zur Entwicklung von Integrationskonzepten in einer komplexer werdenden Service-Landschaft oder zur Sicherstellung von Observability und Monitoring eingesetzt werden. Hierbei handelt es sich in der Regel um Herausforderungen, die Unternehmens- und Systemspezifika betreffen und damit individuell für jede Organisation zu lösen sind. Um wiederkehrende Tätigkeiten, die nicht unternehmensspezifisch sind, kümmert sich der Cloud-Anbieter.

Neben der Fokussierung bietet das Serverless-typische Pay-per-Use-Abrechnungsmodell eine potenzielle Kostenreduktion. Wenn sich die Kosten direkt an der tatsächlichen Nutzung ausrichten, muss man keine Kapazitäten provisorisch vorhalten, um Lastspitzen wie dem E-Commerce-Ansturm zum Black Friday standhalten zu können. Man bezahlt auch nicht mehr für einen wartenden Server, auf dem eine Anwendung nur gelegentlich HTTP-Requests beantwortet. Nicht alle IT-Systeme passen in dieses Muster und könnten von einer Kostenreduktion profitieren. Ein Server, der bei gleichbleibender Auslastung kontinuierlich Batch-Jobs abarbeitet, ist meist kein guter Kandidat zur Ablöse durch eine Serverless-Anwendung. Zwar orientiert sich die Abrechnung für serverlose Rechenkapazität meist auf Millisekunden genau am tatsächlichen Bedarf, der Preis pro CPU-Sekunde ist dafür jedoch typischerweise höher als der Preis pro Sekunde für einen virtuellen Server mit der gleichen Rechenkapazität.

Das Preismodell ist auch noch aus einem anderen Grund interessant: Da die Abrechnung direkt der Ausführung eines bestimmten Code-Teils oder einem Service-Aufruf zugeordnet werden kann, kann man theoretisch Kosten direkt einem einzelnen Geschäftsvorfall zuordnen. Lassen sich die Betriebskosten für einen Online-Shop beispielsweise für jeden beliebigen HTTP-Request aufschlüsseln, kann die User Journey eines Kunden auf der Plattform genau bepreist werden. Diese Transparenz der gesamten Supply Chain eines Geschäftsvorfalls ist mit klassischen Betriebsmodellen nur näherungsweise möglich.

Die automatische Skalierung von Rechen- und Speicherkapazität ist sicherlich eine der beeindruckendsten Leistungen vieler Serverless-Technologien - insbesondere für diejenigen, die schon einmal versucht haben, Skalierung und Ausfallsicherheit von Services auf herkömmlichen Servern, virtuellen Maschinen oder auch nur innerhalb eines Kubernetes-Clusters sicherzustellen. In typischen Serverless-Architekturen sind Systeme zudem stark verteilt und erstrecken sich auf viele unabhängige Deployment-Einheiten, wie zum Beispiel Funktion, auf die wir im folgenden Absatz zu sprechen kommen. Diese ermöglichen nicht nur eine automatische Skalierung des Gesamtsystems, sondern eine differenzierte Skalierung der einzelnen Funktionseinheiten und somit weitere Optimierungspotenziale.

Stand heute haben die drei großen Cloud Anbieter - Amazon Web Services (AWS), Google Cloud Platform (GCP) und Microsoft Azure (Azure) - die bekanntesten Serverless-Angebote in ihrem Portfolio. Im Compute-Bereich, also der Bereitstellung von Rechenleistung, gibt es mit "Functions-as-a-Service" (FaaS) besonders prominente Angebote. Ein FaaS-Angebot nutzt das Konzept der Funktion als Deployment-Einheit. Eine Funktion ist eine Code-Einheit, die idealerweise genau eine Aufgabe erledigt. Sie wird zum FaaS-Anbieter hochgeladen und durch definierte Ereignisse ausgelöst (z.B. ein eingehender HTTP-Request oder eine Dateiänderung in einem Storage-Bucket). Liegt ein solches Ereignis vor, kümmert sich die Cloud-Plattform automatisch um die Bereitstellung und Ausführung der Funktion. Entstehen in kurzer Zeit viele Ereignisse, werden automatisch genauso viele parallel lauffähige Funktionen gestartet und hinterher wieder gestoppt.

Bei AWS heißt das FaaS-Angebot "Lambda", bei GCP "Cloud Functions" und bei Azure einfach "Azure Functions". Es gibt auch noch weitere Anbieter, wie z.B. Cloudflare mit den "Workers". Zu erwähnen ist noch, dass es bei Google mit "Cloud Run" auch noch ein weiteres Serverless-Compute-Angebot gibt. Cloud Run ist ein Hybrid, da hier vollständige Container deployt werden können und sich die Plattform genau wie bei den Cloud Functions im Hintergrund um Ausführung und Skalierung kümmert. Ein Container, der zwischen der Abarbeitung von Ereignissen oder Requests nichts zu tun hat, wird automatisch gestoppt und verursacht bis zum nächsten Request keine Kosten. Cloud Run besteht also den Serverless-Lackmustest. Mit ein paar Einschränkungen ist bei AWS Lambda mittlerweile auch die Verwendung eigener Container-Images möglich.

Neben der Rechenleistung gibt es weitere Services, die man zur Anwendungsentwicklung benötigt und die den Serverless-Lackmustest bestehen. Alle drei großen Cloud-Anbieter bringen zum Beispiel ihre eigenen Serverless-NoSQL-Datenbanken mit (DynamoDB bei AWS, Cloud Firestore bei Google und CosmosDB bei Azure). Praktisch zur Orchestrierung von Funktionen sind weiterhin Queues (SQS, Google PubSub, ...), State-Maschinen (AWS StepFunctions), API-Gateways und Object-Storage (S3, Google Cloud Storage). All diesen Services ist gemein, dass man für ihre tatsächliche Nutzung bezahlt (Anzahl Requests oder verbrauchter Speicherplatz) und dass man keine Kapazitäten oder Instanzen vorkonfigurieren muss. Der Übergang zum allgemeinen Terminus "Managed Service" ist hier fließend. Leider wird bei Managed Services oft mit Serverless geworben, aber nicht alle Kriterien erfüllt: "Neptune Serverless" beispielsweise, eine managed Graph-Datenbank von AWS, verlangt die Einstellung von Minimum und Maximum Kapazitätseinheiten, die mit den zugrunde liegenden Instanzen verbunden sind, und ein Minimum von 0 ist nicht möglich. Konsequenz ist eine Art Grundgebühr und man muss im Vorfeld Kapazitäten festlegen - zwei Gründe dafür, dass "Neptune Serverless" den Serverless-Lackmustest nicht besteht.

Die Nutzung von Serverless-Technologien kommt nicht ohne Risiken und Herausforderungen. Diese sind sowohl technischer als auch organisatorischer Natur.

Zunächst führen die typischerweise sehr kleinen Systemkomponenten zu einer starken Verteilung. Um diese beherrschen zu können, bedarf es einer konsequenten Automatisierung und stringenter Dokumentation. Die Verteilung der Geschäftslogik auf einzelne kleine Funktionen, die jeweils ein eigenes Deployment-Artefakt darstellen, ist erst einmal schwieriger zu durchdenken und zu planen als ein klassischer Monolith. Ebenso essentiell ist eine gute Observability. In stark verteilten, ereignisgetriebenen Architekturen kommt eine Systemanalyse über die isolierte Betrachtung von Log-Ausgaben einzelner Funktionen schnell an ihre Grenzen. Ein Tracing von Workloads über das gesamte System wird notwendig und die Observability sollte nicht als nachgelagerter Aspekt kurz vor dem Live-Gang oder gar danach adressiert werden.

Speziell die Entwicklung von FaaS-Architekturen birgt weitere Herausforderungen. Da die Laufzeitumgebung für Funktionen erst einmal nur in der Cloud existiert und spezielle Funktionssignaturen verlangt, erfordert eine lokale Entwicklung entweder eine ständige Remote Verbindung oder passende Emulatoren. Auch die typischerweise umfangreich genutzten Managed Services wie Datenbanken oder Queues lassen sich nicht "mal eben" lokal starten. Als Alternative zu lokalen Emulatoren verlagert sich die Entwicklung von Funktionen zunehmend in Cloud-IDEs und es wird seltener die gesamte Anwendung rein lokal Ende-zu-Ende getestet. Bei der Entwicklung von Serverless-Funktionen bietet sich zudem eine stark testgetriebene Entwicklung unter Zuhilfenahme von Unit-Tests an. Die Integration erfolgt dann nachgelagert nach dem Deployment in die Cloud.

Während der Scale-to-Zero-Ansatz sehr vorteilhaft für Ressourcenverbräuche ist, kommt er mit einer sogenannten Cold-Start-Problematik: Wird eine Funktion für längere Zeit nicht ausgeführt, hält sie der Cloud-Anbieter nicht mehr im Speicher vor und bei der ersten Ausführung kommt es zu einer höheren Latenz, im schlimmsten Fall von mehreren Sekunden. Bei der Entwicklung von User-Interfaces kann man solche Verzögerungen antizipieren und beispielsweise Warte-Animationen anzeigen oder mit optimistischen Updates arbeiten. Allgemein sollte man bei der Ereignis-Verarbeitung die Möglichkeit einer gewissen zeitlichen Latenz bedenken und in die Architekturplanung einfließen lassen.

Das Serverless-Abrechnungsmodell birgt enormes Potenzial für die Optimierung von Cloud-Kosten und Transparenz entlang der gesamten Supply Chain. Allerdings verbergen sich hier auch Risiken: Ohne passende Budgetierung und Einrichtung von Alerts kann es etwa durch Programmierfehler zu Kostenexplosionen kommen, beispielsweise wenn sich Serverless-Funktionen gegenseitig aufrufen und eine Endlosschleife verursachen.

Häufige Bedenken gegenüber Serverless-Technologien sind die Verwendung einer Public Cloud und der Vendor-Lock-In. In der Tat sind viele Services nur in der Public Cloud und anbieterspezifisch verfügbar. Allerdings lässt sich dieses Risiko durch geschickte Kapselung stark eingrenzen. So kann auch eine Migration z. B. von Google Cloud Functions zu AWS Lambda mit vertretbarem Aufwand durchgeführt werden und nur die Persistenz-Adapter und die Ereignis-Datenmodelle müssen angepasst werden.

Eine Kenntnis der Vorteile, Herausforderungen und Risiken von Serverless-Technologien ist bereits eine gute Voraussetzung für eine gelungene Serverless-Architektur. Auf dieser Basis kann man sich an "klassischen" Architektur-Mustern orientieren. Wie bereits angedeutet eignen sich Serverless-Funktionen insbesondere für Microservice-Architekturen. Zwar lässt sich theoretisch auch ein Monolith in eine Lambda-Function auf AWS verpacken, jedoch verliert man dann den großen Vorteil der differenzierten Skalierbarkeit einzelner Funktionseinheiten und die Cold-Start-Herausforderung fällt umso gravierender ins Gewicht.

Ebenso vorteilhaft sind Ereignis-getriebene Architekturen, die eine lose Kopplung der vielen Deployment-Einheiten ermöglichen und von den FaaS-Umgebungen teilweise sogar vorausgesetzt werden.

Eine weitere Vorgabe von Serverless-Umgebungen ist das Prinzip der Zustandslosigkeit: Zwei Ausführungen der gleichen Funktion müssen immer als unabhängig betrachtet werden. Man kann sich nicht darauf verlassen, dass zwischen zwei Funktionsaufrufen Daten im Arbeitsspeicher oder Dateisystem überleben. Zustandsänderungen der Applikation müssen daher beispielsweise in einer Datenbank persistiert werden. Hierüber erklärt sich auch die Bezeichnung als "Funktion": Analog zu einer Funktion in der Mathematik liefert eine Serverless-Funktion immer das gleiche Ergebnis für die gleichen Eingabeparameter. Man "merkt" sich standardmäßig nichts zwischen zwei separaten Ausführungen. Im Kontext der funktionalen Programmierung werden solche Funktionen als "Pure Functions" bezeichnet. Als positive Nebenwirkung ergibt sich hieraus eine leichte Testbarkeit.

Stark verteilte und Ereignis-getriebene Architekturen dieser Art beinhalten in der Regel verschiedene Aspekte von Asynchronität: Eine Funktion, die mit anderen Funktionen kommuniziert und diese auslöst, "publiziert" zu diesem Zweck lediglich ein Ereignis, ohne sich darum zu kümmern, von welcher anderen Funktion und zu welchem Zeitpunkt dieses verarbeitet wird. Als Mediatoren für diese Art von asynchroner Inter-Service-Kommunikation werden in der Regel "Queues" verwendet. Die großen Cloud-Anbieter bieten ausnahmslos solche Queues mit Serverless-Abrechnungs- und Betriebsmodellen an.

Eine spannende Konsequenz in Serverless-Architekturen ist das Verschwimmen von Software- und Systemarchitektur. "Klassische" Software-Architekturen umfassen Baustein- und Verteilungssichten. Erstere geben einen Überblick über die vorhandenen Komponenten eines Softwaresystems und deren Interaktion. Letztere legen den Fokus auf die Verteilung dieser Bausteine auf Infrastruktur wie Server und Netzwerke. Wenn Server wegabstrahiert werden, ist eine solche Trennung nicht mehr möglich bzw. nötig. Ein Gesamtsystem entsteht stattdessen durch die Verknüpfung vieler Services wie APIs, Queues und Datenbanken. Funktionen bilden hierbei den Klebstoff zwischen den Services, wodurch auch der Begriff des "Glue-Codes" geprägt wurde. Da das Konzept der "Instanz" in Serverless-Architekturen nicht mehr existiert, bildet diese Verknüpfung bereits das gesamte System ab und eine separate Verteilungssicht ist nicht mehr sinnvoll.

Um solch verteilte Umgebungen zuverlässig aufzusetzen, kommt heutzutage typischerweise ein Infrastructure-as-Code (IaC) Ansatz ins Spiel. Hierunter versteht man eine textuelle Beschreibung der Cloud-Infrastruktur, die von IaC-Tools verarbeitet und damit reproduzierbar Cloud-Infrastruktur automatisiert erzeugt bzw. wieder aufgelöst werden kann. Moderne IaC-Tools wie Pulumi nutzen gängige Programmiersprachen wie TypeScript oder Python zur Definition der Cloud-Infrastruktur. Pulumi etwa ermöglicht es zudem "Glue-Code", der zur Laufzeit von FaaS-Umgebungen ausgeführt werden soll, direkt in den Infrastruktur-Code mit einzubetten [3].

Eine recht neue Entwicklung in diesem Umfeld ist das Konzept "Infrastructure-from-Code". Hierbei versucht man, noch einen Schritt weiter zu gehen, in dem Entwickler:innen nur noch ihre Geschäftslogik in einem Framework schreiben müssen und sich das Tooling automatisch um die Auswahl und Provisionierung der notwendigen Cloud-Infrastruktur kümmert. Ob sich dieser Trend durchsetzen oder ein Nischendasein fristen wird, bleibt noch abzuwarten.

Gewappnet mit den grundlegenden Architektur-Überlegungen lässt sich nun auch die Frage nach passenden Use Cases für die Verwendung von Serverless-Technologien näher betrachten. Ereignisgetriebene, stark verteilte Architekturen sind z. B. für Systeme geeignet, die einen Event-Workflow implementieren. Hierzu zählen z. B. mobile und IoT-Applikationen, Anwendungsökosysteme (z. B. Plugins und Add-Ons wie für Slack, Teams oder Confluence) und asynchron arbeitende Backoffice-Systeme, die kleinteilige, entkoppelte Aufgaben erledigen. Für eine Serverless-Implementierung sind auch die meisten Web-Anwendungen und Web-APIs geeignet, deren Geschäftslogik sich auf einfache Berechnungen sowie CRUD-Operationen beschränkt.

Sollen für existierende Systeme Serverless-Ansätze genutzt werden, erfordert dies nicht, den über Jahre gewachsenen Monolithen mit einem Big Bang in den Ruhestand zu schicken. In hybriden Cloud-Architekturen werden immer häufiger auch Serverless-Funktionen eingesetzt, die Aufgaben einer Integrationsschicht übernehmen. Beispielsweise kann ein Kundenportal mit Serverless-Technologien und modernen Frontend-Frameworks in der Cloud entwickelt und das Altsystem im eigenen Rechenzentrum für die Verarbeitung von Bestellungen zunächst beibehalten werden. Eine gesicherte Verbindung zwischen der Public Cloud und den eigenen physikalischen Unternehmensnetzwerken (z. B. per VPN), sowie etwas Integrationslogik in Form von Serverless-Funktionen ermöglichen eine komfortable Realisierung eines solchen Szenarios.

Die Nutzung von Serverless-Technologien verspricht allgemein beeindruckende neue Möglichkeiten: wartungsarme, resiliente Softwarearchitekturen, die automatisch skalieren, potenzielle Kosteneinsparungen, Fokussierung auf Geschäftslogik und Auslagerung eines großen Teils der betrieblichen Querschnittsthemen an Cloud-Anbieter. Gleichzeitig kommt ein Sprung ins kalte Serverless-Wasser nicht ohne Risiken: Das Design von Serverless-Architekturen, die die neuen Potenziale optimal nutzen, erfordert ein Umdenken. Das Entwicklungsteam kann sich nicht mehr auf das Produzieren von Code beschränken, sondern muss sich Gedanken zur Nutzung, Verknüpfung und Integration verschiedener Cloud-Services machen. Dabei müssen Themen wie Monitoring, Alerting und Observability von Anfang an mitgedacht werden. Typischerweise entstehen in größeren Projekten schnell sehr viele unabhängige Funktionen und eine gut geplante und dokumentierte Architektur ist erforderlich.

Dies bedeutet auch, dass Serverless nicht immer der richtige Weg sein muss: Nicht jedes Unternehmen und System hat hohe Anforderungen an eine automatische, differenzierte Skalierung und bei manchen Projekten rechtfertigt sich der Overhead für eine stark verteilte Serverless-Architektur nicht. Zudem bedeutet Serverless nahezu immer den Einsatz einer Public Cloud, was bei vielen Anwendungen zunächst eine Klärung von Datenschutz-Implikationen erfordert. Zwar gibt es auch Open-Source-Projekte wie "knative" und "OpenFaaS", die eine an Serverless angelehnte Architektur auch in der Private Cloud ermöglichen, jedoch sind hier einige Mehrwerte von Serverless-Technologien nicht im gleichen Maß gegeben. Die Skalierung und Kosteneinsparung sind etwa dadurch eingeschränkt, dass das Kubernetes-Cluster noch selbst betrieben und ausreichende Kapazitäten ständig vorgehalten werden müssen.

Das Risiko des Vendor-Lock-Ins lässt sich oft durch eine vorausschauende Architektur und Beachtung einiger Good-Practices wesentlich entschärfen. Dazu gehört eine gute Kapselung von Anbieter-spezifischen Eigenheiten der jeweiligen Services.

Lohnt sich nun der Einsatz von Serverless-Technologien für das nächste Projekt? Wie so oft gilt auch hier der Satz "es kommt darauf an". Serverless ist ein sich stetig weiterentwickelndes Konzept. Es lohnt sich, den Trend im Auge zu behalten und sich mit den Technologien und Architekturmustern weiter zu beschäftigen. Wie eingangs bereits angedeutet: Viele Versprechen der Cloud werden durch Serverless-Technologien erst eingelöst, es liegt aber in der eigenen Hand, die neuen Möglichkeiten zu bewerten und richtig einzusetzen.