Build or Buy Kubernetes? Teil 3

Managed Kubernetes ist nicht gleich Managed Platform: Wie Unternehmen langfristig souverän bleiben

Teil 3 unserer Serie „Build or Buy Kubernetes"

In den ersten beiden Teilen dieser Serie haben wir betrachtet, warum die Einführung von Kubernetes weit mehr als eine Infrastrukturentscheidung ist und weshalb die tatsächlichen Kosten einer Plattform selten auf der Cloud-Rechnung erscheinen. Damit bleibt eine entscheidende Frage offen: Welches Betriebsmodell ist langfristig das richtige?

Die Diskussion wird häufig auf drei Optionen reduziert: Kubernetes selbst betreiben, ein Managed-Kubernetes-Angebot eines Hyperscalers nutzen oder einen spezialisierten Dienstleister beauftragen. Diese Einteilung wirkt zunächst plausibel, verschleiert jedoch einen wesentlichen Unterschied.

Nicht jede gemanagte Kubernetes-Plattform übernimmt auch den Betrieb der Plattform.

Zwischen einer gemanagten Control Plane und einer vollständig betriebenen Plattform liegen organisatorisch und wirtschaftlich erhebliche Unterschiede.

Kubernetes ist nur ein Baustein einer Betriebsplattform

Die Bezeichnung Managed Kubernetes suggeriert, dass sich ein Unternehmen nach der Bereitstellung eines Clusters nicht länger um den Betrieb kümmern müsse. Tatsächlich bezieht sich der Begriff bei den meisten Angeboten jedoch auf einen sehr eng definierten Verantwortungsbereich.

In der Regel übernimmt der Anbieter den Betrieb der Control Plane, sorgt für deren Hochverfügbarkeit und stellt neue Kubernetes-Versionen bereit. Aus Sicht des Cloud-Anbieters endet an dieser Stelle jedoch häufig bereits die Verantwortung.

Die eigentliche Plattform beginnt erst dahinter.

Wer verantwortet die Netzwerkarchitektur? Welche Sicherheitsrichtlinien gelten für Deployments? Wie werden Container–Images signiert und auf Schwachstellen überprüft? Wer entwickelt Backup- und Restore-Strategien? Wie werden Monitoring, Alerting und Incident Response organisiert? Welche Prozesse stellen sicher, dass regulatorische Anforderungen dauerhaft eingehalten werden? Und wer begleitet Entwicklungsteams dabei, diese Plattform effizient zu nutzen?

Diese Fragen lassen sich nicht durch einen API-Endpunkt beantworten.

Sie sind Ausdruck operativer Verantwortung.

Aus diesem Grund ist es sinnvoll, zwischen Managed Kubernetes und Managed Platform zu unterscheiden. Während sich ersteres primär auf den technischen Betrieb eines Clusters konzentriert, umfasst letzteres sämtliche organisatorischen und betrieblichen Prozesse, die erforderlich sind, um Software zuverlässig, sicher und wirtschaftlich bereitzustellen.

Das Shared-Responsibility-Modell endet nicht bei Kubernetes

Cloud-Anbieter sprechen seit vielen Jahren vom sogenannten Shared Responsibility Model. Der Begriff beschreibt die Aufteilung von Verantwortlichkeiten zwischen Infrastrukturbetreiber und Kunde.

Dieses Modell gilt uneingeschränkt auch für Kubernetes.

Ein Managed-Service reduziert zwar den Aufwand für bestimmte Infrastrukturkomponenten, entbindet Unternehmen jedoch nicht von ihrer Verantwortung für Architekturentscheidungen, Sicherheitsrichtlinien, Deployment-Prozesse oder Compliance.

Gerade in regulierten Branchen wird dieser Unterschied häufig unterschätzt.

Ein Anbieter kann eine hochverfügbare Kubernetes-Control-Plane bereitstellen und dennoch keinerlei Aussage darüber treffen, ob die darauf betriebenen Anwendungen den Anforderungen von NIS2, DORA oder dem Cyber Resilience Act entsprechen. Ebenso wenig kann er beurteilen, ob Backup-Konzepte regelmäßig getestet werden, Identity-Konzepte den internen Sicherheitsrichtlinien genügen oder Wiederanlaufprozesse unter realistischen Bedingungen funktionieren.

Compliance entsteht nicht durch Infrastruktur.

Compliance entsteht durch Prozesse.

Und Prozesse bleiben unabhängig vom gewählten Betriebsmodell immer in der Verantwortung des Unternehmens.

Plattformbetrieb ist eine Dienstleistung, keine Software

Viele Unternehmen betrachten Plattformen noch immer als technisches Produkt. Tatsächlich handelt es sich jedoch um eine kontinuierliche Dienstleistung.

Eine Plattform ist niemals “fertig”. Sie verändert sich permanent.

