Serverless Computing: Kostenstruktur, Time-to-Market und die Grenzen des Modells

Was ist Serverless Computing?

Serverless Computing ist ein Cloud-Modell, bei dem der Anbieter die Server betreibt und Sie nur Code in Form einzelner Funktionen liefern. Abgerechnet wird nach Aufrufen und verbrauchter Rechenzeit, nicht nach bereitgestellten Servern. Das Modell passt zu schwankender oder unbekannter Last. Bei Dauerlast, strengen Latenzanforderungen oder dem Wunsch nach Anbieterunabhängigkeit stößt es an Grenzen.

Serverless Computing verändert zwei Dinge: wer die Infrastruktur betreibt und wofür Sie bezahlen. Beides wirkt sich auf Betriebsaufwand, Kostenstruktur und Time-to-Market aus. Dieser Beitrag beschreibt die Mechanik dahinter und benennt die Fälle, in denen das Modell nicht passt.

Wie das Modell funktioniert

Der Anbieter betreibt die gesamte Serverinfrastruktur. Sie liefern nur den Code, in Form einzelner Funktionen. Der Anbieter führt sie aus, sobald ein Ereignis eintritt. Das kann ein HTTP-Aufruf sein, eine Nachricht in einer Warteschlange oder ein Upload in einen Speicher. Kapazitätsplanung, Betriebssystem-Patches und Skalierung übernimmt der Anbieter.

Die bekanntesten Dienste dieser Art sind AWS Lambda, Azure Functions und Cloud Run functions von Google (bis August 2024 Google Cloud Functions). Abgerechnet wird nach Anzahl der Aufrufe und nach der tatsächlich verbrauchten Rechenzeit, nicht nach bereitgestellten Servern.

Was sich im Betrieb ändert

Bei einer klassischen Serverarchitektur konfigurieren Sie Maschinen, richten Load Balancer ein, überwachen die Auslastung und passen die Kapazität an. Bei Serverless entfallen diese Aufgaben. Die Plattform startet bei steigender Last weitere Instanzen der Funktion und fährt sie bei sinkender Last wieder herunter. Das geschieht ohne manuellen Eingriff, auch bei plötzlichen Lastspitzen.

Grenzenlos ist das nicht. Jeder Anbieter begrenzt, wie viele Instanzen gleichzeitig laufen und wie schnell neue hinzukommen. AWS nennt für Lambda je Funktion 1.000 neue Ausführungsumgebungen alle zehn Sekunden. Kommen Anfragen schneller herein oder ist das Kontingent des Kontos erreicht, scheitern die zusätzlichen Aufrufe mit einem Drosselungsfehler (HTTP 429). Für die meisten Anwendungen reicht diese Rate. Wer mit sehr steilen Spitzen rechnet, muss die Grenzen kennen und die Kontingente vorab anpassen.

Was ebenfalls bleibt, ist die Überwachung der Anwendung selbst. AWS erfasst Aufrufzahlen, Laufzeiten und Fehler Ihrer Funktionen automatisch und liefert Metriken, Logs und Tracing. Ob diese Werte ein Problem anzeigen, welche Alarme nötig sind und wo die Ursache liegt, bleibt Ihre Aufgabe.

Ein Teil der Sicherheitsarbeit liegt beim Anbieter: Betriebssystem und Laufzeitumgebung werden dort gepatcht und aktuell gehalten. Die Verantwortung für den eigenen Code, seine Abhängigkeiten, die Zugriffsrechte und den Umgang mit Daten bleibt bei Ihnen.

Für Entwicklungsteams bedeutet das: weniger Zeit für Infrastruktur, mehr Zeit für Funktionen, die beim Kunden ankommen. Wie groß dieser Effekt ist, hängt davon ab, wie viel Betriebsaufwand Ihr Team bisher selbst getragen hat.

Wie die Kosten entstehen

