Serverless oder Container? Entscheiden Sie nach Last und Laufzeit

Für kurzlebige, ereignisgesteuerte Arbeitslasten eignet sich Serverless, für langlaufende, zustandsbehaftete oder ressourcenhungrige Dienste sind Container die bessere Wahl. Entscheidend sind drei Punkte: wie das jeweilige Modell skaliert, wie abgerechnet wird und wie viel Kontrolle über den Betrieb Ihnen bleibt. Serverless tauscht Kontrolle gegen Bequemlichkeit, Container tauschen Bequemlichkeit gegen planbare Leistung und Portabilität.

---

Kurz gefasst:

• Bei gleichmässigem, planbarem Verkehr sind Container die erste Wahl, weil sie günstiger sind und berechenbare Leistung liefern. Serverless passt zu stossweisem, ereignisgesteuertem Verkehr.

• Die Autoskalierung von Kubernetes reagiert träge auf externe Messwerte, während Serverless-Funktionen nahezu sofort skalieren. Das macht sich bei latenzempfindlichen Anwendungen bemerkbar.

• Container tragen zustandsbehaftete Verbindungen und lange Sitzungen deutlich leichter als Serverless-Funktionen, die bewusst zustandslos ausgelegt sind.

• Die Kostenunterschiede sind erheblich: Container kosten die reservierte Kapazität, unabhängig von der Nutzung, Serverless rechnet pro Anfrage und Ausführungszeit ab. Das spricht für sporadische Arbeitslasten.

• Entscheidend für die Wahl der Architektur sind das Know-how im Team, die Planbarkeit der Last und Vorgaben zum Datenstandort. In produktiven Systemen sind Mischformen die Regel.

---

Was sind Container?

Ein Container packt eine Anwendung samt ihren Abhängigkeiten in ein einziges Image, gebaut im OCI-Format (Open Container Initiative). So läuft sie auf dem Notebook, auf dem Testserver und im produktiven Cluster genau gleich. Darunter sorgen Linux-Namespaces für die Abschottung und cgroups für Obergrenzen bei Prozessor und Arbeitsspeicher. Deshalb können sich mehrere Container einen Host teilen, ohne sich gegenseitig zu stören.

Einen Container zu betreiben, ist einfach. Hunderte im Produktivbetrieb zu betreiben, ist der Moment, in dem Kubernetes ins Spiel kommt. Kubernetes verteilt Container auf Knoten, startet ausgefallene neu und fügt über den Horizontal Pod Autoscaler anhand von Prozessorlast, Arbeitsspeicher oder eigenen Messwerten Repliken hinzu oder entfernt sie. Geprüft wird dabei in wiederkehrenden Intervallen, nicht sofort. Kubernetes übernimmt zudem die Dienstsuche, damit Container einander über ihren Namen finden, sowie rollende Aktualisierungen, damit eine neue Version ohne Ausfallzeit live geht.

Der Betriebszyklus rund um Container sieht so aus:

• Ein Container-Image bauen und es im Rahmen der CI/CD-Strecke in eine Registry hochladen.

• Das Image in einen Cluster ausrollen, wo Kubernetes es auf freie Knoten verteilt.

• Die darunterliegenden Knoten überwachen und patchen, denn Betriebssystem und Laufzeitumgebung liegen in Ihrer Verantwortung.

• Repliken von Hand oder automatisch anpassen, wenn sich die Last verändert.

Genau dort liegt der Kompromiss: Sie haben die volle Kontrolle über die Laufzeitumgebung, tragen aber auch den gesamten Unterhalt, von Knoten-Aktualisierungen bis zu Sicherheits-Patches.

Was ist Serverless?

Serverless, genauer Function as a Service (FaaS), erlaubt es Ihnen, eine einzelne Funktion bereitzustellen, die auf ein Ereignis hin läuft: eine HTTP-Anfrage, eine Nachricht in einer Warteschlange, ein hochgeladenes File. Es gibt keinen Server, den Sie bereitstellen oder patchen müssten. Die Plattform startet eine Ausführungsumgebung, lässt Ihren Code laufen und fährt sie wieder herunter, sobald die Arbeit erledigt ist.

