Build or Buy Kubernetes? Teil 2

Die versteckten Kosten von Kubernetes: Warum die Infrastruktur meist der kleinste Posten ist

Teil 2 unserer Serie „Build or Buy Kubernetes"

Nachdem wir im ersten Teil betrachtet haben, weshalb die Entscheidung für Kubernetes weit über die Wahl einer [Container]-Orchestrierungsplattform hinausgeht, stellt sich zwangsläufig die nächste Frage: Was kostet der Betrieb einer Kubernetes-Plattform tatsächlich?

Die meisten Unternehmen beginnen diese Betrachtung mit den falschen Zahlen.

Sie vergleichen Preise für virtuelle Maschinen, Managed-Kubernetes-Angebote oder Cloud-Instanzen. Kalkuliert werden die Kosten der Control Plane, der Worker Nodes, des Storage oder des ausgehenden Datenverkehrs. Diese Positionen sind leicht messbar und erscheinen auf jeder monatlichen Rechnung des Cloud-Anbieters.

Gerade deshalb vermitteln sie eine trügerische Sicherheit.

Denn aus betriebswirtschaftlicher Sicht gehören Infrastrukturkosten zu den am einfachsten kalkulierbaren Bestandteilen einer Kubernetes-Plattform. Sie folgen bekannten Skalierungsmodellen, lassen sich budgetieren und mit geeigneten Werkzeugen kontinuierlich optimieren.

Die eigentlichen Kosten entstehen an einer anderen Stelle – dort, wo sich technologische Komplexität in organisatorischen Aufwand übersetzt.

Infrastruktur ist selten der größte Kostenfaktor

Ein produktiver Kubernetes-Cluster verursacht Kosten für Compute, Netzwerk und Storage. Ab einer gewissen Größenordnung kommen Load Balancer, Container Registry, Observability-Stack oder Backup-Infrastruktur hinzu. All diese Komponenten lassen sich beziffern und in einer Total-Cost-of-Ownership-Betrachtung berücksichtigen.

Wesentlich schwieriger ist die Bewertung der Ressourcen, die notwendig sind, um diese Plattform dauerhaft zuverlässig zu betreiben.

Ein hochverfügbarer Cluster benötigt nicht lediglich Administratoren, sondern Ingenieure mit fundierten Kenntnissen in Linux, Netzwerktechnologien, Storage-Systemen, Public-Key-Infrastrukturen, Observability, Identity- und Access-Management sowie moderner Softwarebereitstellung. Hinzu kommen regulatorische Anforderungen, Sicherheitsprozesse, Incident Management und kontinuierliche Weiterbildung.

Diese Kompetenzen lassen sich nicht beliebig skalieren.

Sie entstehen über Jahre praktischer Erfahrung.

Während sich ein zusätzlicher Worker Node innerhalb weniger Minuten bereitstellen lässt, benötigt der Aufbau eines erfahrenen Plattformteams oftmals mehrere Jahre. Genau deshalb stellt qualifiziertes Personal den mit Abstand größten Investitionsfaktor im Plattformbetrieb dar.

Die teuerste Ressource einer Kubernetes-Plattform ist selten der Cluster selbst. Es sind die Menschen, die seine Stabilität sicherstellen.

Kubernetes verändert die Kostenstruktur eines Unternehmens

Interessanterweise steigen mit der Einführung von Kubernetes nicht zwangsläufig die Infrastrukturkosten. Häufig sinken sie sogar durch eine bessere Ressourcenauslastung, höhere Automatisierung und standardisierte Deployments.

Was sich jedoch verändert, ist die Verteilung der Kosten.

An die Stelle klassischer Infrastrukturinvestitionen treten kontinuierliche Aufwendungen für Plattformentwicklung, Governance und Betriebsprozesse. Kubernetes verschiebt Investitionen von Hardware zu Wissen.

Diese Verschiebung bleibt in vielen Wirtschaftlichkeitsanalysen unberücksichtigt.

Ein Unternehmen, das sich für den Eigenbetrieb entscheidet, investiert nicht nur in Server oder Cloud-Ressourcen. Es investiert in den langfristigen Aufbau einer Organisation, deren Aufgabe darin besteht, eine interne Plattform kontinuierlich weiterzuentwickeln.

