Die Entscheidung hängt vor allem vom Betriebsmodell ab
- Cloud Foundry ist eine stark integrierte Platform as a Service mit einfachem Deployment per CLI.
- Kubernetes bietet mehr Kontrolle, Erweiterbarkeit und eine deutlich größere Cloud-Native-Toolchain.
- Cloud Foundry passt gut zu standardisierten Webanwendungen und kleinen Plattformteams.
- Kubernetes lohnt sich besonders bei heterogenen Workloads, Microservices, GPUs oder speziellen Netzwerk- und Storage-Anforderungen.
- Bei den Lizenzkosten liegen beide Open-Source-Varianten zunächst bei 0 Euro. Der Unterschied entsteht vor allem durch Betrieb, Personal und Zusatzdienste.
Zwei Plattformen mit unterschiedlichen Abstraktionsebenen
Cloud Foundry ist in erster Linie eine Platform as a Service. Entwickler liefern Quellcode oder ein Container-Image und erhalten eine vorgefertigte Laufzeitumgebung. Befehle wie cf push übernehmen viele Schritte, die bei Kubernetes explizit konfiguriert werden müssen.
Kubernetes ist dagegen eine Container-Orchestrierungsplattform. Sie verwaltet Container in sogenannten Pods, verteilt sie auf Nodes und hält den gewünschten Zustand aufrecht. Deployment, Service, Ingress, Secrets und Storage werden meist deklarativ beschrieben, zum Beispiel mit YAML-Dateien.
Der Unterschied wirkt zunächst wie eine Frage des Komforts, geht aber tiefer. Cloud Foundry definiert einen relativ klaren Weg zur Anwendung. Kubernetes stellt eher die Bausteine bereit, aus denen ein Unternehmen seine eigene Plattform zusammensetzt.
| Kriterium | Cloud Foundry | Kubernetes |
|---|---|---|
| Grundidee | Integrierte Anwendungsplattform | Erweiterbare Container-Orchestrierung |
| Deployment | Quellcode oder Image mit cf push
|
Manifeste, Helm, GitOps oder Operatoren |
| Primäre Zielgruppe | Entwicklungsteams und standardisierte Plattformteams | DevOps-, SRE- und Plattformteams |
| Flexibilität | Bewusst eingeschränkt | Sehr hoch |
| Betriebsaufwand | Für Entwickler niedrig, für Betreiber dennoch anspruchsvoll | Von moderat bei Managed Services bis sehr hoch im Eigenbetrieb |
Cloud Foundry arbeitet intern ebenfalls mit Containern. Die Garden-Laufzeit verwendet heute Garden-runC und setzt dabei auf OCI-kompatible Containertechnik. Der Vergleich lautet deshalb nicht „Container gegen keine Container“, sondern vorgefertigte Plattform gegen frei komponierbare Plattform.
Wo Cloud Foundry im Entwicklungsalltag punktet
Die größte Stärke von Cloud Foundry liegt in der kurzen Strecke zwischen fertigem Code und laufender Anwendung. Ein Team kann eine Java-, Node.js-, Python- oder Go-Anwendung bereitstellen, ohne sich zunächst mit Pods, Controllern und Ingress-Konfigurationen beschäftigen zu müssen.
Buildpacks erkennen häufig die verwendete Programmiersprache und erstellen daraus ein deploybares Artefakt. Das beschleunigt den Einstieg und sorgt für einheitliche Sicherheits- und Laufzeitstandards. Gerade in Unternehmen mit vielen ähnlichen Anwendungen ist dieser Standardisierungseffekt wertvoll.
Ein klarer Weg von der Entwicklung bis zum Betrieb
Cloud Foundry bringt Routing, Logs, Health Checks, Skalierung, Benutzerverwaltung und Organisationsstrukturen bereits als zusammenhängende Plattform mit. Mit Organisations- und Space-Konzepten lassen sich Teams, Umgebungen und Berechtigungen relativ übersichtlich trennen.
Ich sehe darin einen praktischen Vorteil für Teams, die ihre Zeit in Fachlogik investieren wollen. Eine typische Webanwendung mit stateless Backend, Datenbank und externem Message Broker lässt sich oft schneller produktiv setzen als auf einem Kubernetes-Cluster, der erst durch mehrere Zusatzkomponenten zu einer vollständigen Entwicklerplattform wird.
Die Grenzen des Komforts
Der einfache Workflow funktioniert am besten, solange sich die Anwendung innerhalb des vorgesehenen Modells bewegt. Spezielle Netzwerkpfade, ungewöhnliche Sidecars, eigene Scheduling-Regeln oder stark angepasste Storage-Anforderungen passen weniger gut hinein.
Auch Betreiber sollten Cloud Foundry nicht mit einer kleinen Einzelserver-Installation verwechseln. Komponenten wie Cloud Controller, Diego, BOSH, Routing, Storage und Logging müssen zuverlässig betrieben werden. Der Aufwand wird für Entwickler verborgen, verschwindet aber nicht. Cloud Foundry reduziert Plattformkomplexität für Nutzer, nicht automatisch für das Betriebsteam.
Wann Kubernetes die bessere technische Basis ist
Kubernetes spielt seine Stärke aus, wenn eine Organisation mehr als klassische Webanwendungen betreiben muss. Unterschiedliche Container-Images, spezialisierte Netzwerke, eigene Operatoren, Batch-Jobs, Stateful Services und Machine-Learning-Workloads lassen sich in einem gemeinsamen Modell verwalten.
Die Plattform bietet dafür eine deklarative API. Das Team beschreibt den gewünschten Zustand, während Kubernetes laufend versucht, diesen Zustand herzustellen. Fällt ein Pod aus, startet ein Controller eine neue Instanz. Steigt die Last, können Deployments, Horizontal Pod Autoscaler oder andere Automatisierungen reagieren.
Flexibilität für heterogene Workloads
- Microservices lassen sich unabhängig skalieren und versionieren.
- StatefulSets und CSI-Treiber unterstützen Anwendungen mit persistentem Speicher.
- Jobs und CronJobs eignen sich für einmalige und regelmäßig wiederkehrende Aufgaben.
- DaemonSets können Agenten für Logging, Monitoring oder Security auf Nodes verteilen.
- GPU-Unterstützung und spezialisierte Scheduling-Regeln sind für KI- und Analyse-Workloads verfügbar.
Diese Möglichkeiten sind kein kostenloser Bonus. Jede zusätzliche Freiheit erzeugt Entscheidungen bei Security, Observability, Netzwerk, Upgrades und Verantwortlichkeiten. Ein Kubernetes-Cluster ohne klare Plattformstandards wird schnell zu einer Sammlung individueller Lösungen.
Managed Kubernetes verändert die Rechnung
Bei einem Managed Service übernimmt der Cloud-Anbieter typischerweise Teile der Control-Plane. Das senkt den Installations- und Wartungsaufwand, nimmt dem Team aber nicht jede Aufgabe ab. Nodes, Namespaces, Policies, Ingress, Secrets, Backups, Kostenkontrolle und Workload-Sicherheit bleiben in der Verantwortung des Kunden.
Für viele deutsche Unternehmen ist das trotzdem der pragmatischste Einstieg. Ein Managed Cluster in einer Region mit passenden Datenschutz- und Compliance-Anforderungen kann die technische Freiheit von Kubernetes mit einem überschaubareren Betriebsmodell verbinden. Managed bedeutet nicht wartungsfrei, aber meist deutlich planbarer als ein vollständig selbst betriebener Cluster.
Der direkte Vergleich bei Betrieb, Kosten und Sicherheit
Die Software selbst kostet in den Open-Source-Varianten von Cloud Foundry und Kubernetes zunächst keine Lizenzgebühr. Für die reale Kalkulation sind jedoch Compute, Storage, Netzwerk, Backups, Monitoring, Support und vor allem die benötigte Plattformkompetenz entscheidend.
| Bereich | Cloud Foundry | Kubernetes |
|---|---|---|
| Infrastrukturkosten | VMs für Plattform und Anwendungen, dazu Storage und Netzwerk | Nodes, Control Plane bei Eigenbetrieb, Storage, Netzwerk und Zusatzdienste |
| Personalkosten | Weniger Entscheidungen für App-Teams, aber Spezialwissen für Plattformbetrieb | Hoher Bedarf an Kubernetes-, Security- und SRE-Kompetenz |
| Upgrades | Stark integrierte Plattform, dadurch koordinierte Aktualisierung mehrerer Komponenten | Cluster, Add-ons, Ingress, CNI, CSI und Workloads müssen kompatibel bleiben |
| Security | Viele Vorgaben sind zentral standardisierbar | Sehr leistungsfähig, aber Fehlkonfigurationen sind leichter möglich |
| Monitoring | Integrierte Plattformsignale und zentrale Logflüsse | Große Auswahl, aber meist eigene Zusammenstellung und Pflege |
Bei Cloud Foundry sollte ein Unternehmen die Kosten für eine dauerhaft verfügbare Plattformbasis einplanen, selbst wenn nur wenige Anwendungen laufen. Kubernetes kann bei kleinen Umgebungen günstiger wirken, wenn ein Managed Service genutzt wird. Durch viele Zusatzdienste, hohe Logmengen oder ineffiziente Ressourcenlimits kann der Cluster jedoch ebenso schnell teuer werden.
Security ist bei beiden Plattformen eine Designaufgabe. Cloud Foundry hilft durch zentrale Standards und klarere Leitplanken. Kubernetes bietet feinere Kontrolle mit RBAC, Network Policies, Admission Controls und Security Contexts, verlangt aber auch, dass diese Mechanismen konsequent eingerichtet und geprüft werden.Typische Einsatzszenarien für die Entscheidung
Cloud Foundry passt zu standardisierten Geschäftsanwendungen
Ein Unternehmen betreibt beispielsweise 80 interne Java- und Node.js-Services. Die Teams brauchen automatisierte Deployments, Logs, Skalierung und getrennte Test- und Produktionsumgebungen. Die Anwendungen sind überwiegend stateless und nutzen Datenbanken als externe Managed Services.Hier ist Cloud Foundry oft die effizientere Wahl. Die Plattform kann einen goldenen Pfad anbieten, also einen geprüften Standardweg, der neue Anwendungen schnell und mit weniger individuellen Architekturentscheidungen in Betrieb bringt.
Kubernetes passt zu einer breiten Plattformstrategie
Ein anderes Unternehmen kombiniert Webanwendungen, Event Streaming, Batch-Verarbeitung, eigene Container-Images und GPU-gestützte KI-Pipelines. Zusätzlich sollen Workloads zwischen mehreren Cloud-Anbietern und dem eigenen Rechenzentrum verschoben werden.
In diesem Fall spricht viel für Kubernetes. Die einheitliche API, das große Ökosystem und die Möglichkeit, eigene Plattformdienste zu entwickeln, sind wichtiger als ein besonders einfacher Einstieg. Der Preis dafür ist ein Team, das Clusterbetrieb und Plattformengineering ernst nimmt.
Lesen Sie auch: GitLab erklärt - Funktionen, Kosten und die passende Variante
Migrationen verlangen einen nüchternen Blick
Eine Migration von Cloud Foundry zu Kubernetes ist selten ein reines Verpacken der Anwendung als Container. Buildpacks, Umgebungsvariablen, Service Bindings, Routing, Logformat, Health Checks und Deployment-Prozesse müssen in ein anderes Betriebsmodell übertragen werden.
Umgekehrt ist auch der Wechsel zu Cloud Foundry nicht für jede Kubernetes-Anwendung realistisch. Wer stark von CRDs, Operatoren, DaemonSets oder individuellen Netzwerkfunktionen abhängt, müsste möglicherweise einen Teil dieser Architektur vereinfachen. Die Anwendung und ihre Betriebsanforderungen sollten den Wechsel bestimmen, nicht ein allgemeiner Plattformtrend.
So treffe ich die Auswahl für ein reales Projekt
Ich beginne nicht mit der Frage, welche Plattform moderner wirkt. Zuerst kläre ich, wer künftig für Cluster, Laufzeit, Security, Backups und Incident Response verantwortlich ist. Eine Plattform ist nur dann passend, wenn das Team sie auch an Wochenenden und unter Zeitdruck beherrschen kann.
- Workloads erfassen und zwischen stateless Services, Datenverarbeitung, Jobs und Stateful Applications unterscheiden.
- Betriebsmodell festlegen und entscheiden, welche Aufgaben ein Cloud-Anbieter, ein Plattformteam und die Entwicklung übernehmen.
- Standardisierung bewerten und prüfen, ob ein gemeinsamer Deployment-Weg wichtiger ist als maximale Individualisierung.
- Eine Pilotanwendung auswählen, die typische Anforderungen an Netzwerk, Datenbank, Secrets, Monitoring und Skalierung abbildet.
- Total Cost of Ownership messen und nicht nur Infrastrukturpreise vergleichen. Dazu gehören auch Onboarding, Bereitschaftsdienst, Upgrades und Fehlerbehebung.
Für eine faire Bewertung sollte der Pilot mindestens vier bis sechs Wochen laufen und einen normalen Release-Zyklus einschließlich Rollback abbilden. Erst dann zeigt sich, ob die Plattform im Alltag wirklich schneller ist oder nur in einer Demo gut aussieht.
Mein praktischer Entscheidungsrahmen ist klar. Bei wenigen, ähnlichen Geschäftsanwendungen und einem kleinen Plattformteam tendiere ich zu Cloud Foundry. Bei stark unterschiedlichen Workloads, einer langfristigen Multi-Cloud-Strategie oder hohem Bedarf an Erweiterbarkeit wähle ich Kubernetes, möglichst als Managed Service mit einem bewusst begrenzten internen Plattformstandard.
Die beste Plattform ist die, die dauerhaft beherrschbar bleibt
Cloud Foundry und Kubernetes sind keine einfachen Gewinner-und-Verlierer-Alternativen. Cloud Foundry optimiert den Weg von Quellcode zu betriebener Anwendung. Kubernetes optimiert die technische Kontrolle und die Möglichkeit, eine eigene Cloud-Native-Plattform aufzubauen.
Wer vor allem Entwicklerproduktivität und klare Standards braucht, findet in Cloud Foundry oft den kürzeren Weg. Wer verschiedene Workloads, Teams und Infrastrukturmodelle unter einer programmierbaren Plattform vereinen möchte, erhält mit Kubernetes mehr Spielraum.
Entscheidend bleibt am Ende nicht die Popularität der Technologie, sondern die Passung zu Anwendungen, Teamgröße, Compliance-Anforderungen und Bereitschaftsdienst. Eine kleinere Plattform, die zuverlässig betrieben wird, ist im Alltag meist wertvoller als ein mächtiger Cluster, dessen Komplexität niemand vollständig verantwortet.
