Serverless mit AWS Lambda — wo es Sinn ergibt und wo nicht

Serverless verspricht null Infrastrukturmanagement, automatische Skalierung und Bezahlung nur für tatsächliche Compute-Nutzung. Nach einem Jahr Betrieb von Lambda-Funktionen in der Produktion teilen wir, was funktioniert und was nicht.

Wo Lambda glänzt¶

• Event Processing — S3-Upload-Trigger, SQS-Verarbeitung, DynamoDB Streams
• API-Backends — einfache CRUD-APIs mit API Gateway
• Geplante Aufgaben — CloudWatch Events Cron-Jobs
• Spike-Workloads — automatische Skalierung von 0 auf Tausende Instanzen

Cold Start — der Elefant im Raum¶

Lambda-Funktionen in Java/JVM: Cold Start von 3-10 Sekunden. Node.js: 100-500ms. Python: 200-800ms. Für synchrone APIs ist Cold Start ein Problem. Wir lösen es mit Provisioned Concurrency (teuer) oder Runtime-Optimierung.

Wo Lambda nicht funktioniert¶

Lang laufende Prozesse — 15 Min. Timeout. Zustandsbehaftete Anwendungen — kein lokaler Zustand. Konstante Last — EC2/ECS ist günstiger. Komplexe Orchestrierung — Step Functions helfen, aber die Komplexität wächst.

Vendor Lock-in¶

Lambda-Funktionen hängen von S3, DynamoDB, SQS, API Gateway ab… Eine Migration zu einer anderen Cloud würde das Umschreiben des größten Teils des Codes bedeuten. Der Vorteil ist, dass sich die Investition in das AWS-Ökosystem meistens auszahlt.

Serverless ist ein Werkzeug, keine Architektur¶

Lambda ist hervorragend für Event-Driven Workloads und Spike Patterns. Aber es ist keine Wunderwaffe — für konstante Last und komplexe Anwendungen bleiben wir bei Kubernetes.