Beide Modelle lösen dasselbe Problem: Code soll laufen, erreichbar sein und mit der Last wachsen. Sie tun es mit gegensätzlichen Annahmen. Serverless geht davon aus, dass Last schwankt und Leerlauf nichts kosten soll. Container gehen davon aus, dass Last einigermaßen vorhersehbar ist und Kontrolle über die Laufzeitumgebung wichtiger ist als der Preis der Leerlaufminute.
Das Lastprofil ist die eigentliche Entscheidungsgrundlage
Vor jeder Technologiediskussion steht eine Messung oder wenigstens eine belastbare Schätzung: Wie sieht der Verlauf über den Tag aus, wie weit liegen Mittelwert und Spitze auseinander, und wie lange dauert eine einzelne Verarbeitung?
- Stark schwankend mit langen Ruhephasen: Serverless — bezahlt wird nur die tatsächliche Ausführung.
- Gleichmäßig hoch über den Tag: Container — Dauerlast in einem Abrechnungsmodell pro Aufruf ist regelmäßig teurer.
- Selten, aber lang laufend: Container oder Batch-Jobs — Serverless-Plattformen begrenzen die Laufzeit je Aufruf.
- Unvorhersehbare Spitzen: Serverless für den Puffer, Container für die Grundlast — die Mischform.
Der teuerste Fehler ist nicht die falsche Wahl, sondern die Wahl ohne Zahlen. Ein Dienst mit gleichmäßiger Grundlast kostet in einem Pro-Aufruf-Modell schnell ein Vielfaches der Containervariante — und fällt trotzdem nicht auf, weil die Rechnung monatlich in vielen kleinen Positionen erscheint.
Kaltstart: relevant oder nicht
Läuft in einer Serverless-Umgebung länger keine Anfrage, wird die Umgebung abgebaut. Die nächste Anfrage muss sie neu aufbauen — der Kaltstart. Je nach Laufzeit und Abhängigkeiten kostet das von wenigen Millisekunden bis zu mehreren Sekunden.
Ob das zählt, hängt vom Aufrufer ab. Bei einer nächtlichen Verarbeitung ist es gleichgültig. Bei einem interaktiven Formular ist eine Sekunde Verzögerung im ersten Aufruf ein spürbarer Bruch. Gegenmittel gibt es — vorgewärmte Instanzen, schlankere Abhängigkeiten, schneller startende Laufzeiten — aber vorgewärmte Instanzen kosten wieder im Leerlauf und heben damit den zentralen Vorteil teilweise auf.
Grenzen, die erst im Betrieb auffallen
Serverless-Plattformen setzen harte Obergrenzen, die in der Entwicklung selten erreicht werden und im Produktivbetrieb plötzlich greifen.
- Maximale Laufzeit je Aufruf: lange Importe, Reports oder Videokonvertierungen brechen ab.
- Speicher- und Paketgrößen: größere Bibliotheken passen nicht ohne Umwege.
- Gleichzeitige Ausführungen: ein Kontingent, das bei Lastspitzen zur Drosselung führt.
- Kein persistenter lokaler Zustand: jede Ausführung startet praktisch von vorn.
- Verbindungslimits zur Datenbank: viele parallele Ausführungen erschöpfen den Verbindungspool.
Der letzte Punkt ist der häufigste Stolperstein. Serverless skaliert die Ausführungen weit schneller, als eine relationale Datenbank Verbindungen annehmen kann — deshalb gehört ein Verbindungspooler dazwischen, sonst kippt die Datenbank genau dann, wenn das System erfolgreich ist.
Der Betriebsaufwand gehört in die Rechnung
Container geben volle Kontrolle über die Laufzeitumgebung und verlangen sie zugleich. Basis-Images aktualisieren, Sicherheitslücken schließen, Skalierungsregeln pflegen, Cluster betreiben — das ist wiederkehrende Arbeit, die selten in der Kostenbetrachtung auftaucht.
Bei kleinen Teams ist dieser Aufwand oft der entscheidende Posten. Eine Serverless-Lösung, die auf dem Papier teurer ist, kann günstiger sein, sobald die Personalstunden für den Betrieb mitgerechnet werden. Umgekehrt relativiert sich das, sobald ein Cluster ohnehin für andere Dienste läuft — dann ist der zusätzliche Dienst darauf nahezu aufwandsneutral.
Portabilität und Bindung an den Anbieter
Container sind weitgehend portabel: dasselbe Image läuft bei einem anderen Anbieter oder im eigenen Rechenzentrum. Serverless-Funktionen sind über Ereignisformate, Berechtigungsmodelle und Umgebungsvariablen enger an eine Plattform gebunden.
Diese Bindung ist beherrschbar, wenn die Geschäftslogik konsequent von der plattformspezifischen Einstiegsschicht getrennt wird — die Funktion nimmt das Ereignis entgegen, übersetzt es und ruft eine Bibliothek auf, die nichts von der Plattform weiß. Der Aufwand ist gering, der Effekt beim Wechsel erheblich; die Systematik beschreibt der Beitrag zu Vendor Lock-in vermeiden.
Die Mischform ist der Normalfall
In der Praxis gewinnt selten ein Modell allein. Bewährt hat sich, die dauerhaft laufenden Kernkomponenten in Containern zu betreiben und alles Ereignisgesteuerte, Unregelmäßige oder Randständige serverless anzubinden: Webhooks, Bildverarbeitung, geplante Aufgaben, Benachrichtigungen.
Diese Aufteilung folgt genau dem Lastprofil. Sie erfordert allerdings, dass beide Welten dieselbe Beobachtbarkeit haben — gleiche Protokollformate, durchgängige Nachverfolgung, gemeinsames Alarmierungssystem. Zwei getrennte Betriebsmodelle mit zwei getrennten Monitorings sind der Zustand, in dem Fehler zwischen den Systemen verschwinden.