Serverless vs. Container: Welche Architektur passt zu Ihrer Software?

Serverless ist meist die bessere Wahl für ereignisgesteuerte, kurze Aufgaben mit stark schwankender Last. Mit Containern fahren Sie besser, wenn eine Anwendung dauerhaft läuft, gleichmäßig ausgelastet ist oder über Jahre portabel bleiben soll. Kubernetes ist kein drittes Modell, sondern ein Werkzeug, das viele Container gleichzeitig steuert. Es lohnt sich erst, wenn Ihre Anwendung aus mehreren Diensten besteht und jemand den Betrieb wirklich verantwortet. In diesem Beitrag erklären wir die Unterschiede, rechnen die Kostenlogik durch, gehen auf Vendor Lock-in und DSGVO ein und geben Ihnen fünf Fragen an die Hand, mit denen Sie die Entscheidung für Ihr eigenes Projekt treffen.

Mintellity

Die passende Architektur für Ihre Software

Mintellity entwickelt maßgeschneiderte Software, die sich an Ihren individuellen Prozessen und Anforderungen orientiert.

Mintellity kennenlernen

TL;DR

Serverless heißt: Sie liefern Code, der Cloud-Anbieter kümmert sich um Server, Skalierung und Abrechnung pro Aufruf. Das ist ideal für Webhooks, Datei-Verarbeitung, Cronjobs und Prototypen.
Container verpacken Ihre Anwendung mit allen Abhängigkeiten. Sie laufen fast überall gleich und eignen sich für langlebige, rechenintensive oder komplexe Anwendungen.
Kubernetes orchestriert viele Container. Es bringt viel Kontrolle, verlangt aber Know-how und laufenden Betriebsaufwand.
Kosten: Bei sporadischer Last ist Serverless oft günstiger, bei hoher, konstanter Last sind Container meist planbarer.
Strategie: Achten Sie früh auf Portabilität und Datenstandort. Beides ist später nur noch teuer zu korrigieren.

Was Serverless und Container wirklich bedeuten

Beide Begriffe werden oft als Gegensätze behandelt, dabei lösen sie dasselbe Grundproblem: Software soll schnell ausgeliefert werden, zuverlässig laufen und Ressourcen sparsam nutzen. Der Unterschied liegt darin, wie viel Verantwortung Sie selbst behalten.

Serverless: Sie liefern Funktionen, nicht Server

Bei Serverless (oft auch Function as a Service genannt) schreiben Sie einzelne Funktionen, die auf ein Ereignis reagieren: eine HTTP-Anfrage, einen Datei-Upload, eine Nachricht in einer Warteschlange. Der Anbieter startet die Funktion bei Bedarf, skaliert sie automatisch und fährt sie wieder herunter, wenn nichts zu tun ist. Abgerechnet wird nach Aufrufen und Laufzeit, nicht nach reservierten Servern.

„Serverlos“ ist dabei nur aus Ihrer Sicht wahr. Unter der Haube stecken hochgradig virtualisierte Umgebungen. AWS beschreibt etwa, wie Lambda isolierte MicroVMs für Szenarien einsetzt, in denen Nutzer oder KI-Agenten Code ausführen. Diese Technik (Firecracker) verbindet die Isolation einer virtuellen Maschine mit Startzeiten, die fast an einen normalen Prozess heranreichen. Für Anwendungen, die fremden oder nutzergenerierten Code ausführen, ist das ein echtes Argument.

Container: Ihre Anwendung im portablen Paket

Ein Container bündelt Ihren Code mit Laufzeitumgebung, Bibliotheken und Konfiguration. Das Ergebnis ist ein Image, das auf dem Laptop eines Entwicklers genauso läuft wie in der Cloud oder auf einem eigenen Server. AWS fasst es in seinem Whitepaper so zusammen: Container bieten eine Möglichkeit, Anwendungen in einer isolierten Umgebung zu entwickeln, auszuliefern und zu betreiben. Docker ist das bekannteste Werkzeug dafür, das Image-Format selbst ist offen standardisiert.

Anders als eine Serverless-Funktion läuft ein Container so lange, wie Sie es wollen. Sie entscheiden über Arbeitsspeicher, CPU, Laufzeit und Netzwerk. Diese Freiheit bedeutet aber auch: Jemand muss Updates einspielen, Ressourcen dimensionieren und den Betrieb überwachen.