Neue Kubernetes-Versionen erscheinen mehrmals im Jahr. APIs werden eingestellt, Sicherheitslücken veröffentlicht, regulatorische Anforderungen erweitert und Entwicklungswerkzeuge kontinuierlich angepasst. Gleichzeitig verändern sich die Anforderungen der eigenen Entwicklerteams. Neue Frameworks entstehen, Softwarearchitekturen entwickeln sich weiter und Geschäftsmodelle wachsen.

Eine Plattform muss auf all diese Veränderungen reagieren können, ohne ihre Stabilität zu verlieren.

Genau deshalb besteht professioneller Plattformbetrieb zu einem erheblichen Teil aus wiederkehrenden Tätigkeiten, die in klassischen Wirtschaftlichkeitsbetrachtungen kaum sichtbar werden: Architekturreviews, Wartungsplanung, Kapazitätsanalysen, Restore-Tests, Sicherheitsbewertungen, Incident-Nachbereitung, Dokumentation und kontinuierliche Standardisierung.

Diese Arbeiten erzeugen keinen unmittelbar sichtbaren Mehrwert. Sie verhindern vielmehr, dass sich technische Schulden über Jahre hinweg unbemerkt ansammeln.

Erfahrene Plattformteams investieren deshalb einen erheblichen Teil ihrer Zeit nicht in neue Technologien, sondern in die Reduzierung zukünftiger Komplexität.

Der größte Fehler beim Outsourcing ist der Verlust von Wissen

Wenn Unternehmen den Plattformbetrieb an einen externen Partner übertragen, entsteht häufig eine berechtigte Sorge.

Verlieren wir dadurch unsere Unabhängigkeit?

Diese Frage ist legitim. Sie wird jedoch häufig an der falschen Stelle beantwortet.

Abhängigkeit entsteht nicht dadurch, dass ein externer Dienstleister operative Aufgaben übernimmt.

Abhängigkeit entsteht dort, wo Wissen verloren geht.

Wenn Architekturentscheidungen ausschließlich vom Dienstleister verstanden werden, Betriebsprozesse nicht dokumentiert sind oder interne Teams keine Möglichkeit erhalten, die Plattform zu verstehen und weiterzuentwickeln, entsteht tatsächlich ein erhebliches Risiko.

Dieses Risiko hat jedoch nichts mit Managed Services zu tun.

Es ist das Ergebnis schlechter Zusammenarbeit.

Ein professioneller Plattformpartner sollte daher niemals versuchen, Wissen zurückzuhalten. Im Gegenteil: Sein Interesse muss darin bestehen, Architekturentscheidungen nachvollziehbar zu dokumentieren, offene Standards einzusetzen, Betriebsprozesse transparent zu gestalten und internes Know-how kontinuierlich aufzubauen.

Diese Haltung mag auf den ersten Blick widersprüchlich erscheinen.

Warum sollte ein Dienstleister seine Kunden unabhängiger machen?

Weil nachhaltige Partnerschaften nicht auf Informationsasymmetrien beruhen, sondern auf Vertrauen und nachweisbarer Kompetenz. Unternehmen wechseln heute selten den Anbieter, weil sie plötzlich mehr Wissen besitzen. Sie wechseln ihn, wenn Transparenz fehlt oder das Gefühl entsteht, die Kontrolle über die eigene Plattform verloren zu haben.

Offene Standards sind mehr als ein technisches Detail

Im Zusammenhang mit Vendor Lock-in wird häufig ausschließlich über proprietäre APIs oder Cloud-Dienste diskutiert.

Diese Sichtweise greift zu kurz.

Abhängigkeiten entstehen ebenso durch proprietäre Betriebsprozesse, individuelle Automatisierung oder fehlende Dokumentation. Selbst eine vollständig auf Open-Source-Komponenten basierende Plattform kann praktisch unportierbar sein, wenn niemand mehr nachvollziehen kann, wie sie aufgebaut wurde.

Digitale Souveränität beginnt deshalb nicht erst bei der Auswahl einer Kubernetes-Distribution.

Sie beginnt bei der konsequenten Nutzung offener Standards, reproduzierbarer Infrastrukturdefinitionen und transparenter Betriebsprozesse.

GitOps, Infrastructure as Code, deklarative Konfigurationen, standardisierte APIs und nachvollziehbare Dokumentation sind deshalb weit mehr als moderne Entwicklungsmethoden. Sie bilden die Grundlage dafür, dass Plattformen langfristig portierbar und unabhängig bleiben.

Die entscheidende Frage lautet nicht, ob ein Unternehmen einen Dienstleister beauftragt.

Die entscheidende Frage lautet, ob es seine Plattform auch ohne diesen Dienstleister weiterentwickeln könnte.

Wenn diese Frage mit Ja beantwortet werden kann, ist echte Souveränität erreicht.

