Serverless Computing

Serverless Computing ist eine Nutzungsform von Cloud-Diensten, bei der der Anbieter die benötigte Rechenleistung (Compute) automatisch bereitstellt, mit der Last mitwachsen lässt und nur die tatsächliche Nutzung abrechnet. Der Kunde betreibt selbst keine Server oder virtuellen Maschinen (VMs, softwarebasierte Rechner in der Cloud). Die drei Kernmerkmale sind automatische Skalierung bis auf null (Scale-to-Zero, ohne Last laufen keine Ressourcen), verbrauchsgenaue Abrechnung nach Laufzeit oder verarbeiteter Datenmenge und eine vom Anbieter gepflegte Ausführungsumgebung.

Was ist Serverless Computing?

Serverless Computing ist ein Oberbegriff für Cloud-Angebote, bei denen der Anbieter die komplette Betriebsarbeit rund um die Rechenleistung übernimmt. Server existieren physisch weiterhin, sie sind für den Kunden nur nicht mehr sichtbar oder verwaltbar. Aufgaben wie Bereitstellung (Provisionierung), Sicherheits-Updates (Patching), Kapazitätsplanung und Skalierung liegen vollständig beim Anbieter. Der Kunde nutzt am Ende nur einen Ausführungspunkt für Code oder Abfragen (einen sogenannten Endpunkt), die technischen Recheneinheiten dahinter bleiben verborgen und lassen sich nicht anpassen.

Vier Merkmale definieren das Modell in seiner reinen Form. Erstens automatische Skalierung nach Last, einschließlich Scale-to-Zero: ohne Anfragen fährt die Kapazität auf null herunter und verursacht keine Kosten. Zweitens verbrauchsabhängige Abrechnung, gemessen in Ausführungszeit (typischerweise Millisekunden), verarbeiteten Requests, gescannten Datenmengen oder normalisierten Compute-Einheiten. Drittens eine ereignis- oder anfragegetriebene Auslösung: Code oder Query läuft nur, wenn ein Auslöser eintritt. Viertens eine vom Anbieter verwaltete Runtime, in der Betriebssystem, Sprach-Runtime und darunterliegende Infrastruktur gepflegt werden.

Verbreitet sind drei Ausprägungen. Function-as-a-Service stellt einzelne Funktionen als Ausführungseinheit bereit, ausgelöst durch Events (AWS Lambda, Azure Functions, Google Cloud Functions). Container-Serverless nimmt beliebige Container-Images entgegen und übernimmt die Orchestrierung, ohne dass ein Kubernetes-Cluster verwaltet werden muss (Google Cloud Run, AWS Fargate, Azure Container Apps). Serverless Data oder Serverless Analytics wendet dasselbe Prinzip auf Datenverarbeitung an: Warehouses und Query-Engines skalieren mit der Anzahl paralleler Abfragen und rechnen nach gescannten Bytes oder Compute-Einheiten ab (Google BigQuery, Snowflake, Databricks Serverless SQL Warehouses, AWS Athena).

Der Begriff hat sich als eigene Kategorie etabliert, weil das Modell Betriebsaufgaben aus dem Nutzer-Verantwortungsbereich entfernt, die in klassischen IaaS- und PaaS-Angeboten dort verbleiben. Die typischen Trade-offs sind Cold Starts nach Scale-to-Zero (erste Anfrage nach einer Ruhephase startet die Runtime kalt und antwortet mit erhöhter Latenz), eingeschränkte Kontrolle über Laufzeitumgebung und Netzwerk, Anbieter-Bindung durch spezifische Ereignisintegrationen und Ausführungsmodelle sowie ungünstige Kostenkurven bei anhaltend hoher, gleichmäßiger Last, bei der ein reservierter Cluster günstiger sein kann.

Abgrenzung: IaaS, PaaS, Container-Orchestrierung, Cold Start

Serverless Computing wird häufig mit benachbarten Cloud-Modellen und Latenz-Phänomenen vermischt. Die Abgrenzung ordnet den Begriff im Bereitstellungs-Spektrum ein.

Der zentrale Unterschied zu IaaS und PaaS liegt in der Abrechnungs- und Verantwortungs-Grenze. IaaS rechnet nach reservierter VM-Kapazität ab, unabhängig von Nutzung. PaaS rechnet nach Instanz-Stunden ab, in denen die Anwendung deploybar ist. Serverless rechnet nach tatsächlicher Ausführung ab und kennt Scale-to-Zero. Container-Orchestrierung mit Kubernetes bleibt IaaS-nah, weil der Kunde den Cluster verwaltet; erst Container-Serverless zieht die Orchestrierungs-Grenze auf die Anbieter-Seite. Der Cold Start bildet eine eigene Ebene: ein Latenz-Nebeneffekt der Scale-to-Zero-Eigenschaft, der in allen Serverless-Ausprägungen auftritt.

Beispiel: Bildverarbeitung als FaaS und Serverless SQL Warehouse

Eine ereignisgetriebene Bildverarbeitung zeigt das Modell in FaaS-Ausprägung. Beim Upload eines Bildes in einen S3-Bucket löst ein Object-Created-Event eine AWS-Lambda-Funktion aus, die Miniaturbilder erzeugt und in einen zweiten Bucket schreibt. Zwischen zwei Uploads läuft kein Prozess; die Funktion wird pro Aufruf gestartet, die Ausführung wird in Millisekunden abgerechnet, und bei ausbleibenden Uploads fallen keine Compute-Kosten an. Skaliert wird nach eingehenden Events: bei hundert gleichzeitigen Uploads startet die Plattform hundert parallele Funktionsinstanzen ohne vorherige Kapazitätsplanung.

Als analytisches Beispiel skaliert ein [Databricks Serverless SQL Warehouse](https://docs.databricks.com/aws/en/compute/sql-warehouse/serverless) Cluster automatisch mit der Anzahl parallel laufender BI-Abfragen. Bei leerer Last fährt das Warehouse innerhalb weniger Minuten auf null herunter, bei einer eintreffenden Query startet es innerhalb von Sekunden. Der Verbrauch wird in DBUs pro Sekunde gemessen, die zugrundeliegenden VMs verwaltet Databricks; sichtbar ist nur der SQL-Endpunkt. Auf derselben Klasse operiert Google BigQuery, das nach gescannten Bytes abrechnet, während Snowflake nach Warehouse-Sekunden abrechnet. Alle drei folgen dem Serverless-Prinzip, unterscheiden sich aber in der konkreten Verbrauchsmetrik und im Verhalten bei Leerlauf.