Serverless

Entstehung und Beteiligte

Serverless Computing entwickelte sich aus Platform as a Service. AWS Lambda startete 2014 und machte Function as a Service populär. Google Cloud Functions und Azure Functions folgten.

Welches Problem sollte gelöst werden?

Entwickler sollten Ereigniscode ausführen können, ohne Servergrößen, Betriebssysteme oder dauerhafte Instanzen zu verwalten. Kosten sollten sich enger an tatsächlicher Ausführung orientieren.

Technische Hürden und Lösungen

Cold Starts, Laufzeitgrenzen, verteilter Zustand und Anbieterbindung beeinflussen Architektur. „Serverless“ bedeutet nicht serverfrei; der Anbieter betreibt und teilt die Server. Beobachtung und lokales Testen sind schwieriger.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• 2014 wird AWS Lambda vorgestellt.
• FaaS führt Funktionen ereignisgesteuert aus.
• Abrechnung erfolgt häufig nach Aufrufen, Laufzeit und Ressourcen.
• Dauerlast kann auf klassischen Diensten günstiger sein.

Was ist Serverless?

Serverless Computing (auch Function as a Service, FaaS) ist ein Cloud-Ausführungsmodell, bei dem der Cloud-Anbieter die gesamte Serverinfrastruktur verwaltet. Entwickler deployen einzelne Funktionen, konfigurieren Trigger und bezahlen nur für die tatsächliche Ausführungszeit – auf die Millisekunde genau.

Der Begriff "Serverless" ist irreführend – Server existieren natürlich. Der Punkt: Entwickler abstrahieren vollständig von Serververwaltung, Betriebssystem, Patching und Kapazitätsplanung.

Wie funktioniert FaaS?

Eine Serverless-Funktion ist ein kleines, zustandsloses Stück Code (Handler-Funktion) mit klarem Input und Output. Sie wird durch Events ausgelöst:

1. Ein Event tritt auf: HTTP-Request, File-Upload in S3, Cron-Job, Nachricht in Queue
2. Der Cloud-Anbieter startet einen Container (oder nutzt einen "warmen") mit deiner Funktion
3. Die Funktion verarbeitet das Event (typisch: Sekunden bis Minuten, bei AWS Lambda max. 15min)
4. Ergebnis wird zurückgegeben oder in andere Services geschrieben
5. Container bleibt kurz "warm" für Folge-Requests, wird dann terminiert – kein Idle-Kosten

Cold Start und Performance

Ein "Cold Start" tritt auf, wenn kein vorgewärmter Container verfügbar ist. Der Anbieter muss Container-Image laden, Runtime initialisieren und die Funktion starten – das dauert 100ms bis 3 Sekunden je nach Sprache und Paketgröße.

Typische Cold-Start-Zeiten: Python/Node.js ~100–500ms, Java/C# ~1–3s (JVM-Overhead!). Gegenmaßnahmen: Provisioned Concurrency (warm halten), leichte Runtimes, kleines Deployment-Paket, Rust oder Go statt JVM.

Wann Serverless, wann nicht?

Ideal für: Event-getriebene Verarbeitung (Bild-Resize bei Upload), API-Backends mit sporadischem Traffic, Glue-Code zwischen Services, Scheduled Jobs, Webhooks.

Weniger geeignet für: Lange laufende Prozesse (>15min), WebSockets/Long-Polling (zustandslos!), sehr niedrige Latenz-Anforderungen (Cold Start), hoher konstanter Durchsatz (da wird EC2/Container günstiger).