Kubernetes: der Dirigent für viele Container

Sobald eine Anwendung aus mehreren Containern besteht, etwa Frontend, API, Worker und Datenbank-Proxy, braucht es eine Steuerung. Kubernetes übernimmt das: Es verteilt Container auf Server, startet abgestürzte Instanzen neu, skaliert nach Last und rollt neue Versionen ohne Ausfallzeit aus. Die Frage „Serverless oder Kubernetes“ ist deshalb eigentlich die Frage: Wollen Sie eine Plattform selbst steuern oder die Steuerung komplett abgeben?

Der direkte Vergleich

Die folgende Tabelle fasst die Kriterien zusammen, die in unseren Architekturgesprächen mit Kunden am häufigsten den Ausschlag geben.

Kriterium	Serverless (Functions)	Container (z. B. Docker)	Kubernetes
Betriebsaufwand	sehr gering	mittel	hoch
Skalierung	automatisch, auch auf null	manuell oder per Plattform	automatisch, frei konfigurierbar
Laufzeit pro Aufgabe	kurz, vom Anbieter begrenzt	unbegrenzt	unbegrenzt
Kaltstarts	möglich	nein, wenn dauerhaft laufend	nein, wenn dauerhaft laufend
Kostenmodell	pro Aufruf und Laufzeit	pro reservierter Ressource	pro Cluster und Knoten
Portabilität	gering, stark anbieterabhängig	hoch	hoch
Kontrolle über Umgebung	gering	hoch	sehr hoch
Typischer Einsatz	Events, Webhooks, Cronjobs, MVPs	Web-Apps, APIs, Legacy-Anwendungen	Microservices, große Plattformen

Wichtig: Die Grenzen verschwimmen. AWS betont in seinem Whitepaper zur logischen Trennung, dass sich Serverless, Container und Microservices kombinieren lassen, um mehrere Isolationsebenen aufzubauen. In der Praxis sehen wir genau das am häufigsten: eine containerisierte Kernanwendung, ergänzt um einzelne Serverless-Funktionen für Randaufgaben.

Kosten: Wann welches Modell günstiger ist

Die Kostenfrage ist selten so eindeutig, wie es Marketingseiten vermuten lassen. Entscheidend ist Ihr Lastprofil.

Sporadische Last: Serverless spielt seine Stärke aus

Eine Funktion, die nur ein paar Tausend Mal am Tag kurz anläuft, kostet bei Serverless sehr wenig, weil Sie für Leerlauf nichts bezahlen. Ein Container, der rund um die Uhr auf Anfragen wartet, verursacht dagegen auch nachts Kosten. Typische Beispiele: ein Webhook, der Bestellungen aus dem Shop an die Warenwirtschaft weiterreicht, eine nächtliche PDF-Generierung oder ein internes Tool, das nur zu Bürozeiten genutzt wird.

Konstante Last: Container werden planbarer

Kippen kann die Rechnung, sobald Ihre Anwendung dauerhaft gefragt ist. Jede Anfrage kostet dann Geld, und die Summe vieler kleiner Beträge übersteigt schnell den Preis eines fest dimensionierten Servers. Hinzu kommen Posten, die man anfangs übersieht:

Gebühren pro Anfrage für API-Gateways und Funktionen, die mit dem Traffic linear wachsen.
Egress-Kosten, also Gebühren für ausgehenden Datentransfer. Bei großen US-Anbietern fallen sie spürbar höher aus als bei vielen spezialisierten europäischen Hostern.
Begleitdienste wie verwaltete Datenbanken, Logging und Monitoring, die bei Serverless fast immer zusätzlich nötig sind.

Wie deutlich die Unterschiede ausfallen können, zeigt ein Erfahrungsbericht des SaaS-Start-ups SendRec: Statt auf einen Hyperscaler zu setzen, betreibt das Team seinen gesamten Produktiv-Stack auf einem einzelnen Hetzner-Server und legt die Kosten offen. Das ist kein Modell für jedes Unternehmen, aber ein guter Realitätscheck dafür, was eine gut gebaute containerisierte Anwendung wirklich braucht.

Unser Rechenweg für Ihre Entscheidung

Statt Listenpreise zu vergleichen, empfehlen wir drei Schritte:

