Serverless Beyond Lambda: Step Functions
Entdecken Sie, wie Step Functions und EventBridge Ihre Event-Architekturen skalieren. So bauen Sie robuste, entkoppelte Cloud-Systeme.
Das Wichtigste in Kürze
- Serverless ist mehr als Lambda – Step Functions, EventBridge und SQS bilden das Rückgrat moderner Architekturen.
- Event-Driven Architecture entkoppelt Services und ermöglicht asynchrone, skalierbare Verarbeitung.
- AWS Step Functions orchestrieren komplexe Workflows visuell und fehlertolerant.
- EventBridge routet Events regelbasiert an Consumer – das zentrale Nervensystem für Event-Architekturen.
- Serverless-Kosten sind bei niedriger Last unschlagbar, bei Dauerlast oft teurer als Container.
AWS Lambda war der Startschuss, aber Serverless ist längst mehr als Functions-as-a-Service. Moderne Serverless-Architekturen orchestrieren Workflows mit Step Functions, routen Events über EventBridge, puffern mit SQS und speichern in DynamoDB – alles ohne einen einzigen Server zu managen. Die Herausforderung ist nicht mehr die Technologie, sondern das Architekturdenken.
Event-Driven Architecture: Das Grundprinzip
In einer Event-Driven Architecture kommunizieren Services über Events statt über synchrone API-Calls. Ein Bestellservice publiziert ein „Order Created“-Event. Der Zahlungsservice, der Lagerservice und der Benachrichtigungsservice reagieren unabhängig – ohne voneinander zu wissen.
Die Vorteile: Lose Kopplung (Services können unabhängig deployed werden), Skalierbarkeit (jeder Consumer skaliert unabhängig), Ausfallsicherheit (wenn ein Consumer ausfällt, gehen Events nicht verloren, sondern werden gepuffert).
Die Herausforderung: Debugging verteilter, asynchroner Systeme ist komplex. Events können out-of-order ankommen, Consumer können idempotent sein müssen, und End-to-End-Tracing erfordert Correlation-IDs durch alle Services.
AWS Step Functions: Workflow-Orchestrierung ohne Server
Step Functions definieren Workflows als State Machines: Eine visuelle Definition beschreibt Schritte, Verzweigungen, Parallelen, Fehlerbehandlung und Retries. Jeder Schritt kann eine Lambda-Funktion, einen AWS-Service-Call (DynamoDB, S3, SQS, ECS) oder eine menschliche Genehmigung triggern.
Zwei Modes: Standard Workflows für lang laufende Prozesse (bis 1 Jahr, exactly-once-Execution). Express Workflows für Hoch-Volumen, kurze Prozesse (bis 5 Minuten, at-least-once). Preismodell: Standard zahlt pro State Transition, Express pro Anfrage und Dauer.
Praxisbeispiel: Ein Onboarding-Workflow, der Account erstellt (Lambda), E-Mail sendet (SES), CRM updatet (API-Call), auf Verifizierung wartet (Callback), und bei Timeout automatisch erinnert – alles als visueller Workflow, fehlertolerant und skalierbar.
EventBridge: Das Event-Routing-System
Amazon EventBridge ist ein Serverless Event Bus, der Events von AWS-Services, SaaS-Anbietern (Salesforce, Zendesk, Shopify) und eigenen Anwendungen empfängt und regelbasiert an Targets routet. Ein Event-Pattern beschreibt, welche Events wohin geroutet werden – ohne Code, nur Konfiguration.
Event Pipes vereinfachen Point-to-Point-Integration: Source (SQS, DynamoDB Stream, Kinesis) → optionale Transformation → Target (Lambda, Step Functions, API Destination). Für einfache Event-Verarbeitung ohne komplexes Routing ist das die effizienteste Lösung.
Scheduler ersetzt CloudWatch Events Cron: Geplante Ausführung von Lambda-Funktionen, Step Functions oder API-Calls – mit flexibler Wiederholungslogik und Timezone-Support.
Serverless Patterns: Über einzelne Functions hinaus
Choreography: Services reagieren auf Events ohne zentrale Koordination. Jeder Service entscheidet selbst, auf welche Events er reagiert. Einfach, aber schwer zu debuggen bei komplexen Abläufen.
Orchestration: Step Functions koordinieren den Ablauf zentral. Jeder Schritt ist explizit definiert. Einfacher zu verstehen und debuggen, aber die Step Function wird zum zentralen Dependency.
Saga Pattern: Für verteilte Transaktionen über mehrere Services. Jeder Schritt hat eine Kompensationslogik (Rollback). Step Functions implementieren Sagas elegant mit Error-Handling und Compensate-States.
Fan-Out/Fan-In: Ein Event triggert parallele Verarbeitung (Fan-Out), die Ergebnisse werden aggregiert (Fan-In). SNS → Lambda (Fan-Out) + Step Functions Parallel State (Fan-In) ist das klassische AWS-Pattern.
Kosten und Grenzen von Serverless
Serverless ist bei niedriger und variabler Last unschlagbar günstig: Lambda kostet nur bei Ausführung, EventBridge pro Event (1 USD pro Million), Step Functions pro Transition. Für Anwendungen mit Spike-Last oder geringem Durchschnitt ist das optimal.
Bei Dauerlast wird Serverless teuer: Eine Lambda-Funktion, die 24/7 mit 1 GB Memory läuft, kostet über 40 USD/Monat – ein Container auf Fargate oder ECS wäre günstiger. Die Kostenoptimierungsregel: Serverless für variable Last, Container für stabile Last.
Weitere Grenzen: Cold Starts (1-5 Sekunden bei Java/C#), maximale Ausführungszeit (15 Minuten bei Lambda), Payload-Limits (6 MB synchron) und Vendor-Lock-in (EventBridge, Step Functions sind AWS-proprietär).
Häufige Fragen
Ist Serverless wirklich serverless?
Nein – Server existieren, aber der Cloud-Provider verwaltet sie. Der Kunde sieht keine Server, patcht keine Server und skaliert keine Server. „Serverless“ bedeutet: keine Infrastruktur-Verantwortung, nicht keine Infrastruktur.
Wie debuggt man Serverless-Anwendungen?
AWS X-Ray und CloudWatch Logs sind die nativen Tools. Lumigo und Epsagon (jetzt Cisco) bieten bessere Visualisierung verteilter Serverless-Traces. Lokales Testen mit SAM CLI oder LocalStack simuliert die AWS-Umgebung auf dem Entwickler-Laptop.
Kann man Serverless ohne AWS nutzen?
Ja. Azure Functions + Logic Apps + Event Grid bieten ein ähnliches Ökosystem. Google Cloud Functions + Workflows + Eventarc ebenfalls. Open-Source-Alternativen (Knative, OpenFaaS) laufen auf Kubernetes. Die Konzepte sind portabel, die Implementierungen Provider-spezifisch.
Wann sollte man Serverless vs. Container wählen?
Serverless für: Event-Driven-Workloads, variable Last, schnelle Time-to-Market, kleine Teams. Container für: Stabile Last, lange Laufzeit, spezifische Runtime-Anforderungen, Multi-Cloud-Portabilität. Hybrid ist üblich: Container für Core-Services, Serverless für Glue-Logic und Event-Processing.
Wie verhindert man Vendor-Lock-in bei Serverless?
Vollständig verhindern ist schwierig – Step Functions und EventBridge haben keine direkten Äquivalente bei anderen Providern. Strategien: Business-Logik in Plain-Code-Functions (portabel), Infrastruktur als Code (Terraform/Pulumi), Hexagonale Architektur (Ports & Adapters) für austauschbare Provider-Integrationen.
Quelle des Titelbildes: Pexels / panumas nikhomkhai
Lesetipps der Redaktion
cloudmagazinLenovo ThinkCentre M75q Tiny Gen 5: Enterprise-Mini-PC mit AMD PRO und 5 Watt Idle für Edge und KioskcloudmagazinServerless KI ist überbewertet – hier ist was stattdessen zähltcloudmagazinQNAP TS-464: 4-Bay-NAS mit Docker, HDMI und PCIe-Slot – was Synology in dieser Klasse nicht bietet