Sie zahlen für Aufrufe und für die Rechenzeit, die Ihre Funktionen tatsächlich verbrauchen. Läuft nichts, kostet es nichts, solange Sie keine Kapazität fest reservieren. Bei Lambda heißt diese Option Provisioned Concurrency. Sie hält Instanzen dauerhaft bereit und wird nach konfigurierter Menge und Dauer abgerechnet, auch ohne einen einzigen Aufruf. Ohne eine solche Reservierung gibt es keine Server, die nachts oder am Wochenende ungenutzt weiterlaufen und trotzdem auf der Rechnung stehen.

Dieses Modell rechnet sich vor allem bei unregelmäßiger oder schwer vorhersehbarer Last. Typische Fälle: Anwendungen mit klaren Nutzungsspitzen. Interne Werkzeuge, die nur zu Bürozeiten laufen. Verarbeitungsschritte, die ein eingehendes Ereignis auslöst. Neue Produkte, deren Nutzung noch niemand kennt. In diesen Fällen müssten Sie bei klassischem Betrieb Kapazität für die Spitze vorhalten und für die Leerlaufzeit mitbezahlen.

Bei konstant hoher Last kehrt sich die Rechnung um. Dazu unten mehr.

Schnellere Markteinführung und Vermeidung von Opportunitätskosten

Weniger Infrastrukturarbeit verkürzt den Weg von der Idee zur ersten nutzbaren Version. Ein Team kann eine Funktion schreiben, bereitstellen und mit echten Nutzern testen. Server dimensionieren oder eine Betriebsumgebung aufsetzen muss es vorher nicht.

Das hat eine wirtschaftliche Seite. Jede Woche, die ein Produkt später auf den Markt kommt, ist eine Woche ohne Umsatz aus diesem Produkt. Und eine Woche ohne Rückmeldung von Kunden. Diese Opportunitätskosten tauchen in keiner Rechnung auf, sind aber real. Serverless senkt sie, weil die Zeit zwischen Entwicklung und Bereitstellung kürzer wird. Sie starten mit kleinem Einsatz und investieren erst bei nachgewiesener Nachfrage mehr.

Wo Serverless an Grenzen stößt

Serverless ist kein Modell für jeden Anwendungsfall. Vier Punkte sollten Sie vor der Entscheidung kennen.

Cold Starts. Wird eine Funktion nach einer Phase der Inaktivität aufgerufen, muss die Plattform zuerst eine Laufzeitumgebung hochfahren. Der erste Aufruf dauert dann spürbar länger. AWS nennt für Lambda eine Spanne von unter 100 Millisekunden bis über einer Sekunde. Lädt eine Funktion beim Start große Frameworks oder Abhängigkeiten, können es mehrere Sekunden sein. Für Anwendungen mit strengen Antwortzeit-Anforderungen ist das ein Problem, das sich zwar abmildern, aber nicht vollständig beseitigen lässt.

Vendor Lock-in. Serverless-Funktionen hängen eng an den Diensten des jeweiligen Anbieters: an dessen Ereignisquellen, Berechtigungsmodell, Datenbanken und Warteschlangen. Der Funktionscode selbst lässt sich portieren, die Verdrahtung drumherum nicht ohne Weiteres. Ein späterer Wechsel des Anbieters kostet deutlich mehr als bei einer Anwendung, die in Containern läuft.

Debugging und Observability. Eine Anwendung aus vielen kleinen Funktionen lässt sich lokal schwerer ausführen als ein einzelner Dienst. Ein Geschäftsvorgang zieht sich über mehrere Funktionsaufrufe, Warteschlangen und Ereignisse. Ohne verteiltes Tracing, strukturierte Logs und Korrelations-IDs von Anfang an ist im Fehlerfall schwer nachzuvollziehen, wo etwas schiefgelaufen ist. Wie sich das bei asynchroner Verarbeitung mit Lambda lösen lässt, beschreibt der Beitrag Echtzeit-Alerts und kein Datenverlust.