Lastprofil messen: Wie viele Anfragen pro Tag, wie lange dauert eine Anfrage, wie stark schwankt die Last über Tag und Woche?
Beide Modelle durchrechnen: Serverless mit Aufrufen, Laufzeit und Datentransfer, Container mit der kleinsten Servergröße, die Ihre Spitzenlast trägt.
Wachstum einplanen: Rechnen Sie mit der dreifachen und zehnfachen Last. Oft zeigt erst dieser Schritt, wo der Kipppunkt liegt.

Denken Sie dabei auch an die Personalkosten. Ein Container-Setup, das niemand pflegt, ist am Ende teurer als jede Serverless-Rechnung.

Serverless oder Kubernetes: Wann sich der Orchestrator lohnt

Kubernetes hat den Ruf, der Standard für moderne Software zu sein. Für große Plattformen stimmt das. Für viele Projekte im Mittelstand und bei Start-ups ist es aber eine Nummer zu groß.

Kubernetes lohnt sich, wenn

Ihre Anwendung aus vielen Diensten besteht, die unabhängig voneinander skalieren und ausgerollt werden sollen,
Sie strenge Anforderungen an Verfügbarkeit, Netzwerk oder Mandantentrennung haben,
Sie mehrere Umgebungen (Entwicklung, Staging, Produktion) einheitlich betreiben wollen,
ein Team oder ein Partner den Cluster dauerhaft betreut.

Serverless ist die bessere Wahl, wenn

Sie schnell ein Produkt testen wollen, ohne Infrastruktur aufzubauen,
Ihre Last stark schwankt oder zeitweise bei null liegt,
Ihre Aufgaben kurz und ereignisgesteuert sind,
Sie kein eigenes Betriebsteam haben und keines aufbauen möchten.

Dazwischen liegt für viele Unternehmen die vernünftigste Lösung: einfache Container auf einer verwalteten Plattform, ganz ohne eigenen Kubernetes-Cluster. Damit behalten Sie die Portabilität, sparen sich aber den Großteil der Komplexität.

Serverless Container: der Mittelweg

Inzwischen gibt es Dienste, die beide Welten verbinden. Sie liefern ein Container-Image, der Anbieter betreibt und skaliert es wie eine Serverless-Funktion. AWS beschreibt seinen Dienst Fargate als serverlose Compute-Engine für Container, die ohne eigene Server-Verwaltung auskommt. Google Cloud Run und Azure Container Apps folgen demselben Prinzip.

Der Vorteil: Ihre Anwendung bleibt ein Standard-Container und damit portabel, und Sie müssen trotzdem keine Server pflegen. Der Nachteil: Die Plattform selbst ist wieder anbieterspezifisch, und das Kostenmodell ähnelt dem von Serverless.

Wer europäische Anbieter bevorzugt, findet hier noch Lücken. Laut der Übersicht von Cirran bietet unter den gelisteten EU-Clouds aktuell nur Scaleway mit „Serverless Containers“ ein direktes Gegenstück, während StackIT, IONOS und Hetzner keinen direkten Ersatz haben. Klassische Container und Kubernetes gibt es dagegen bei vielen europäischen Anbietern.

Vendor Lock-in: Die Frage, die in drei Jahren zählt

In Gesprächen mit Start-ups erleben wir oft, dass die Architekturwahl allein nach der Startgeschwindigkeit getroffen wird. Das ist verständlich, denn Serverless bringt Sie in wenigen Tagen live. Der Preis zeigt sich später: Serverless-Funktionen sind eng mit den proprietären Diensten des Anbieters verwoben, mit seinen Event-Quellen, Berechtigungssystemen, Warteschlangen und Datenbanken. Ein Umzug bedeutet dann nicht „Code kopieren“, sondern Teile der Anwendung neu zu schreiben.

Ein Container-Setup ist dagegen weitgehend portabel. Dasselbe Image läuft bei einem Hyperscaler, bei einem europäischen Anbieter oder auf eigener Hardware. Das sichert Ihnen Verhandlungsspielraum bei den Kosten und Unabhängigkeit bei strategischen Entscheidungen.

Lock-in lässt sich aber auch bei Serverless begrenzen:

