3 Min. Lesezeit
Das Wichtigste in Kürze
- Serverless geht über Lambda/Functions hinaus: Datenbanken, Queues, Storage, ML-Inferenz – alles als Serverless verfügbar
- Pay-per-Execution spart 60-80 Prozent bei sporadischen Workloads, kann aber bei Dauerlast teurer werden als Compute-Instanzen
- Cold Starts bleiben ein Problem für latenzkritsiche Anwendungen – Provisioned Concurrency als Workaround
- Vendor Lock-in durch proprietäre Event-Modelle (EventBridge, Cloud Events) – Portabilität erfordert Abstraktionsschichten
- Serverless-First als Architekturprinzip: Nur was nicht serverless geht, wird auf Compute deployed
Serverless hat seinen Platz gefunden – aber anders als erwartet. AWS Lambda, Azure Functions und Google Cloud Functions waren der Startpunkt. 2026 ist Serverless ein Architekturprinzip, kein einzelner Dienst: Serverless-Datenbanken, Serverless-Container, Serverless-ML-Inferenz. Die Frage ist nicht mehr ob Serverless, sondern wie viel.
Beyond Functions: Das Serverless-Ökosystem 2026
Die erste Serverless-Welle (2015-2020) war auf Functions fokussiert: kleine Code-Fragmente, event-getriggert, pay-per-invocation. Das Ökosystem 2026 ist dramatisch breiter: DynamoDB und Aurora Serverless (Datenbanken), SQS und EventBridge (Messaging), S3 und EFS (Storage), SageMaker Serverless Inference (ML) – alles ohne Kapazitätsplanung.
Der Paradigmenwechsel: Statt „Welchen Server brauche ich?“ die Frage „Welchen Service bietet die Cloud für meinen Anwendungsfall?“. Die Antwort ist zunehmend: einen, bei dem man sich nicht um Infrastruktur kümmert.
Wann Serverless billiger ist – und wann nicht
Die Kosten-Mathematik ist eindeutig bei sporadischen Workloads: Ein Lambda-Function, die 10.000 Mal am Tag für je 200ms läuft, kostet unter 1 EUR/Monat. Ein kleiner EC2-Server für den gleichen Workload: 30-50 EUR/Monat. Einsparung: 97 Prozent.
Bei Dauerlast kehrt sich die Rechnung um: Ein Lambda, das 24/7 mit hoher Concurrency läuft, wird teurer als eine dedizierte EC2-Instanz. Die Break-Even-Analyse hängt von Aufruffrequenz, Execution-Dauer und Memory-Bedarf ab. Faustregel: Unter 50 Prozent Auslastung ist Serverless günstiger.
Cold Starts: Das persistente Problem
Wenn eine Serverless-Function nach Inaktivität zum ersten Mal aufgerufen wird, muss die Laufzeitumgebung initialisiert werden – das ist der Cold Start. Python/Node.js: 100-500ms. Java/.NET: 1-5 Sekunden. Für APIs mit Latenzbedarf unter 200ms ist das problematisch.
Lösungen: Provisioned Concurrency (AWS) hält Functions warm – eliminiert Cold Starts, aber auch den Kostenvorteil. Snap Start (Java) und Tiered Compilation reduzieren die Initialisierungszeit. Der Trend: Runtimes werden schneller, Cold Starts werden kürzer – aber nicht eliminiert.
Serverless-First als Architekturprinzip
Zukunftsorientierte Architekten starten mit der Frage: „Geht das serverless?“ Nur was nicht serverless realisierbar ist (lange laufende Prozesse, GPU-Workloads, spezielle Netzwerkanforderungen), wird auf Compute-Instanzen oder Kubernetes deployed.
Dieses Prinzip maximiert den Anteil der Infrastruktur, der fully managed ist. Weniger Betriebsaufwand, automatische Skalierung, pay-per-use – die operativen Vorteile überwiegen in den meisten Fällen die Einschränkungen. Die Architektur muss sich anpassen (Event-Driven, Stateless, Idempotent), aber das sind ohnehin Best Practices für skalierbare Systeme.
Häufige Fragen
Ist Serverless nur für kleine Workloads?
Nein. Netflix, Coca-Cola und LEGO betreiben massive Serverless-Architekturen. Serverless skaliert per Design auf Millionen gleichzeitiger Ausführungen. Die Einschränkung liegt nicht in der Skalierung, sondern in der Architektur: Stateless, Event-Driven und kurzlebige Prozesse.
Wie handle ich State in Serverless?
State wird externalisiert: DynamoDB/Redis für Session-State, S3 für Dateien, Step Functions für Workflow-State. Das ist Architektur-Disziplin – aber es erzwingt Best Practices, die auch in Nicht-Serverless-Architekturen sinnvoll sind.
Was ist mit Vendor Lock-in?
Real, aber managebar. Event-Modelle und Trigger-Konfigurationen sind proprietär. Die Function-Logik selbst (Python, Node.js, Go) ist portabel. Frameworks wie Serverless Framework und SST abstrahieren Provider-Spezifika teilweise.
Kann ich bestehende Anwendungen auf Serverless migrieren?
Monolithen: schwierig bis unmöglich ohne Re-Architektur. Microservices: ja, schrittweise. Empfehlung: Neue Features serverless bauen, bestehende Services graduell migrieren. Strangler Fig Pattern als Migrationsstrategie.
Was sind Serverless Container (Fargate, Cloud Run)?
Container, die ohne Cluster-Management ausgeführt werden. Sie kombinieren die Flexibilität von Containern (eigene Runtime, größere Payloads) mit dem Betriebsmodell von Serverless (kein Server-Management, pay-per-use). Für viele Workloads der Sweet Spot zwischen Lambda und Kubernetes.
Quelle des Titelbildes: Pexels / Steve Johnson
Lesetipps der Redaktion
- Lenovo ThinkCentre M75q Tiny Gen 5: Enterprise-Mini-PC mit AMD PRO und 5 Watt Idle für Edge und Kiosk
- Serverless KI ist überbewertet – hier ist was stattdessen zählt
- QNAP TS-464: 4-Bay-NAS mit Docker, HDMI und PCIe-Slot – was Synology in dieser Klasse nicht bietet
