Zwei Antworten auf dieselbe Frage
Wie bringe ich meinen Code zuverlässig und skalierbar in Produktion? Kubernetes antwortet: mit einem Orchestrierungssystem, das dir volle Kontrolle über Container, Netzwerk und Skalierung gibt – gegen den Preis erheblicher Betriebskomplexität. Serverless antwortet: indem du die Infrastruktur komplett dem Anbieter überlässt und nur noch Funktionen oder Container-Images ablieferst – gegen den Preis von Kontrollverlust und Anbieterbindung. Es ist ein Tausch: Kontrolle gegen Komfort. Welcher Tausch sich lohnt, hängt weniger von der Technologie ab als vom Profil deiner Workloads und den Fähigkeiten deines Teams.
Kubernetes: Das Betriebssystem der Cloud
Kubernetes orchestriert Container über viele Maschinen hinweg: Es verteilt Workloads, startet abgestürzte Prozesse neu, skaliert bei Last und verwaltet Netzwerk, Speicher und Konfiguration deklarativ. Du beschreibst den Soll-Zustand, Kubernetes stellt ihn her.
Die Stärken:
- Volle Kontrolle: Runtime, Ressourcen-Limits, Netzwerk-Policies, Scheduling – alles konfigurierbar
- Portabilität: Derselbe Cluster-Aufbau läuft bei jedem Cloud-Anbieter und im eigenen Rechenzentrum
- Dauerhafte Workloads: Prozesse laufen permanent – keine Cold Starts, konstante Latenz
- Riesiges Ökosystem: Von Monitoring über Service Mesh bis GPU-Scheduling ist alles vorhanden
Die Schwächen: Kubernetes ist ein eigenes Fachgebiet. Cluster-Upgrades, Security-Patches, Ressourcen-Tuning, Netzwerk-Debugging – das erfordert dediziertes Know-how und bindet Personal. Managed-Angebote der Cloud-Anbieter nehmen einen Teil davon ab, aber die konzeptionelle Komplexität (Pods, Deployments, Services, Ingress, RBAC …) bleibt. Für ein kleines Team mit einer einfachen Anwendung ist das oft ein zu schweres Werkzeug. Dazu kommen laufende Kosten: Ein Cluster verursacht auch dann Ausgaben, wenn gerade nichts zu tun ist.
Serverless: Code statt Infrastruktur
Serverless (Functions-as-a-Service und verwandte Modelle) abstrahiert die Infrastruktur vollständig weg. Du deployest eine Funktion oder ein Container-Image; der Anbieter führt es aus, wenn ein Ereignis eintrifft – ein HTTP-Request, eine neue Datei, eine Queue-Nachricht. Skalierung passiert automatisch, von null bis zu tausenden parallelen Instanzen.
Die Stärken:
- Kein Betrieb: Keine Server, keine Patches, kein Kapazitätsplanung
- Scale-to-Zero: Keine Last, keine Kosten – ideal für sporadische Workloads
- Pay-per-Use: Abgerechnet wird die tatsächliche Ausführungszeit
- Schnelle Time-to-Market: Vom Code zur laufenden Funktion in Minuten
Die Schwächen: Cold Starts – nach Inaktivität muss die Umgebung erst hochfahren, was Latenz kostet. Dazu kommen Limits: maximale Ausführungsdauer, begrenzter Arbeitsspeicher, Payload-Größen, meist keine oder eingeschränkte GPU-Unterstützung. Lang laufende Prozesse, WebSocket-Verbindungen oder speicherintensive Jobs passen schlecht ins Modell. Und der Code ist oft eng mit den Diensten eines Anbieters verwoben – Vendor-Lock-in ist real, auch wenn Container-basierte Serverless-Angebote das mildern.
Die KI-Perspektive: Wo läuft LLM-Inferenz?
Für KI-Workloads fällt die Antwort ungewöhnlich deutlich aus. LLM-Inferenz und Modell-Serving sprechen fast alles gegen klassisches Serverless: Große Modelle brauchen GPUs, belegen viele Gigabyte Speicher und benötigen lange, um in den GPU-Speicher geladen zu werden. Ein Cold Start, der das Modell jedes Mal neu lädt, macht die Latenz unbrauchbar; Laufzeit- und Speicherlimits kollidieren mit langen Generierungen und Streaming. Kubernetes mit GPU-Nodes ist deshalb das etablierte Muster für selbst gehostete Modelle – dauerhaft laufende Inferenz-Server, GPU-Scheduling und feinjustiertes Autoscaling inklusive.
Serverless hat im KI-Stack trotzdem seinen Platz: als Orchestrierungsschicht. Funktionen, die externe LLM-APIs aufrufen, Embeddings-Pipelines anstoßen, Webhooks verarbeiten oder RAG-Dokumente vorverarbeiten, sind kurzlebig und ereignisgesteuert – genau das Serverless-Profil. Wer die GPU-Last an einen API-Anbieter auslagert, kann seine gesamte KI-Anwendung problemlos serverless bauen.
Wann was?
Nimm Kubernetes, wenn:
- Workloads dauerhaft laufen und konstante Latenz brauchen
- Du GPU-Inferenz oder Modell-Serving selbst betreibst
- Portabilität (Multi-Cloud, On-Premises) strategisch wichtig ist
- Du komplexe Systeme mit vielen Services orchestrierst und das Team-Know-how vorhanden ist
Nimm Serverless, wenn:
- Workloads ereignisgesteuert und kurzlebig sind
- Die Last stark schwankt oder oft bei null liegt
- Du kein Ops-Team hast und schnell liefern willst
- Cold Starts und Anbieter-Limits für deinen Use Case unkritisch sind
Ein pragmatischer Startpunkt für neue Projekte: Beginne serverless, solange die Limits nicht stören – und wechsle erst dann zu Kubernetes, wenn Workload-Profil, Kosten bei Dauerlast oder Kontrollbedarf es tatsächlich erfordern.
Kombination statt Glaubenskrieg
In reifen Architekturen koexistieren beide: Kubernetes trägt die Kernservices und die Inferenz, Serverless erledigt Event-Handler, Cron-Jobs und Integrations-Glue. Und die Grenze verschwimmt – Frameworks wie Knative bringen Scale-to-Zero und ereignisgesteuerte Ausführung in den eigenen Cluster, während Container-basierte Serverless-Plattformen immer mehr Kontrolle zulassen. Die richtige Frage ist nicht Kubernetes oder Serverless?, sondern: Welcher Workload hat welches Profil?