Was ist Serverless und FaaS

Was ist Serverless Computing

Serverless Computing ist ein Cloud-Computing-Modell, bei dem der Cloud-Anbieter die Infrastruktur automatisch verwaltet. Im Gegensatz zum klassischen Webhosting Skalierung und Ressourcenzuweisung anstelle von Ihnen. Trotz des Namens existieren Server weiterhin, aber Sie denken nicht über sie nach und konfigurieren sie nicht. Sie schreiben Code, deployen ihn und der Cloud-Anbieter kümmert sich um alles andere, einschließlich Betriebssystem, Runtime-Umgebung, Skalierung und hohe Verfügbarkeit. Sie zahlen nur für die Ausführungszeit Ihres Codes, nicht für die Zeit, in der der Server auf Anfragen wartet.

Serverless ist eine Evolution von physischen Servern über virtuelle Maschinen und Container hin zu einem vollständig abstrahierten Computing-Modell. Jeder Schritt in dieser Evolution entfernt eine Verantwortungsebene vom Entwickler und überträgt sie an den Cloud-Anbieter. Beim Serverless-Modell konzentriert sich der Entwickler ausschließlich auf die Geschäftslogik, während sich der Cloud-Anbieter um alles andere kümmert, was die Entwicklung drastisch beschleunigt und die Betriebskosten für viele Anwendungstypen senkt.

Functions as a Service (FaaS)

FaaS ist die bekannteste Form des Serverless Computing. Im FaaS-Modell schreiben Sie kleine, eigenständige Funktionen, die als Reaktion auf Ereignisse (Events) ausgeführt werden. Jede Funktion hat eine klar definierte Verantwortung, erhält Eingabedaten, führt Logik aus und gibt ein Ergebnis zurück. Der Cloud-Anbieter erstellt automatisch eine Instanz zur Ausführung der Funktion, führt sie aus und schaltet die Instanz aus, wenn sie fertig ist. Wenn 1000 gleichzeitige Anfragen eintreffen, erstellt der Anbieter automatisch 1000 Instanzen.

Wichtige FaaS-Anbieter

• AWS Lambda - der erste und ausgereifteste FaaS-Service, gestartet 2014
• Google Cloud Functions - Googles FaaS mit guter Firebase-Integration
• Azure Functions - Microsofts FaaS mit ausgezeichneter .NET-Unterstützung
• Cloudflare Workers - Edge Computing mit globaler Verteilung und V8-Isolierung
• Vercel Functions - optimiert für Next.js und Frontend-Frameworks
• Netlify Functions - einfach für Jamstack-Websites

Jeder Anbieter hat Besonderheiten hinsichtlich unterstützter Programmiersprachen, maximaler Ausführungszeit, Speicherlimits und Trigger-Methoden. Für einen klassischeren Ansatz erwägen Sie Cloud-Hosting-Dienst. AWS Lambda unterstützt Node.js, Python, Java, Go, .NET und Ruby mit einer maximalen Ausführungszeit von 15 Minuten und bis zu 10 GB Speicher. Cloudflare Workers verwenden V8-Runtime mit Beschränkung auf 50ms CPU-Zeit (kostenloser Plan), bieten aber außergewöhnlich niedrige Latenz, da sie an Edge-Standorten ausgeführt werden.

Wie Serverless-Funktionen funktionieren

Wenn ein Ereignis eine Serverless-Funktion auslöst, durchläuft der Cloud-Anbieter mehrere Schritte. Zuerst prüft er, ob eine warme Instanz existiert, die bereits initialisiert und zur Ausführung bereit ist. Falls nicht, wird eine neue Instanz erstellt, was als Cold Start bezeichnet wird. Cold Start umfasst das Starten des Containers, das Laden der Runtime, das Laden Ihres Codes und die Ausführung der Initialisierungslogik. Danach wird die Handler-Funktion mit den Ereignisdaten ausgeführt.

Cold-Start-Problem

Cold Start ist die häufigste Quelle für Latenz in der Serverless-Architektur. Für Node.js-Funktionen dauert ein Cold Start normalerweise 100-500ms, für Python 200-800ms und für Java kann es aufgrund der JVM-Initialisierung 1-5 Sekunden oder länger dauern. Nach der ersten Ausführung bleibt die Instanz einige Zeit warm (normalerweise 5-15 Minuten) und nachfolgende Anfragen werden viel schneller ausgeführt, da sie die Initialisierung überspringen.

Strategien zur Reduzierung des Cold Starts umfassen die Verwendung leichterer Runtimes (Node.js und Python sind schneller als Java), Minimierung der Deployment-Paketgröße, Verwendung von Provisioned Concurrency (Sie zahlen für im Voraus aufgewärmte Instanzen) und Vermeidung schwerer Initialisierungen in der Handler-Funktion. AWS Lambda SnapStart für Java und Cloudflare Workers, die V8-Isolate anstelle von Containern verwenden, reduzieren den Cold Start erheblich auf ein Niveau, das für die meisten Anwendungen vernachlässigbar ist.