Konstant hohe Last. Die Abrechnung pro Aufruf ist günstig, solange die Auslastung schwankt. Läuft ein System rund um die Uhr unter gleichmäßig hoher Last, kehrt sich das um. Derselbe Rechenaufwand ist dann über reservierte oder dedizierte Kapazität meist günstiger. In diesem Fall ist der Preis für die Flexibilität höher als ihr Nutzen. Dieselbe Frage, ob Dauerlast eigene Kapazität rechtfertigt, stellt sich auch bei KI-Modellen: Eigene KI-Modelle selbst hosten oder mieten?

Wann Serverless passt und wann nicht

Serverless Computing verlagert den Betrieb der Infrastruktur zum Anbieter und koppelt die Kosten an die tatsächliche Nutzung. Dadurch lässt sich ein neues Produkt schneller bereitstellen und ohne Vorabinvestition in Kapazität betreiben.

Das Modell passt zu Anwendungen mit unregelmäßiger oder noch unbekannter Last und zu Teams, die Betriebsaufwand abgeben wollen. Es passt weniger zu Systemen mit konstant hoher Auslastung, strengen Latenzanforderungen oder dem Wunsch, den Anbieter jederzeit wechseln zu können. Die Entscheidung hängt am Lastprofil und an den Anforderungen der konkreten Anwendung. Nicht an der Technologie selbst.

Häufige Fragen

Wann lohnt sich Serverless Computing? Bei unregelmäßiger oder schwer vorhersehbarer Last: Anwendungen mit Nutzungsspitzen, interne Werkzeuge für Bürozeiten, ereignisgesteuerte Verarbeitung, neue Produkte mit unbekannter Nachfrage. In diesen Fällen zahlen Sie für tatsächliche Aufrufe und Rechenzeit statt für vorgehaltene Kapazität.

Ist Serverless bei konstant hoher Last günstiger? Meist nicht. Läuft ein System rund um die Uhr unter gleichmäßig hoher Last, ist derselbe Rechenaufwand über reservierte oder dedizierte Kapazität in der Regel günstiger. Die Abrechnung pro Aufruf lohnt sich, solange die Auslastung schwankt.

Was sind Cold Starts und lassen sie sich vermeiden? Ein Cold Start ist die Verzögerung beim ersten Aufruf einer Funktion nach einer Phase der Inaktivität, weil die Plattform erst eine Laufzeitumgebung hochfährt. AWS nennt für Lambda eine Spanne von unter 100 Millisekunden bis über einer Sekunde, bei großen Abhängigkeiten mehrere Sekunden. Cold Starts lassen sich abmildern, aber nicht vollständig beseitigen.

Quellen

• AWS Lambda Developer Guide, Understanding the Lambda execution environment lifecycle: Cold-Start-Spanne „from under 100 ms to over 1 second“.
• AWS Lambda Developer Guide, Improving startup performance with Lambda SnapStart: Initialisierung mit Frameworks und Abhängigkeiten „can sometimes take several seconds“.
• AWS Lambda Developer Guide, Understanding Lambda scaling behavior: Skalierungsrate „1,000 execution environment instances every 10 seconds“ je Funktion; bei Überschreitung „throttling error (429 status code)“.
• AWS Lambda Developer Guide, Monitoring, debugging, and troubleshooting Lambda functions: Metriken, Logs und Tracing für Funktionen und Anwendungen.
• AWS, Lambda Pricing: Provisioned Concurrency „You pay for the amount of concurrency you configure, and for the period of time you configure it“.
• AWS Whitepaper, Security Overview of AWS Lambda (PDF), Abschnitt „The Shared Responsibility Model“: AWS betreibt Infrastruktur, Betriebssystem und Anwendungsplattform; „You are responsible for the security of your code and AWS IAM to the Lambda service and within your function“.
• Google Cloud, Cloud Run functions release notes: Umbenennung von Cloud Functions in Cloud Run functions, Eintrag vom 21. August 2024.