On-Premises vs Cloud: Welches Kubernetes passt zu Ihrem Unternehmen?

TL;DR

Die Entscheidung zwischen On-Premises und Cloud Kubernetes hängt von drei Faktoren ab: Kosten (TCO über 3-5 Jahre), Team-Skills und Compliance-Anforderungen. On-Premises rechnet sich ab ca. 50 Nodes bei vorhandenem Ops-Team. Cloud (EKS, AKS, GKE) ist schneller produktiv und skaliert flexibel. Hybrid-Ansätze kombinieren beide Vorteile, erhöhen aber die Komplexität.

Die falsche Frage vermeiden

Die meisten Vergleiche starten mit "Was ist billiger?" -- das ist die falsche Frage. Die richtige lautet: Was können wir betreiben?

Ein Kubernetes-Cluster auf eigener Hardware aufzusetzen dauert 2-3 Tage. Ihn zuverlässig zu betreiben dauert ewig. Patches, etcd-Backups, Certificate Rotation, Node-Drains, Storage-Ausfälle -- das ist der Alltag, nicht die Installation.

Aufwand nach Betriebsmodell (pro Monat):

On-Premises Self-Hosted (kubeadm/k3s):
├── Cluster-Upgrades:           8-16 Stunden/Quartal
├── Node-Management:            4-8 Stunden
├── etcd Backup & Recovery:     2-4 Stunden
├── Certificate Rotation:       2 Stunden/Quartal
├── Hardware-Ausfälle:          4-8 Stunden (Ø)
├── Security Patches:           4-8 Stunden
└── Monitoring & Troubleshooting: 8-16 Stunden
    Gesamt:                     ~40-60 Stunden/Monat

Managed Kubernetes (EKS/AKS/GKE):
├── Cluster-Upgrades:           2-4 Stunden/Quartal
├── Node-Group-Management:      2-4 Stunden
├── Security Patches:           2-4 Stunden (Nodes)
└── Monitoring & Troubleshooting: 4-8 Stunden
    Gesamt:                     ~10-20 Stunden/Monat

Die Differenz sind 20-40 Stunden pro Monat. Bei einem internen Stundensatz von 100 EUR sind das 24.000-48.000 EUR pro Jahr -- nur für den Betrieb, ohne Hardware.

TCO-Vergleich: Die echten Zahlen

Ein realistischer TCO-Vergleich über 3 Jahre für einen mittelgroßen Workload (20 Nodes, 80 vCPUs, 320 GB RAM).

TCO 3-Jahres-Vergleich (20 Nodes, Production-Grade):

ON-PREMISES (eigenes RZ oder Colocation):
Hardware (Server, Storage, Netzwerk):      120.000 EUR
  └── 20x Server á 6.000 EUR
Colocation / Strom / Kühlung (36 Monate):  54.000 EUR
  └── 1.500 EUR/Monat
Netzwerk (Uplink, Firewall):               18.000 EUR
Software-Lizenzen (VMware/Ceph):           24.000 EUR
Personal (0.5 FTE Ops, 36 Monate):        180.000 EUR
  └── 10.000 EUR/Monat (anteilig)
Setup & Migration:                          30.000 EUR
───────────────────────────────────────────────────────
Gesamt On-Premises:                        426.000 EUR
Pro Monat:                                  11.833 EUR

MANAGED CLOUD (EKS/AKS mit Reserved Instances):
Control Plane (36 Monate):                  2.592 EUR
  └── 72 EUR/Monat (EKS)
Worker Nodes (m5.xlarge RI 3y):           136.800 EUR
  └── 3.800 EUR/Monat (20 Nodes)
Storage (EBS/Managed Disks):               25.920 EUR
  └── 720 EUR/Monat
Netzwerk (Egress, LB):                    43.200 EUR
  └── 1.200 EUR/Monat
Personal (0.2 FTE Ops, 36 Monate):        72.000 EUR
  └── 2.000 EUR/Monat (anteilig)