Die Abrechnung folgt derselben Logik. Statt für einen laufenden Server zahlen Sie für Anfragen und Ausführungszeit, üblicherweise auf die Millisekunde genau, zuzüglich des zugeteilten Arbeitsspeichers. AWS Lambda ist die verbreitetste Umsetzung dieses Modells, und seine Grenzen prägen, wie Sie darum herum entwerfen.

Diese Mechanismen sollten Sie kennen, bevor Sie sich für Serverless entscheiden:

• Funktionen haben eine maximale Laufzeit und eine Obergrenze beim Arbeitsspeicher. Langlaufende oder speicherhungrige Aufgaben brauchen deshalb eine andere Architektur.

• Reservierte Nebenläufigkeit sichert einer Funktion einen festen Anteil an Kapazität zu, während provisioned concurrency Umgebungen vorab initialisiert, um Kaltstarts zu verkürzen. Das kostet zusätzlich, abgerechnet pro Version oder Alias.

• Serverless-Funktionen greifen in der Regel auf verwaltete Dienste zu, etwa ein API-Gateway oder eine verwaltete Datenbank, statt diese Logik selbst zu beherbergen.

• Der Aufruf verhält sich unterschiedlich: Synchrone Aufrufe liefern direkt eine Antwort zurück, asynchrone können Wiederholungen auslösen oder Fehler in eine Dead-Letter-Queue umleiten.

Dieses Modell spielt seine Stärken aus, wenn der Verkehr stossweise oder schwer vorhersehbar ist, denn zwischen den Ereignissen zahlen Sie nicht für ungenutzte Kapazität.

Die Unterschiede, die den Ausschlag geben

Sobald man hinter die Verkaufsargumente schaut, gehen die beiden Modelle deutlich auseinander. Und die Unterschiede lassen sich an Merkmalen der Arbeitslast festmachen, die Sie messen können, bevor Sie überhaupt etwas bauen.

1. Verhalten bei der Autoskalierung. Der Kubernetes-HPA reagiert in festen Intervallen auf Messwerte und skaliert Repliken innerhalb der Grenzen, die Sie setzen. Werkzeuge wie KEDA erweitern dieses Modell um externe Messwerte wie die Länge einer Warteschlange und schliessen damit einen grossen Teil des Abstands zur Elastizität von Funktionen. Serverless-Plattformen skalieren pro Aufruf und nahezu sofort. Das passt zu Lastspitzen, nimmt Ihnen aber die feine Kontrolle darüber, wie viele Instanzen gleichzeitig laufen.

2. Kostenmodell und böse Überraschungen. Container kosten die reservierte Kapazität, ob Sie sie nutzen oder nicht. Serverless rechnet pro Anfrage und Dauer ab, was bei sporadischen Arbeitslasten günstiger und bei dauerhaft hohem Volumen teurer ist. Bei AWS Lambda wächst die Prozessorleistung proportional zum zugeteilten Arbeitsspeicher. Wer also mehr Speicher zuteilt, um eine langsame Funktion zu beschleunigen, treibt die Rechnung unbemerkt hoch, falls die Arbeitslast gar nie prozessorgebunden war.

3. Latenz und Kaltstarts. Ein bereits laufender Container antwortet sofort. Eine Funktion, die untätig war, muss zuerst eine Umgebung hochfahren, was Latenz hinzufügt. Provisioned concurrency bei Lambda und vorgewärmte Container-Pools lösen das beide, allerdings um den Preis, dass Sie wieder für ungenutzte Kapazität zahlen.

4. Zustand. Container können Sitzungsdaten im Arbeitsspeicher halten oder lange Verbindungen über mehrere Anfragen hinweg offen lassen. Serverless-Funktionen sind bewusst zustandslos ausgelegt und lagern Sitzungsdaten typischerweise in einen externen Speicher aus. Deshalb landen zustandsbehaftete Arbeitslasten standardmässig bei Containern.

