Begriff
Serverless (FaaS)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Der Name ist eine Lüge. Natürlich gibt es Server. Aber sie gehören dir nicht. Du mietest keinen Server (wie bei einer WG). Du mietest nicht mal einen Container (wie bei Airbnb). Du mietest Rechenzeit pro Millisekunde. Beispiel: Du lädst Code hoch ("Konvertiere Bild zu Schwarz-Weiß"). Niemand ruft an? Du zahlst 0 €. 1 Million Leute rufen an? 1 Million kleine Instanzen starten sofort, arbeiten 100ms, und sterben wieder. Du kümmerst dich nie wieder um Updates, Abstürze oder Skalierung.
Merksatz: Ein Cloud-Computing-Modell, bei dem der Cloud-Provider die Infrastruktur komplett verwaltet und Ressourcen dynamisch bei Bedarf zuweist (Function as a Service).
- AWS Lambda, Azure Functions, Google Cloud Functions. Perfekt für "Glue Code" (Klebstoff): "Wenn eine Datei in S3 hochgeladen wird, starte Lambda, mach ein Thumbnail, speichere es in DB." Das läuft komplett event-gesteuert.
1. Cold Start
Das größte Problem. Wenn deine Funktion lange nicht lief, "schläft" sie (Cloud provider hat den Container gelöscht). Der erste User muss warten, bis der Container bootet (0,5 bis 5 Sekunden). Das ist tödlich für Echtzeit-APIs. Lösung: "Provisioned Concurrency" (Geld zahlen, damit sie wach bleiben) oder leichtgewichtige Runtimes (Go/Rust statt Java).
2. Stateless
Serverless Functions haben kein Gedächtnis. Du kannst nichts im RAM speichern für den nächsten Aufruf. Alles muss in eine externe DB (DynamoDB, Redis). Das zwingt zu sauberer Architektur ("Shared Nothing Architecture").
1. Cold Start & Firecracker Micro-VMs
Warum dauert ein Cold Start so lange? Früher startete AWS einen kompletten Docker-Container. Heute nutzt AWS Firecracker, einen Open-Source Virtual Machine Monitor (VMM). Firecracker startet Micro-VMs in weniger als 125 Millisekunden. Dennoch: Wenn deine App (z. B. Java/Spring Boot) 5 Sekunden braucht, um den Kontext zu laden, bringt die schnellste VM nichts. Profis optimieren dies durch Snapshotted Runtimes (z. B. AWS Lambda SnapStart): Der Speicherzustand des fertig gebooteten Prozesses wird auf Disk eingefroren. Bei einem Cold Start wird nicht gebootet, sondern einfach nur der RAM-Dump in die CPU geladen – ein "Warm Boot" in Millisekunden.
2. Statelessness & The Portability Trap (Vendor Lock-in)
Serverless zwingt dich zu einer Architektur, die fast 100% von den Services des Providers abhängt. Deine Funktion nutzt das AWS-spezifische S3-Event, loggt in CloudWatch und speichert in DynamoDB. Ein Wechsel zu Google Cloud bedeutet: Du musst nicht nur den Code umschreiben (Trigger-Formate!), sondern deine gesamte Daten-Architektur migrieren. Das nennt man den Hingabe-Effekt (Vendor Lock-in). Wer "Cloud Agnostic" bleiben will, sollte Frameworks wie das Serverless Framework oder Pulumi nutzen, die diese Infrastruktur-Definitionen abstrahieren können, wobei dies oft zu einem "kleinsten gemeinsamen Nenner" führt, der die coolsten Cloud-Features wieder ausschließt.
3. Event-Driven Anti-Patterns (The Infinite Loop)
In Serverless zahlt man für jeden Aufruf. Ein klassischer "SRE-Horror" ist die unendliche Rekursion zwischen zwei Cloud-Services: Service A schreibt eine Datei. Das triggert Lambda B. Lambda B schreibt (aus Versehen) eine neue Datei im gleichen Ordner. Das triggert wieder Lambda B... Innerhalb weniger Minuten können so zehntausende Euro Kosten entstehen, da der Provider die Skalierung gnadenlos hochfährt. Cloud-Architekten müssen zwingend Circuite Breakers, maximale Instanzen-Limits und Budget-Alerts im Dashboard setzen, bevor sie "Serverless" auf die Produktion loslassen.
Quick-Check
Ist es billiger?
Bei sporadischer Nutzung: Ja, extrem (oft kostenlos). Bei Dauerlast (24/7 Number Crunching): Nein, da sind VMs (EC2) billiger.Gibt es ein Zeitlimit?
Ja. AWS Lambda darf maximal 15 Minuten laufen. Wer länger braucht, ist kein "Serverless", sondern ein "Batch Job" (AWS Batch).Vendor Lock-in?
Hoch. Lambda-Code ist stark an AWS Events gebunden. Es ist schwer, mal eben zu Azure zu wechseln. Frameworks wie "Serverless Framework" versuchen das zu abstrahieren.