Serverless mit Azure Functions — wo es Sinn macht und wo nicht

Serverless klingt auf Konferenzen magisch. „Keine Server!” Natürlich, Server sind da — jemand anderes verwaltet sie nur. Nach einem Jahr mit Azure Functions haben wir ein klareres Bild, wann Serverless hilft und wann es nur Komplexität hinzufügt.

Use Case 1: Dokumentenverarbeitung ✅¶

PDF-Upload in Blob Storage → Azure Function → OCR → Metadaten in DB → Benachrichtigung. Event-Driven, unvorhersehbarer Workload, kurze Ausführungszeit. Kosten: ~$8/Monat statt ~$120/Monat für eine VM. Lehrbuch-Serverless.

Use Case 2: API Backend ❌¶

REST API auf Azure Functions — Cold Start 3-5 Sekunden. UX-Katastrophe. Premium Plan löst den Cold Start, aber Sie bezahlen für vorgewärmte Instanzen — im Grunde eine VM mit zusätzlichen Schritten. Für High-Traffic APIs sind klassische Container die bessere Wahl.

Use Case 3: Geplante Aufgaben ✅¶

Timer Trigger — Reportgenerierung, Datenbereinigung, Health Checks. Haben 5 Cron Jobs ersetzt. Weniger Infrastruktur, integriertes Monitoring, automatischer Retry.

Durable Functions — Workflow-Orchestrierung¶

Bestellung → Validierung → Zahlung → Versand. Jeder Schritt eine Funktion, der Orchestrator steuert den Ablauf, der Zustand wird automatisch persistiert. Elegant für Onboarding-Prozesse mit menschlichen Aufgaben und Wartezeiten.

Was nicht funktioniert¶

Lang laufende Prozesse — Timeout 5 Min./30 Min. Reicht nicht für Batch-Verarbeitung. Lokale Entwicklung — Debugging schlechter als Spring Boot. Vendor Lock-in — Code lässt sich nicht ohne Umschreiben auf Lambda übertragen.

Echte Zahlen¶

Consumption Plan: erste 1M Ausführungen/Monat kostenlos. Für unsere Anwendungsfälle ~$20/Monat. Gleichwertige VM ~$120. Echte Einsparungen für den richtigen Workload.

Serverless ist ein Werkzeug, keine Architektur¶

Verwenden Sie es für Event-Driven Processing, geplante Aufgaben, Glue Code. Für API-Backends und lang laufende Prozesse bleiben Sie bei Containern. Schraubendreher — hervorragend für Schrauben, schlecht für Nägel.