5. Portabilität und Abhängigkeit vom Anbieter. Ein Container-Image läuft auf jeder OCI-kompatiblen Laufzeitumgebung, und Kubernetes selbst ist eine über Clouds hinweg portable Abstraktion. Serverless-Funktionen werden gegen die APIs, Ereignisformate und Grenzen eines bestimmten Anbieters gebaut. Ein Wechsel ist deshalb kein erneutes Ausrollen, sondern ein Neuschreiben.

6. Werkzeuge und Beobachtbarkeit. Container-Plattformen bringen ausgereifte Werkzeuge für Tracing und Fehlersuche mit, die auf langlebige Prozesse ausgelegt sind. Bei Serverless hängt die Fehlersuche stärker an Logs und anbieterspezifischem Tracing, denn Sie können keinen Debugger an eine Umgebung hängen, die nach dem Aufruf nicht mehr existiert.

Praxistipp: Bevor Sie sich für ein Skalierungsmodell entscheiden, testen Sie Ihre Funktion oder Ihren Container unter realistischer Last und messen Sie mittlere Laufzeit, maximale Nebenläufigkeit und Speicherverbrauch. Diese drei Zahlen sagen mehr über die Eignung aus als jedes Architekturdiagramm.

Wo sich die beiden Modelle überschneiden und wie Teams sie kombinieren

Container und Serverless stehen auf demselben cloud-nativen Fundament: Microservices, unveränderliche Auslieferungen und CI/CD-Strecken, die kleine, unabhängige Code-Einheiten ausliefern. In der Praxis ist die Trennlinie weniger scharf als in der Theorie.

Ein verbreitetes Mischmodell betreibt die Kerndienste, etwa eine API oder ein zustandsbehaftetes Backend, in Containern auf Kubernetes, während Ereignis-Handler, Webhooks und geplante Aufgaben daneben als Funktionen laufen. Werkzeuge wie KEDA und Knative verwischen die Grenze weiter: Sie lassen Container auf null herunterskalieren und sich wie Funktionen verhalten, wenn kein Verkehr mehr anfällt. Umgekehrt verpacken Ansätze nach dem Muster «Funktionen in Containern» FaaS-artigen Code als Container-Image, um ihn portabel zu machen.

Wann was passt: typische Szenarien

Meist ergibt sich die richtige Wahl von selbst, sobald Sie die Art der Arbeitslast benennen.

• APIs und Webdienste mit gleichmässigem, planbarem Verkehr laufen auf Containern in der Regel günstiger, denn die Abrechnung pro Anfrage summiert sich bei dauerhaftem Volumen rasch.

• Hintergrundprozesse und Stapelverarbeitung, die kurz und unregelmässig laufen, passen natürlicherweise zu Serverless, weil Sie nicht für untätige Arbeitskapazität zahlen.

• ML-Inferenz auf GPUs braucht fast immer Container, denn Serverless-Plattformen bieten nur selten Zugriff auf GPUs, und lange Ladezeiten von Modellen vertragen sich schlecht mit den Zeitlimiten von Funktionen.

• Ereignisgesteuerte Abläufe und Verbindungscode, etwa das Verkleinern eines Bildes nach dem Hochladen oder das Weiterreichen eines Webhooks, sind der Lehrbuchfall für Serverless.

• Dienste mit hohem Durchsatz im grossen Massstab sprechen bei den Kosten meist für Container, denn eine dauerhaft ausgelastete Funktion kostet pro Recheneinheit mehr als ein Container, der dieselbe Arbeitslast durchgehend abarbeitet.

Die Umfragedaten aus CNCF’s State of Cloud Native Development stützen dieses Bild: Container werden im ersten Quartal 2025 von rund 61 % der Backend-Entwickler:innen eingesetzt, Serverless von rund 20 %. Der Bericht hält zudem fest, dass die Nutzung von Serverless über die Zeit zurückgegangen ist, weil gleichmässige, intensiv genutzte Arbeitslasten wie maschinelles Lernen bei einer Abrechnung pro Aufruf weniger wirtschaftlich sind.

