Serverless oder Kubernetes wählen: Was passt besser?

Ein neues Kundenportal soll schneller live gehen, die API muss Lastspitzen zuverlässig abfedern und das Betriebsteam darf nicht mit zusätzlicher Infrastrukturpflege überlastet werden. Wer vor solchen Anforderungen steht, muss früh entscheiden: Serverless oder Kubernetes wählen? Die richtige Antwort hängt nicht von einem Architekturtrend ab, sondern von Workload, Produktstrategie, Betriebsmodell und Kostenprofil.

Beide Ansätze können moderne Anwendungen skalierbar und sicher in die Cloud bringen. Sie verschieben jedoch Verantwortung an unterschiedliche Stellen. Serverless reduziert den Infrastrukturanteil deutlich. Kubernetes schafft mehr Kontrolle und eignet sich für Plattformen, deren Betrieb, Vernetzung und Skalierung gezielt steuerbar sein müssen. Eine falsche Wahl wird selten am ersten Deployment sichtbar, aber oft bei wachsenden Kosten, längeren Incident-Zeiten oder stockender Produktentwicklung.

Wann sollten Sie Serverless oder Kubernetes wählen?

Die Kernfrage lautet nicht, welche Technologie leistungsfähiger ist. Serverless und Kubernetes lösen unterschiedliche betriebliche Probleme. Serverless ist ein Ausführungsmodell: Cloud-Funktionen oder gemanagte Services werden bei Bedarf aktiviert, die Plattform übernimmt weite Teile von Skalierung und Infrastruktur. Kubernetes ist eine Orchestrierungsplattform: Teams betreiben containerisierte Anwendungen mit klaren Regeln für Deployment, Netzwerk, Ressourcen und Verfügbarkeit.

Für Entscheider im Mittelstand ist deshalb die Verantwortungskette entscheidend. Bei Serverless delegieren Sie mehr operative Aufgaben an den Cloud-Anbieter. Bei Kubernetes behalten Sie mehr technische Gestaltungsmöglichkeiten, müssen diese aber auch professionell automatisieren, überwachen und absichern. Das ist kein Nachteil, wenn die Anwendung diese Kontrolle benötigt. Es ist unnötiger Aufwand, wenn eine schlanke, ereignisgesteuerte Lösung den Geschäftszweck besser erfüllt.

Serverless: stark bei Ereignissen, Schwankungen und kurzer Time-to-Market

Serverless passt besonders gut, wenn Anwendungen auf klar abgegrenzte Ereignisse reagieren: eine Bestellung wird verarbeitet, ein Dokument hochgeladen, eine Nachricht in eine Warteschlange gestellt oder ein externer Webhook empfangen. Funktionen starten bedarfsabhängig und skalieren automatisch. Das verkürzt den Weg vom Fachkonzept bis zur produktiven Funktion erheblich.

Für neue digitale Produkte kann das ein konkreter Vorteil sein. Ein Team konzentriert sich auf Fachlogik, APIs und Sicherheitsregeln, statt zunächst Cluster, Worker-Nodes und Skalierungsregeln aufzubauen. Gerade bei unvorhersehbarem Traffic vermeiden Unternehmen Kosten für dauerhaft vorgehaltene Kapazität. Auch Integrationen zwischen SaaS-Systemen, Datenpipelines und Hintergrundprozessen lassen sich effizient umsetzen.

Die Kehrseite liegt in den Grenzen des Laufzeitmodells. Kurzlebige Funktionen sind nicht ideal für dauerhaft laufende Prozesse, komplexe Verbindungen oder Anwendungen mit hohem Speicherbedarf. Kaltstarts können bei bestimmten Laufzeiten und Zugriffsmustern die Antwortzeit beeinflussen. Zusätzlich entstehen technische Abhängigkeiten von Cloud-spezifischen Diensten, Ereignisformaten und Berechtigungsmodellen. Das ist vertretbar, wenn die Vorteile bewusst genutzt werden. Es wird problematisch, wenn Portabilität, lokale Ausführung oder ein späterer Providerwechsel von Beginn an zentrale Anforderungen sind.