───────────────────────────────────────────────────────
Gesamt Cloud:                             280.512 EUR
Pro Monat:                                  7.792 EUR

DIFFERENZ: 145.488 EUR (Cloud günstiger)

Diese Rechnung kippt bei größeren Setups. Ab ca. 50 Nodes wird On-Premises oft günstiger, weil Hardware-Kosten linear skalieren, Cloud-Kosten aber überproportional steigen. Außerdem: Reserved Instances binden Sie für 3 Jahre -- das ist auch eine Form von Lock-in.

Team-Skills: Der unterschätzte Faktor

Die beste Infrastruktur nützt nichts, wenn das Team sie nicht betreiben kann.

Für ein Team mit 1-2 DevOps-Engineers ist Managed Kubernetes die sicherere Wahl. On-Premises Kubernetes erfordert mindestens 2-3 dedizierte Ops-Spezialisten -- und die sind auf dem deutschen Arbeitsmarkt schwer zu finden.

Compliance und Datenresidenz

Für deutsche Unternehmen ist Compliance oft der entscheidende Faktor. DSGVO, BSI-Grundschutz, KRITIS und branchenspezifische Regulierung beeinflussen die Standortwahl.

# Compliance-Entscheidungsbaum als Pseudo-Config
apiVersion: v1
kind: ConfigMap
metadata:
  name: compliance-decision
data:
  decision-tree: |
    frage_1: "Verarbeiten Sie personenbezogene Daten nach Art. 9 DSGVO?"
    ja: "On-Premises oder EU-Cloud mit Auftragsverarbeitung"
    nein:
      frage_2: "Unterliegen Sie KRITIS-Regulierung?"
      ja: "On-Premises oder BSI C5-zertifizierter Cloud-Provider"
      nein:
        frage_3: "Verlangt Ihr Kunde Datenresidenz in DE?"
        ja: "Cloud mit Region eu-central-1 oder On-Premises"
        nein:
          frage_4: "Haben Sie ein Ops-Team mit K8s-Erfahrung?"
          ja: "On-Premises oder Cloud -- beides möglich"
          nein: "Managed Cloud (EKS/AKS/GKE)"

Wichtig: "Cloud" bedeutet nicht automatisch "nicht DSGVO-konform". AWS Frankfurt (eu-central-1) und Azure West Europe hosten Daten in der EU. Aber: Der CLOUD Act erlaubt US-Behörden theoretisch Zugriff auf Daten bei US-Anbietern, auch wenn die Server in der EU stehen. Für regulierte Branchen (Finanz, Gesundheit, KRITIS) kann das ein Ausschlusskriterium sein.

Alternativen: Deutsche Cloud-Provider wie IONOS, Hetzner oder STACKIT bieten Kubernetes ohne US-Jurisdiktion. Die Feature-Parität mit AWS/Azure ist geringer, aber für viele Workloads ausreichend.

Hybrid-Ansätze: Das Beste aus beiden Welten?

Hybrid Kubernetes kombiniert On-Premises und Cloud. Das klingt nach dem besten Kompromiss, erhöht aber die Betriebskomplexität erheblich.

Wann Hybrid sinnvoll ist

Burst-Szenario: Basis-Last läuft On-Premises, Lastspitzen werden in die Cloud ausgelagert. Typisch für saisonale Geschäftsmodelle (E-Commerce, Steuerberatung).

Daten-Split: Sensible Daten bleiben On-Premises, unkritische Workloads laufen in der Cloud. Erfordert klare Datenklassifikation.

Migrations-Phase: Übergang von On-Premises zu Cloud (oder umgekehrt). Hybrid als temporärer Zustand, nicht als Dauerlösung.

Wann Hybrid schadet

Wenn Sie kein dediziertes Platform-Team haben. Hybrid bedeutet: zwei verschiedene Infrastrukturen betreiben, zwei verschiedene Netzwerke verstehen, zwei verschiedene Storage-Systeme pflegen. Mit einem 2-Personen-Team ist das nicht nachhaltig.

Entscheidungsmatrix