So entscheiden Sie: eine Checkliste für die Praxis

Gehen Sie diese Punkte durch, bevor Sie sich auf eines der Modelle festlegen.

1. Erfassen Sie Ihr Lastmuster: gleichmässig, stossweise oder überwiegend untätig mit gelegentlichen Spitzen?

2. Schätzen Sie Anfragen pro Sekunde, mittlere Ausführungszeit und maximale Nebenläufigkeit unter realistischer Last.

3. Prüfen Sie, ob die Arbeitslast zwischen den Anfragen einen Zustand oder lange Verbindungen halten muss.

4. Klären Sie Vorgaben zu Compliance und Datenstandort, die bestimmte verwaltete Dienste ausschliessen könnten.

5. Beurteilen Sie die Fähigkeiten Ihres Teams: Der Betrieb von Containern und Kubernetes verlangt anderes Wissen als das Bereitstellen von Funktionen und das Verdrahten von Ereignissen.

6. Fragen Sie Ihre Plattform oder Ihren Anbieter nach SLA-Zusagen, dem Verhalten bei Kaltstarts und danach, wie ein Weg weg von dieser Plattform konkret aussähe.

Auf Seite der Container liegt die Nutzung von Kubernetes im ersten Quartal 2025 bei rund 61 % der Backend-Entwickler:innen, gegenüber rund 20 % bei Serverless. Dieser Abstand zeigt: Container bleiben die Standardwahl für die meisten produktiven Backends, auch wenn Serverless seine feste Nische behauptet.

Warnsignale, bei denen Sie innehalten sollten: eine harte Abhängigkeit von anbieterexklusiven APIs ohne Abstraktionsschicht, Kaltstarts ohne Gegenmassnahmen auf latenzempfindlichen Pfaden und eine Beobachtbarkeit, die bei einfachen Logs endet, ohne verteiltes Tracing.

Beobachtungen aus Architektur-Reviews

In Architektur-Reviews zeigt sich immer wieder dasselbe Muster: Teams greifen zu Serverless, weil der Einstieg einfacher wirkt, und stossen dann an Grenzen, sobald der Verkehr gleichmässig wird oder die Arbeitslast einen Zustand braucht. Ein Review durch erfahrene Leute ganz am Anfang statt mitten im Bau ist meist das, was dies auffängt, bevor daraus ein Neuschreiben wird.

Für Teams, die Container im Produktivbetrieb führen, zahlen sich einige Praktiken verlässlich aus: GitOps für Auslieferungen, damit der Zustand des Clusters einer versionierten Quelle der Wahrheit entspricht, eine bewusst gewählte Strategie für provisioned concurrency statt eines nachträglichen Einfalls, und CI/CD-Strecken, die Images bauen und prüfen, bevor sie überhaupt einen Cluster erreichen. Auch Anforderungen an die Datensouveränität prägen die Entscheidung stärker, als die meisten Teams erwarten. Der Kubernetes Service von Swisscom ist ein gutes Beispiel: Er wurde als anbieterunabhängige, regelkonforme Alternative zu Kubernetes-Angeboten der Hyperscaler gebaut und trägt produktive Arbeitslasten im grossen Massstab für Organisationen, die ihre Infrastruktur im Land behalten müssen. Ampersand hat vergleichbar anspruchsvolle Betriebsumgebungen geführt, darunter eine Mehrstandort-Plattform mit über 600 Websites aus einem einzigen System, bei der Beständigkeit im Betrieb wichtiger war als jede einzelne Skalierungsentscheidung.

Wie Ampersand Teams hilft, die richtige Architektur zu wählen und zu bauen