Mit jeder zusätzlichen Anwendung wächst der Anspruch an Standardisierung, Dokumentation und Automatisierung. Aus einer technischen Betriebsumgebung entsteht schrittweise ein internes Produkt, dessen Nutzer die eigenen Entwicklungsteams sind.

Damit verändern sich nicht nur die technischen Anforderungen, sondern auch die wirtschaftlichen Kennzahlen.

Der Preis organisatorischer Komplexität

In der Softwarearchitektur wird Komplexität häufig als technisches Problem verstanden.

Im Plattformbetrieb ist sie jedoch vor allem ein organisatorisches Problem.

Jede neue Komponente erweitert nicht nur die technische Architektur, sondern erhöht gleichzeitig die Anzahl möglicher Abhängigkeiten, Betriebszustände und Fehlerbilder. Mit jeder zusätzlichen Schnittstelle wächst der Aufwand für Dokumentation, Testautomatisierung, Monitoring, Incident Response und Change Management.

Diese Zusammenhänge sind selten unmittelbar sichtbar.

Sie äußern sich beispielsweise in längeren Abstimmungsprozessen zwischen Entwicklung und Betrieb, steigenden Anforderungen an Dokumentation, komplexeren Freigabeprozessen oder einer wachsenden Zahl betrieblicher Sonderfälle.

Die Plattform wird dadurch nicht zwangsläufig instabil. Sie wird jedoch zunehmend schwieriger zu verstehen.

Genau hier setzt das Konzept der Cognitive Load an, das insbesondere durch das Buch Team Topologies geprägt wurde.

Cognitive Load als betriebswirtschaftlicher Faktor

Jedes Entwicklungsteam verfügt nur über eine begrenzte Fähigkeit, komplexe Systeme gleichzeitig zu verstehen, zu betreiben und weiterzuentwickeln.

Diese kognitive Belastung ist keine theoretische Größe, sondern einer der wichtigsten Einflussfaktoren auf Produktivität, Fehleranfälligkeit und Innovationsgeschwindigkeit.

Wenn Softwareentwickler neben ihrer eigentlichen Fachdomäne zusätzlich Netzwerkarchitekturen, [Kubernetes]-Interna, Storage-Konzepte, Service Meshes, Zertifikatsmanagement, Policy Engines und Sicherheitsprozesse beherrschen müssen, steigt die Komplexität ihrer täglichen Arbeit erheblich.

Die Folge ist nicht zwangsläufig schlechtere Software.

Die Folge ist langsamere Softwareentwicklung.

Jede Stunde, die ein Entwicklungsteam in die Analyse einer fehlerhaften NetworkPolicy investiert, steht nicht mehr für die Weiterentwicklung des eigentlichen Produkts zur Verfügung.

Damit entstehen Opportunitätskosten, die sich in keiner Cloud-Rechnung wiederfinden.

Conway’s Law wirkt auch im Plattformbetrieb

Ein weiterer Aspekt wird in der Build-or-Buy-Diskussion häufig übersehen.

Nach Conway’s Law spiegeln Softwarearchitekturen die Kommunikationsstrukturen der Organisation wider, die sie entwickelt.

Dieser Zusammenhang gilt in besonderem Maße für Kubernetes.

Unternehmen, die mehrere Entwicklungsteams auf einer gemeinsamen Plattform arbeiten lassen, benötigen zwangsläufig organisatorische Schnittstellen. Plattformteams definieren Standards. Entwicklungsteams konsumieren diese Standards. Security-Abteilungen formulieren Richtlinien. Compliance-Verantwortliche etablieren Audit-Prozesse.

Die Plattform wird damit zum gemeinsamen Produkt unterschiedlichster organisatorischer Einheiten.

Je größer diese Organisation wird, desto wichtiger werden klare Verantwortlichkeiten, standardisierte Prozesse und eine konsistente Governance.

Die Einführung von Kubernetes verändert daher nicht nur die technische Architektur eines Unternehmens. Sie verändert dessen Zusammenarbeit.

Wann lohnt sich ein eigenes Platform Team?

An dieser Stelle stellt sich zwangsläufig die Frage, ob jedes Unternehmen ein eigenes Platform Team aufbauen sollte.