Empfehlung nach Unternehmensgröße

Startup / kleine Teams (< 10 Entwickler): Managed Cloud. Sie brauchen Ihre Entwickler für Features, nicht für etcd-Backups. EKS, AKS oder GKE -- je nach bestehender Cloud-Präferenz.

Mittelstand (10-100 Entwickler): Cloud mit Exit-Option. Nutzen Sie Managed Kubernetes, aber halten Sie Manifests portabel. Kustomize Overlays und Terraform-Module ermöglichen den Wechsel, wenn nötig. Details dazu im Vendor Lock-in Guide.

Regulierte Unternehmen (KRITIS, Finanz, Gesundheit): On-Premises oder deutsche Cloud-Provider. Die Compliance-Anforderungen wiegen schwerer als die Betriebskosten-Differenz. Alternativ: Sovereign Cloud Lösungen wie Kubernetes Private Cloud.

Großunternehmen (> 100 Entwickler, > 50 Nodes): On-Premises oder Hybrid. Ab dieser Größe rechnet sich eigene Hardware. Ein dediziertes Platform-Team (3-5 Personen) amortisiert sich über die geringeren Infrastrukturkosten.

FAQ

Ab welcher Cluster-Größe lohnt sich On-Premises?

Ab ca. 50 Nodes oder 200 vCPUs wird On-Premises kostenmäßig attraktiv. Voraussetzung: Sie haben bereits ein Rechenzentrum (oder Colocation) und ein Ops-Team mit Kubernetes-Erfahrung.

Kann ich später von Cloud zu On-Premises wechseln?

Ja, wenn Sie von Anfang an portabel arbeiten. Standard-Kubernetes-Manifests, Kustomize Overlays und IaC-Tools machen den Wechsel machbar. Die Daten-Migration ist typischerweise der aufwendigste Teil.

Wie hoch ist der Aufwand für ein Kubernetes-Upgrade On-Premises?

Pro Minor-Version (z.B. 1.29 auf 1.30) kalkulieren Sie 2-4 Tage für Test und Rollout. Bei Managed Kubernetes ist es ein API-Call mit 1-2 Stunden Monitoring. On-Premises kommen etcd-Upgrade, kubelet-Updates auf jedem Node und CNI-Kompatibilitätsprüfung hinzu.

Bieten deutsche Cloud-Provider echte Alternativen zu AWS/Azure?

IONOS Managed Kubernetes, Hetzner (k3s-basiert) und STACKIT bieten solide Kubernetes-Plattformen. Die Stärke: deutsche Jurisdiktion, DSGVO-Compliance ohne Diskussion. Die Schwäche: weniger Managed Services drumherum (kein RDS-Äquivalent, kleineres Marketplace-Ökosystem).

Was passiert bei einem Hardware-Ausfall On-Premises?

Bei korrektem Setup (3 Master-Nodes, Node-Redundanz) überlebt der Cluster einzelne Node-Ausfälle ohne Downtime. Kubernetes rescheduled Pods automatisch auf gesunde Nodes. Der ausgefallene Node muss manuell ersetzt werden -- das ist der Unterschied zur Cloud, wo Auto-Healing den Node automatisch neu provisioniert.

Fazit

Es gibt keine universell richtige Antwort. On-Premises gibt Ihnen Kontrolle und Kostenvorteile bei Skalierung. Cloud gibt Ihnen Geschwindigkeit und reduziert den Ops-Aufwand. Die Entscheidung hängt an drei Fragen:

1. Haben Sie ein Ops-Team? Nein: Cloud. Ja: Beide Optionen offen.
2. Brauchen Sie maximale Datensouveränität? Ja: On-Premises oder deutsche Cloud.
3. Wie groß ist Ihr Setup? Unter 50 Nodes: Cloud meist günstiger. Darüber: On-Premises prüfen.

Egal wie Sie sich entscheiden -- halten Sie Ihre Workloads portabel. Die Anforderungen ändern sich, und ein Wechsel sollte eine geplante Migration sein, kein Notfall-Projekt.