Die Wahl zwischen Serverless und Containern ist selten eine einmalige Entscheidung, sie prägt Ihre Kosten und die Arbeitslast Ihres Teams über Jahre. Ampersand führt Architektur-Reviews durch, bei denen erfahrene Entwickler:innen ab dem ersten Gespräch dabei sind. So ist die Empfehlung, die Sie erhalten, an Ihre tatsächlichen Lastmuster und die Fähigkeiten Ihres Teams gebunden und keine Standardantwort.

Wenn Sie bereits wissen, dass etwas gebaut werden muss, sei es eine neue Plattform, eine Migration weg von einem Altsystem oder eine Integrationsschicht, die Container und verwaltete Dienste verbindet, schnürt Ampersand die Arbeit als Projekt mit festem Umfang oder als laufende Zusammenarbeit. Für Teams, die Architekturentscheide fortlaufend statt nur einmal überprüft haben möchten, gibt es Pläne für laufende technische Unterstützung. Aktuelle Angaben zu Paketen und Preisen finden Sie auf der Preisseite. Alle Angaben zu Paketen und Preisen finden Sie auf der Preisseite. Beginnen Sie mit einem Gespräch über Ihre Arbeitslast, dann liegt die richtige Architektur meist lange vor der ersten Zeile Code auf der Hand.

Quellen

• Horizontal Pod Autoscaler

• provisioned concurrency

• CNCF’s State of Cloud Native Development

Häufige Fragen

Ist Serverless günstiger als Container?

Das hängt vom Lastmuster ab: Bei sporadischen oder stossweisen Arbeitslasten ist Serverless meist günstiger, weil Sie pro Anfrage und Ausführungszeit zahlen. Bei gleichmässigem Verkehr mit hohem Volumen sind Container meist günstiger, weil kein Aufschlag pro Aufruf anfällt. Die Umfragedaten der CNCF zeigen, dass Container unter Backend-Entwickler:innen insgesamt die verbreitetere Option bleiben.

Kann Kubernetes so skalieren wie Serverless?

Der eingebaute Horizontal Pod Autoscaler von Kubernetes skaliert Repliken in festen Intervallen anhand von Prozessorlast, Arbeitsspeicher oder eigenen Messwerten. Das ist langsamer und gröber als die Skalierung auf Funktionsebene. Werkzeuge wie KEDA erweitern dies um externe Ereignisquellen wie die Länge einer Warteschlange und schliessen einen grossen Teil des Abstands zur Elastizität von Serverless, während die Arbeitslasten in Containern bleiben.

Wie vermeide ich bei Serverless die Abhängigkeit von einem Anbieter?

Serverless-Funktionen werden gegen die Ereignisformate und APIs eines bestimmten Anbieters gebaut, vollständige Portabilität ist deshalb schwierig. Sie können das Risiko aber begrenzen, indem Sie die Geschäftslogik in gemeinsam genutzten Bibliotheken halten, getrennt vom Handler-Code. Container umgehen dieses Problem weitgehend, denn ein OCI-Image läuft auf jeder kompatiblen Laufzeitumgebung, auch auf einer souveränen Plattform wie dem Kubernetes Service von Swisscom.

Sind Kaltstarts bei Serverless immer ein Problem?

Kaltstarts fallen vor allem bei latenzempfindlichen Anfragen ins Gewicht, die Nutzende direkt betreffen. Bei Hintergrundaufgaben oder asynchroner Verarbeitung, wo eine kurze Verzögerung unsichtbar bleibt, spielen sie kaum eine Rolle. Provisioned concurrency verringert Kaltstarts, indem Ausführungsumgebungen vorab initialisiert bleiben. Das kostet zusätzlich, und zwar umso mehr, je mehr Nebenläufigkeit Sie reservieren.

Empfohlen

• Die Mitte: Running 600+ websites for a Swiss political party from one system.

• Arthouse Kinos: A new website and ticket shop for Zürich’s most iconic cinemas.

• Mikron: A showroom on a laptop, for machines too big to bring to the fair.

• Repa Immobiliare: Getting a property portfolio off paper, with software that never goes online.