Serverless-Architektur: Wann sie sich lohnt und wann nicht

Kurz gefasst: Eine Serverless-Architektur lohnt sich für Anwendungen mit unregelmäßiger oder stark schwankender Last, für ereignisgesteuerte Aufgaben wie Webhooks und Dateiverarbeitung und für Teams, die keine Server betreuen wollen. Bei gleichmäßig hoher Last, lang laufenden Prozessen oder strengen Anforderungen an Antwortzeiten ist ein klassischer Server oder ein Container oft günstiger und einfacher. Viele Systeme fahren mit einer Mischung am besten.

Was Serverless bedeutet

Server gibt es natürlich auch hier. Der Begriff beschreibt, dass Sie sich nicht um sie kümmern: Kein Betriebssystem zu patchen, keine Kapazität zu planen, keine Maschinen hochzufahren. Sie schreiben Funktionen, laden sie bei einem Anbieter wie AWS Lambda, Google Cloud Run Functions oder Azure Functions hoch, und der Anbieter führt sie bei Bedarf aus.

Abgerechnet wird nach tatsächlicher Nutzung, also nach Anzahl der Aufrufe und Rechenzeit. Läuft nichts, kostet es fast nichts. Kommt plötzlich viel Last, startet der Anbieter automatisch weitere Instanzen. Zum Serverless-Umfeld gehören außerdem verwaltete Dienste wie Datenbanken, Warteschlangen und Dateispeicher, die ebenfalls ohne eigene Server auskommen.

Wann Serverless sinnvoll ist

Schwankende oder unvorhersehbare Last

Eine Anwendung, die tagsüber wenig und zu bestimmten Zeiten sehr viel Last hat, etwa bei Aktionen, Anmeldefristen oder saisonalen Spitzen, profitiert von der automatischen Skalierung. Sie zahlen nicht für Kapazität, die die meiste Zeit ungenutzt bleibt.

Ereignisgesteuerte Aufgaben

Webhooks verarbeiten, hochgeladene Bilder verkleinern, PDFs erzeugen, nachts einen Bericht versenden: Solche Aufgaben werden durch ein Ereignis ausgelöst, laufen kurz und sind dann erledigt. Genau dafür ist Serverless gebaut.

Kleine Teams und frühe Produktphasen

Wer ein MVP baut oder ohne eigenes DevOps-Team arbeitet, spart mit Serverless Betriebsaufwand. Das Team kann sich auf die Funktionen konzentrieren, statt Server zu warten.

Wann Serverless problematisch wird

Kaltstarts

Wird eine Funktion länger nicht aufgerufen, muss der Anbieter beim nächsten Aufruf erst eine neue Umgebung starten. Diese Verzögerung, der Kaltstart, ist bei Hintergrundaufgaben egal, bei einer interaktiven API aber spürbar. Es gibt Gegenmaßnahmen wie vorgehaltene Instanzen, die aber wieder laufende Kosten verursachen.

Lange Laufzeiten und dauerhafte Verbindungen

Funktionen haben Zeitgrenzen, bei AWS Lambda maximal 15 Minuten. Lange Datenverarbeitungen, Videokodierung oder dauerhaft offene WebSocket-Verbindungen passen schlecht in dieses Modell. Auch Datenbankverbindungen sind ein Thema: Viele parallele Funktionsinstanzen können eine klassische relationale Datenbank mit Verbindungen überlasten, wenn kein Connection-Pooling vorgeschaltet ist.

Gleichmäßig hohe Last

Bei einer Anwendung, die rund um die Uhr gleichmäßig ausgelastet ist, wird die Abrechnung pro Aufruf schnell teurer als ein fest gemieteter Server oder Container. Ein Kostenvergleich auf Basis Ihrer realen Last lohnt sich. Weitere Ansätze beschreibt unser Beitrag zur Kostenoptimierung in der Cloud.

Abhängigkeit vom Anbieter

Serverless-Anwendungen nutzen oft eng verzahnte Dienste eines Anbieters: Funktionen, Warteschlangen, Authentifizierung, Datenbank. Ein späterer Wechsel bedeutet viel Umbau. Eine saubere Trennung zwischen Geschäftslogik und anbieterspezifischem Code hält diese Abhängigkeit kleiner.

Betrieb, Fehlersuche und Datenschutz

Verteilte Funktionen sind schwerer zu überblicken als eine einzelne Anwendung. Ein Fehler kann über mehrere Funktionen und Warteschlangen wandern, bevor er sichtbar wird. Strukturierte Logs, Tracing über Dienstgrenzen hinweg und Alarme sind deshalb von Anfang an nötig. Wie das aussieht, zeigt unser Artikel über Monitoring und Observability.

Für den Datenschutz gilt: Die großen Anbieter haben Rechenzentren in der EU, AWS etwa in Frankfurt. Wählen Sie die Region bewusst, schließen Sie einen Auftragsverarbeitungsvertrag und prüfen Sie, welche Zusatzdienste Daten außerhalb dieser Region verarbeiten.

Die Mischform als Normalfall

In der Praxis ist die Frage selten „Serverless oder nicht“. Eine typische Architektur betreibt die Hauptanwendung als Container oder auf einem Server und lagert Hintergrundaufgaben, Webhooks und zeitgesteuerte Jobs in Funktionen aus. Plattformen wie Vercel oder Netlify verbinden beides, indem sie Frontends ausliefern und serverseitige Logik als Funktionen oder am Netzwerkrand ausführen. Wie Edge-Funktionen sich davon unterscheiden, beschreibt unser Beitrag zu Edge Computing. Und wer die Grundsatzfrage zur Struktur seiner Anwendung klären möchte, findet in unserem Vergleich Microservices oder Monolith eine Entscheidungshilfe.

Häufige Fragen (FAQ)

Ist Serverless immer günstiger als ein eigener Server?

Nein. Bei geringer oder stark schwankender Last ist Serverless meist günstiger, bei gleichmäßig hoher Last oft teurer. Vergleichen Sie die Kosten anhand Ihrer tatsächlichen Aufrufzahlen und Laufzeiten.

Kann ich eine bestehende Anwendung auf Serverless umstellen?

Teilweise. Einzelne Aufgaben wie Dateiverarbeitung oder Webhooks lassen sich gut herauslösen. Eine komplette Umstellung erfordert meist einen größeren Umbau, weil Zustand, Datenbankzugriffe und lange Prozesse anders gelöst werden müssen.

Wie gehe ich mit Kaltstarts um?

Halten Sie Funktionen klein und mit wenigen Abhängigkeiten, damit sie schnell starten. Für zeitkritische Endpunkte bieten die Anbieter vorgehaltene Instanzen an. Wenn eine API dauerhaft schnelle Antworten braucht, ist ein Container oft die einfachere Lösung.

Ist Serverless DSGVO-konform nutzbar?

Ja, wenn Sie eine EU-Region wählen, einen Auftragsverarbeitungsvertrag abschließen und darauf achten, dass Logs und Zusatzdienste ebenfalls in der EU bleiben. Die Verantwortung für die Konfiguration liegt bei Ihnen.

Fazit

Serverless spielt seine Stärken bei kurzen, ereignisgesteuerten Aufgaben und schwankender Last aus. Wer die Hauptanwendung dort betreibt, wo sie am günstigsten und vorhersehbarsten läuft, und Funktionen gezielt ergänzt, bekommt die Vorteile ohne die typischen Nachteile.

Wenn Sie die passende Architektur für Ihre Anwendung klären möchten, sprechen Sie mit uns über Webentwicklung.