Anwendungsfälle für Serverless

Die Serverless-Architektur ist ideal für bestimmte Arten von Workloads, während sie für andere teuer oder unpraktisch sein kann. Das Verständnis des richtigen Anwendungsfalls ist entscheidend für die erfolgreiche Anwendung des Serverless-Modells in der Praxis.

Ideale Szenarien

• API-Backends - REST- oder GraphQL-APIs, die HTTP-Anfragen verarbeiten
• Ereignisverarbeitung - Reaktion auf Datei-Upload, Datenbankänderungen, Nachrichten in einer Queue
• Geplante Aufgaben - Cron-Jobs, die periodisch ausgeführt werden
• Bild- und Videoverarbeitung - Resizing, Komprimierung, Transcodierung auf Anfrage
• Chatbots und KI-Inferenz - Verarbeitung von Benutzernachrichten und Aufrufe an KI-Modelle
• Webhooks - Empfang und Verarbeitung von Webhook-Aufrufen externer Dienste
• IoT-Datenverarbeitung - Verarbeitung von Daten von Sensoren und Geräten

Weniger geeignete Szenarien

Serverless ist nicht optimal für langlaufende Prozesse, die länger als 15 Minuten dauern, für Anwendungen, die konstant niedrige Latenz erfordern (Cold-Start-Problem), für Workloads mit konstant hohem Traffic, bei denen ein dedizierter Server günstiger ist, und für Anwendungen, die lokales Dateisystem oder lang andauernde WebSocket-Verbindungen erfordern. In diesen Fällen sind Container oder traditionelle Server die bessere Wahl.

Abrechnungsmodell

Einer der größten Vorteile des Serverless-Modells ist die Pay-per-Use-Abrechnung. Sie zahlen nicht für die Leerlaufzeit des Servers, sondern nur für die Zeit, in der Ihr Code aktiv ausgeführt wird. AWS Lambda berechnet nach Anzahl der Anfragen (0,20 Dollar pro Million Anfragen) und nach Ausführungsdauer in GB-Sekunden (wie viel Speicher die Funktion verwendet, multipliziert mit der Ausführungsdauer in Sekunden).

Kostenvergleich

Für eine kleine Website oder API mit 100.000 Anfragen pro Monat, bei denen jede Anfrage 200ms mit 256MB Speicher dauert, wären die monatlichen Kosten bei AWS Lambda unter einem Dollar. Ein äquivalenter EC2-Server t3.micro kostet etwa 8,50 Dollar pro Monat, selbst wenn er die meiste Zeit nichts tut. Für diese Art von Workload ist Serverless drastisch günstiger.

Die Berechnung ändert sich jedoch bei großem Umfang. Für eine Anwendung mit 100 Millionen Anfragen pro Monat können Serverless-Kosten 200 Dollar pro Monat übersteigen, während ein dedizierter Server mit ähnlicher Kapazität weniger kosten würde. Die sogenannte Serverless Cost Cliff entsteht, wenn die Workload eine bestimmte Schwelle überschreitet, ab der ein konstant gemieteter Server rentabler wird. Für jede Anwendung ist es wichtig, vor der Wahl des Modells eine Kostenanalyse für die erwartete Workload durchzuführen.

Vorteile der Serverless-Architektur

• Kein Infrastrukturmanagement - keine Sorgen um Server, Patches, Skalierung
• Automatische Skalierung - von null auf eine Million Anfragen ohne Konfiguration
• Pay-per-Use - Sie zahlen nur für Ausführung, nicht für Leerlaufzeit
• Schnellere Entwicklung - Fokus auf Code statt Infrastruktur beschleunigt die Auslieferung
• Hohe Verfügbarkeit - der Cloud-Anbieter garantiert Verfügbarkeit ohne Ihr Engagement
• Skalierung auf null - keine Kosten, wenn kein Traffic vorhanden ist

Nachteile und Herausforderungen

Die Serverless-Architektur bringt auch spezifische Herausforderungen mit sich. Vendor Lock-in ist real, da jeder Anbieter spezifische APIs, Dienste und Tools hat, die die Migration zu einem anderen Anbieter erschweren. Cold-Start-Latenz kann für Anwendungen problematisch sein, die konstant schnelle Reaktion erfordern. Debugging und Monitoring sind komplexer, da Funktionen in ephemeren Umgebungen ohne Zugriff auf traditionelle Diagnose-Tools ausgeführt werden.

Lokale Entwicklung und Tests stellen ebenfalls Herausforderungen dar, da es schwierig ist, die Cloud-Umgebung lokal zu replizieren. Tools wie AWS SAM, Serverless Framework und LocalStack helfen, können aber das Produktionsverhalten nicht vollständig simulieren. Beschränkungen für Deployment-Paketgröße, Ausführungszeit und Speicher können das Refactoring bestehender Anwendungen erfordern. Schließlich kann die Lernkurve für Teams ohne Cloud-Service-Erfahrung steil sein.