Build und Buy schließen sich nicht aus

Die Diskussion um Build oder Buy vermittelt häufig den Eindruck, dass sich Unternehmen für genau einen Weg entscheiden müssten.

Die Praxis sieht deutlich differenzierter aus.

Viele erfolgreiche Organisationen verfolgen heute hybride Modelle.

Strategische Architekturentscheidungen, Governance und Plattformstrategie verbleiben bewusst im Unternehmen. Operative Tätigkeiten wie Clusterbetrieb, Monitoring, Backup-Management, Security-Patching oder 24/7-Rufbereitschaften werden dagegen an spezialisierte Plattformteams übertragen.

Diese Arbeitsteilung folgt einem einfachen wirtschaftlichen Prinzip.

Unternehmen sollten dort eigenes Wissen aufbauen, wo dadurch ein nachhaltiger Wettbewerbsvorteil entsteht. Tätigkeiten, die zwar geschäftskritisch, aber nicht differenzierend sind, profitieren dagegen häufig von Spezialisierung, Standardisierung und Skaleneffekten.

Plattformbetrieb gehört in vielen Organisationen genau in diese Kategorie.

Er ist unverzichtbar.

Er schafft jedoch nur selten den eigentlichen Unternehmenswert.

Fazit

Die Frage Build or Buy Kubernetes lässt sich nicht pauschal beantworten. Sie hängt von regulatorischen Anforderungen, Unternehmensgröße, vorhandenen Kompetenzen und den strategischen Zielen einer Organisation ab.

Eine Erkenntnis lässt sich jedoch aus nahezu jedem erfolgreichen Plattformprojekt ableiten.

Nicht der Cluster entscheidet über den langfristigen Erfolg einer Kubernetes-Strategie, sondern die Qualität der Betriebsorganisation.

Managed Kubernetes reduziert Infrastrukturaufwand. Managed Platform reduziert organisatorische Komplexität. Beides kann sinnvoll sein – vorausgesetzt, Unternehmen verstehen den Unterschied und treffen ihre Entscheidung bewusst.

Gleichzeitig sollte jede Plattformstrategie darauf ausgerichtet sein, die eigene Handlungsfähigkeit zu stärken. Offene Standards, transparente Prozesse, dokumentierte Architekturentscheidungen und kontinuierlicher Wissenstransfer sind keine optionalen Komfortfunktionen. Sie sind die Voraussetzung dafür, dass Plattformen auch in fünf oder zehn Jahren noch beherrschbar bleiben.

Am Ende geht es deshalb nicht um die Frage, ob Infrastruktur selbst betrieben oder eingekauft wird.

Es geht darum, Verantwortung dort zu übernehmen, wo sie einen strategischen Mehrwert schafft, und sie dort zu delegieren, wo Spezialisierung zu mehr Qualität, höherer Sicherheit und größerer Wirtschaftlichkeit führt.

Schlussgedanken

Die Einführung einer Kubernetes-Plattform gehört zu den weitreichendsten Infrastrukturentscheidungen, die ein Unternehmen heute treffen kann. Sie beeinflusst Architektur, Organisation, Entwicklungsprozesse und nicht zuletzt die wirtschaftliche Leistungsfähigkeit der gesamten Softwareentwicklung.

Gerade deshalb lohnt es sich, diese Entscheidung nicht isoliert aus der Perspektive einer einzelnen Technologie zu betrachten. Häufig zeigt sich bereits in einem gemeinsamen Architekturgespräch, dass die eigentliche Herausforderung weniger im Kubernetes-Cluster selbst liegt als in Fragen der Governance, des Plattformbetriebs oder der organisatorischen Ausrichtung.

Wenn Sie vor der Entscheidung stehen, eine Kubernetes-Plattform aufzubauen, bestehende Betriebsmodelle zu hinterfragen oder die Wirtschaftlichkeit Ihrer Plattformstrategie objektiv bewerten möchten, sprechen Sie mit uns. Wir unterstützen Unternehmen seit vielen Jahren beim Aufbau, Betrieb und der Weiterentwicklung produktionskritischer Kubernetes-Plattformen – unabhängig davon, ob diese in der Public Cloud, auf europäischer Infrastruktur oder im eigenen Rechenzentrum betrieben werden. Unser Ziel ist dabei nicht, Ihnen eine bestimmte Lösung zu verkaufen, sondern gemeinsam das Betriebsmodell zu finden, das technisch, organisatorisch und wirtschaftlich am besten zu Ihrer Organisation passt.

Die Erstberatung ist selbstverständlich unverbindlich und kostenfrei. Sie gewinnen eine fundierte technische Einschätzung, wir lernen Ihre Herausforderungen kennen – und beide Seiten können anschließend beurteilen, ob eine Zusammenarbeit sinnvoll ist. Genau so sollte Beratung aus unserer Sicht funktionieren.