Auch das Debugging verlangt Disziplin. Ein einzelner Request kann mehrere Funktionen, Queues, Datenbanken und externe Schnittstellen durchlaufen. Ohne verteiltes Tracing, strukturierte Logs und nachvollziehbare Korrelationen ist die Fehleranalyse langsam. Serverless spart keine Betriebsarbeit automatisch ein - es verlagert sie von Serverpflege zu Architektur, Observability und Kostensteuerung.

Kubernetes: die Plattform für komplexe Produktlandschaften

Kubernetes ist sinnvoll, wenn Anwendungen dauerhaft laufen, aus mehreren Services bestehen oder über standardisierte Deployment-Prozesse in unterschiedlichen Umgebungen bereitgestellt werden sollen. Typische Beispiele sind SaaS-Plattformen, E-Commerce-Systeme, interne Kernanwendungen, APIs mit konstantem Traffic sowie datenintensive Backend-Services. Container schaffen dabei eine einheitliche Verpackung für Entwicklung, Test und Produktion.

Die Stärke von Kubernetes liegt in der Kontrolle. Teams können Ressourcen begrenzen, Deployments kontrolliert ausrollen, Anwendungen über mehrere Verfügbarkeitszonen verteilen und Netzwerkzugriffe präzise absichern. Horizontal Pod Autoscaling, Ingress-Regeln, Secrets, Service-Mesh-Komponenten oder Jobs lassen sich gezielt kombinieren. Für eine wachsende Produktplattform entsteht so eine belastbare technische Grundlage, statt für jeden Service ein separates Betriebsmodell zu etablieren.

Diese Flexibilität hat ihren Preis. Ein Cluster wird nicht dadurch produktionsreif, dass Anwendungen darin laufen. Benötigt werden Infrastructure as Code, ein sauberer CI/CD-Prozess, Rechte- und Secret-Management, Monitoring, Backup- und Recovery-Konzepte, Sicherheitsupdates sowie klare Verantwortlichkeiten für Incidents. Ein unmanaged Cluster ohne Betriebsmodell kann schneller zum Risiko werden als eine klassische virtuelle Maschine.

Für Unternehmen mit mehreren Entwicklungsteams kann sich der Aufwand dennoch klar rechnen. Eine zentral gepflegte Plattform standardisiert den Weg in die Produktion, reduziert manuelle Übergaben und beschleunigt Releases. Entscheidend ist, Kubernetes nicht als Selbstzweck einzuführen. Wer nur eine kleine Web-Anwendung mit überschaubarer Last betreibt, schafft mit einem Cluster oft mehr Komplexität als Nutzen.

Kosten: Nicht nur den Preis pro Anfrage vergleichen

Serverless wirkt beim Einstieg häufig günstiger, weil keine dauerhaft laufenden Server bezahlt werden. Das trifft vor allem auf unregelmäßige Last, selten ausgeführte Prozesse und klar begrenzte Funktionen zu. Bei hohem, konstantem Traffic kann sich das Verhältnis jedoch drehen. Viele Funktionsaufrufe, lange Ausführungszeiten, Datentransfers und ergänzende Managed Services summieren sich schnell.

Kubernetes verursacht eher planbare Grundkosten: Compute-Kapazität, Managed-Control-Plane, Speicher, Netzwerk und Betriebsaufwand. Wenn Workloads dauerhaft ausgelastet sind, kann dieses Modell wirtschaftlicher sein. Die Rechnung darf aber nicht bei Infrastrukturkosten enden. Ein Cluster ohne Automatisierung bindet qualifizierte Fachkräfte und erhöht das Ausfallrisiko. Umgekehrt kann eine Serverless-Landschaft mit vielen Einzelfunktionen hohe Kosten und schwer nachvollziehbare Abhängigkeiten erzeugen.