Geschäftslogik entkoppeln: Die eigentliche Logik liegt in normalen Modulen, die Funktion ist nur ein dünner Adapter.
Offene Standards nutzen: etwa PostgreSQL statt proprietärer Datenbanken, HTTP statt anbieterspezifischer Trigger.
Infrastruktur als Code: Werkzeuge, die mehrere Anbieter unterstützen, machen einen Wechsel planbarer.

Wie Sie das systematisch angehen, zeigen wir in unserem Leitfaden Vendor Lock-in vermeiden.

DSGVO, CLOUD Act und die Wahl des Anbieters

Für Unternehmen in der EU, die personenbezogene Daten verarbeiten, ist die Architekturfrage oft auch eine Rechtsfrage. Große US-Anbieter bieten zwar Rechenzentren in Europa an, unterliegen aber weiterhin US-Recht. SendRec nennt genau das als Grund für die Entscheidung für Hetzner: Server unter europäischer Jurisdiktion senken das Risiko, dass US-Behörden über den CLOUD Act auf Daten zugreifen.

Das spricht nicht grundsätzlich gegen Serverless, verschiebt aber die Gewichte. Weil europäische Anbieter vor allem klassische Rechenleistung, Kubernetes und Datenbanken anbieten, wie der Leitfaden von EU Alternative zur Wahl eines EU-Cloud-Anbieters zeigt, landen datenschutzsensible Projekte häufig bei Containern. Ein Tipp aus der Praxis: Prüfen Sie nicht nur, wo Ihre Anwendung läuft, sondern auch, wohin Ihre Logs, Backups und Analysedaten fließen. Dieselbe Frage stellt sich etwa beim serverseitigen Tracking und seinen datenschutzrechtlichen Grenzen: Entscheidend ist, wer die Datenverarbeitung kontrolliert.

Welche Anforderungen Ihre Software konkret erfüllen muss, klären Sie am besten mit Ihrem Datenschutzbeauftragten. Einen Überblick über die technischen Bausteine finden Sie in unserem Beitrag zu DSGVO-konformer Software.

Fünf Fragen für Ihre Entscheidung

Wenn Sie diese Fragen ehrlich beantworten, ergibt sich die Architektur meist von selbst:

Wie sieht Ihre Last aus? Schwankend oder zeitweise null spricht für Serverless, gleichmäßig hoch für Container.
Wie lange laufen Ihre Aufgaben? Kurze Ereignisse passen zu Funktionen. Lange Berechnungen, Videoverarbeitung oder KI-Inferenz mit großen Modellen passen besser in Container.
Wer betreibt das System? Ohne Betriebsteam oder Wartungspartner ist Kubernetes ein Risiko, Serverless oder verwaltete Container sind dann die sicherere Wahl.
Wie wichtig ist Ihnen Unabhängigkeit? Wenn ein späterer Anbieterwechsel realistisch ist, setzen Sie auf Container.
Welche Daten verarbeiten Sie? Sensible personenbezogene Daten machen den Anbieter und seinen Rechtsraum zum Auswahlkriterium.

Typische Szenarien aus der Praxis

Damit die Kriterien greifbar werden, hier vier Konstellationen, wie sie uns bei unseren Zielgruppen regelmäßig begegnen:

Das Start-up mit dem ersten MVP. Die Idee muss schnell zu echten Nutzern. Serverless-Funktionen plus verwaltete Datenbank sind hier ein hervorragender Startschuss. Unser Rat: Halten Sie die Geschäftslogik von Anfang an anbieterunabhängig, dann ist der spätere Umzug in Container ein überschaubares Projekt.

Der Mittelständler, der Prozesse automatisiert. Schnittstellen zu ERP, Warenwirtschaft und Buchhaltung, dazu Jobs, die nachts Daten abgleichen. Hier funktioniert oft ein Hybrid: Eine containerisierte Kernanwendung trägt die Logik, Serverless-Funktionen übernehmen Webhooks und zeitgesteuerte Aufgaben.

Der E-Commerce-Anbieter mit Lastspitzen. Black Friday, Newsletter-Versand, Saisongeschäft. Serverless fängt Spitzen elegant ab, bei dauerhaft hohem Traffic sind Container mit automatischer Skalierung oft günstiger. Viele Shops kombinieren beides.

Das Unternehmen, das KI integriert. Wer nur eine externe KI-API aufruft, ist mit Serverless gut bedient. Wer eigene Modelle betreibt oder große Datenmengen vorverarbeitet, braucht die Kontrolle über Speicher, GPU und Laufzeit, die Container bieten.