Die Antwort lautet: nicht unbedingt.

Organisationen, deren Wettbewerbsvorteil unmittelbar aus ihrer Plattformkompetenz entsteht, profitieren häufig von einem dedizierten Plattformteam. Hyperscaler, SaaS-Plattformen oder Unternehmen mit stark standardisierten Entwicklungsprozessen können erhebliche Skaleneffekte erzielen, wenn Plattformentwicklung zu einer eigenen Kernkompetenz wird.

Für viele mittelständische Softwareunternehmen stellt sich die Situation jedoch anders dar.

Ihr wirtschaftlicher Erfolg hängt nicht davon ab, ob sie besonders effiziente Kubernetes-Upgrades durchführen oder Admission Controller entwickeln.

Er hängt davon ab, wie schnell sie hochwertige Software für ihre Kunden bereitstellen können.

In solchen Organisationen sollte kritisch hinterfragt werden, welche Aufgaben tatsächlich strategische Differenzierungsmerkmale darstellen und welche sich standardisieren oder an spezialisierte Plattformbetreiber übertragen lassen.

Ein eigenes Platform Team aufzubauen bedeutet nicht lediglich, zusätzliche Stellen zu schaffen. Es bedeutet, dauerhaft Verantwortung für Architektur, Betrieb, Governance, Dokumentation, Sicherheitsprozesse und kontinuierliche Weiterentwicklung zu übernehmen.

Diese Entscheidung sollte ebenso sorgfältig getroffen werden wie die Entwicklung eines eigenen Softwareprodukts.

Total Cost of Ownership endet nicht bei der Cloud-Rechnung

Eine belastbare Wirtschaftlichkeitsbetrachtung muss daher deutlich weiter reichen als der Vergleich verschiedener Infrastrukturangebote.

Sie sollte unter anderem folgende Fragen beantworten:

• Welche personellen Ressourcen werden für einen stabilen 24/7-Betrieb benötigt?
• Welche Kosten entstehen durch Rufbereitschaften, Vertretungsregelungen und kontinuierliche Weiterbildung?
• Wie hoch ist der Aufwand für Auditierungen, regulatorische Anforderungen und Sicherheitsprozesse?
• Welche Opportunitätskosten entstehen dadurch, dass hochqualifizierte Ingenieure Plattformprobleme statt Produktinnovationen lösen?
• Welche Auswirkungen haben steigende organisatorische Komplexität und wachsende Cognitive Load auf die Liefergeschwindigkeit neuer Funktionen?

Erst wenn diese Faktoren gemeinsam betrachtet werden, entsteht ein realistisches Bild der tatsächlichen Kosten einer [Kubernetes]-Plattform.

Nicht selten zeigt sich dabei, dass die Infrastruktur nur einen vergleichsweise kleinen Teil der Gesamtinvestition ausmacht.

Fazit

Kubernetes ist weder günstig noch teuer.

Es macht lediglich sichtbar, welche organisatorischen Investitionen notwendig sind, um moderne Softwareplattformen zuverlässig zu betreiben.

Wer den Eigenbetrieb ausschließlich anhand von Infrastrukturkosten bewertet, unterschätzt den eigentlichen Aufwand erheblich. Entscheidend sind nicht die Kosten für virtuelle Maschinen oder Managed Services, sondern die langfristigen Investitionen in Menschen, Prozesse und organisatorische Reife.

Die eigentliche Build-or-Buy-Entscheidung ist daher keine technische, sondern eine wirtschaftliche und strategische Abwägung: Welche Kompetenzen schaffen einen nachhaltigen Wettbewerbsvorteil – und welche sollten bewusst standardisiert werden, um wertvolle Ingenieurskapazitäten dort einzusetzen, wo sie den größten Nutzen für das Unternehmen stiften?

Im dritten und letzten Teil dieser Serie betrachten wir die unterschiedlichen Betriebsmodelle im Detail. Wir analysieren, warum „Managed Kubernetes" häufig lediglich eine gemanagte Control Plane bedeutet, welche Verantwortung dennoch beim Unternehmen verbleibt und weshalb die langfristig erfolgreichsten Plattformstrategien nicht auf maximale Abhängigkeit, sondern auf Transparenz, offene Standards und systematischen Wissenstransfer setzen.