FinOps beginnt deshalb mit Transparenz. Kosten sollten nach Produkt, Team, Mandant oder Funktion zugeordnet werden. Budgets, Alarme und regelmäßige Analysen zeigen, ob Skalierungsregeln, Speicherklassen oder Laufzeiten tatsächlich zum Nutzungsverhalten passen. Architekturentscheidungen bleiben nur dann wirtschaftlich, wenn die Kosten im laufenden Betrieb sichtbar sind.

Die Entscheidung an Geschäftsanforderungen festmachen

Statt mit einer Technologiepräferenz zu starten, sollten Teams die Arbeitslast konkret beschreiben. Wie konstant ist der Traffic? Welche Antwortzeiten sind vertraglich oder fachlich erforderlich? Gibt es lange laufende Jobs, komplexe Netzwerkregeln oder Anforderungen an hybride Umgebungen? Wie viele Teams deployen unabhängig voneinander, und wer trägt die operative Verantwortung außerhalb der Bürozeiten?

Serverless ist meist die bessere Wahl, wenn einzelne Funktionen klar abgegrenzt sind, ereignisgesteuert arbeiten und Last stark schwankt. Es eignet sich auch, um neue Produktideen schnell zu validieren oder bestehende Systeme über APIs, Queues und Automatisierungen zu erweitern. Die Architektur sollte dabei modulare Grenzen, Versionsmanagement und Observability von Anfang an vorsehen.

Kubernetes ist die bessere Wahl, wenn eine langfristige Produktplattform entsteht, Services dauerhaft verfügbar sein müssen und mehrere Anwendungen nach einheitlichen Regeln betrieben werden sollen. Das gilt ebenso, wenn regulatorische Vorgaben, spezifische Netzwerkarchitekturen oder Anforderungen an Portabilität den Gestaltungsspielraum erhöhen. Voraussetzung ist ein Team oder Partner, der den Plattformbetrieb nicht als Nebenaufgabe behandelt.

Häufig ist die richtige Antwort: beides

Die Gegenüberstellung ist in der Praxis oft zu grob. Ein Kubernetes-Cluster kann die Kernanwendung, Hintergrund-Worker und interne Services tragen, während Serverless Funktionen Dokumentenverarbeitung, Bildtransformation, nächtliche Datenimporte oder externe Event-Integrationen übernehmen. So bleibt die zentrale Plattform kontrollierbar, ohne jede seltene oder stark schwankende Aufgabe dauerhaft vorzuhalten.

Ein solches Zusammenspiel funktioniert nur mit klaren Schnittstellen. Ereignisse brauchen stabile Verträge, Berechtigungen müssen übergreifend steuerbar sein, und das Monitoring muss einen Geschäftsprozess über beide Welten hinweg abbilden. Besonders wichtig sind einheitliche Deployment-Standards und belastbare Runbooks. Sonst entsteht kein flexibles Gesamtsystem, sondern ein neuer Betriebs-Flickenteppich.

Architektur ist eine Betriebsentscheidung

Die Wahl zwischen Serverless und Kubernetes prägt nicht nur den Code. Sie bestimmt Release-Prozesse, Sicherheitskontrollen, Incident-Management, Kostensteuerung und die Geschwindigkeit, mit der ein Unternehmen neue Anforderungen umsetzt. Deshalb sollte die Entscheidung gemeinsam von Produktverantwortung, Entwicklung und Betrieb getroffen werden - nicht isoliert im ersten Architekturworkshop.

devRocks bewertet solche Entscheidungen entlang des realen Betriebs: Lastprofile, Verfügbarkeitsziele, Sicherheitsanforderungen, vorhandene Teams und wirtschaftliche Leitplanken. Daraus entsteht keine Standardempfehlung, sondern eine Architektur, die auch nach dem Go-live wartbar und kalkulierbar bleibt.

Die beste Plattform ist am Ende die, die Ihre Teams nicht von der Produktarbeit abhält und gleichzeitig sicherstellt, dass Wachstum, Störungen und Kosten nicht erst dann sichtbar werden, wenn sie bereits geschäftskritisch sind.