Egal, wofür Sie sich entscheiden: Eine saubere CI/CD-Pipeline und zentrales Logging sind bei beiden Modellen die Grundlage für einen stabilen Betrieb.

Unsere Sicht: Die Architektur folgt dem Prozess

Wir entwickeln Software, die sich an die Abläufe unserer Kunden anpasst, nicht umgekehrt. Genau so gehen wir auch an die Frage „Serverless oder Container“ heran. Wir starten nicht mit der Technologie, sondern mit Ihrem Prozess: Wann entstehen Daten, wie oft wird ein System genutzt, wer soll es in fünf Jahren noch weiterentwickeln können?

Unsere Erfahrung: Die meisten Projekte profitieren von einer pragmatischen Mischung. Ein portabler Container-Kern sichert Unabhängigkeit und planbare Kosten, gezielt eingesetzte Serverless-Funktionen bringen Tempo und Eleganz für ereignisgesteuerte Aufgaben. Kubernetes setzen wir dort ein, wo es echten Mehrwert bringt, und nicht, weil es gerade in jeder Stellenanzeige steht.

Technologieoffenheit heißt für uns auch, Entscheidungen revidieren zu können. Deshalb bauen wir Architekturen so, dass sie mitwachsen: Was heute als Funktion startet, kann morgen in einen Container umziehen, ohne dass Sie bei null anfangen. Weil wir Software in langfristigen Partnerschaften weiterentwickeln, sehen wir sehr genau, welche Entscheidungen sich nach Jahren auszahlen und welche teuer werden.

— Mintellity

Mit uns zur passenden Architektur

Sie planen eine neue Anwendung oder wollen ein bestehendes System in die Cloud bringen? Wir beraten Sie technologieoffen, entwickeln Ihre individuelle Software auf der Architektur, die zu Ihren Prozessen passt, und betreuen sie anschließend mit Wartung und Support. Wenn bereits eine ältere Anwendung existiert, prüfen wir im Rahmen der Softwaremodernisierung, ob Container, Serverless oder eine Kombination der richtige nächste Schritt ist. Wie ein Projekt bei uns abläuft, lesen Sie unter So arbeiten wir, praktische Hinweise zum Umzug bündelt unser Leitfaden zur Cloud-Migration von Anwendungen.

Häufige Fragen

Ist ein Container eine Form der Virtualisierung?

Ja, aber eine leichtgewichtige. Container teilen sich den Kernel des Betriebssystems und isolieren nur Prozesse, Dateisystem und Netzwerk. Eine virtuelle Maschine bringt dagegen ein komplettes eigenes Betriebssystem mit, ist dadurch stärker isoliert, aber auch schwerer und langsamer im Start.

Ist Amazon S3 serverless?

Im weiteren Sinne ja: Sie speichern Daten, ohne Server zu verwalten, und zahlen nach Nutzung. S3 ist allerdings ein Speicherdienst, kein Ort, an dem Code läuft. Häufig dient es als Auslöser für Serverless-Funktionen, etwa wenn ein Datei-Upload automatisch eine Verarbeitung startet.

Kann ich Serverless und Container kombinieren?

Unbedingt, und das ist in vielen Projekten die beste Lösung. Typisch ist ein containerisierter Kern für die Hauptanwendung, ergänzt um Funktionen für Webhooks, Dateiverarbeitung oder zeitgesteuerte Jobs. Wichtig ist eine klare Schnittstelle zwischen beiden Welten, damit Sie Teile später verschieben können.

Warum wenden sich manche Teams von Docker ab?

Meist geht es nicht um Container an sich, sondern um das Werkzeug Docker oder dessen Lizenzmodell für Desktop-Anwendungen. Da das Image-Format offen standardisiert ist, lassen sich alternative Werkzeuge nutzen, ohne die Container selbst zu ändern. Ihre Anwendung bleibt also portabel.

Brauche ich für Container zwingend Kubernetes?

Nein. Für eine einzelne Anwendung oder wenige Dienste reichen oft ein Server mit Docker Compose oder eine verwaltete Container-Plattform. Kubernetes lohnt sich erst bei vielen Diensten, hohen Verfügbarkeitsanforderungen und einem Team, das den Cluster dauerhaft betreut.

Quellen