Die Kubernetes-Dominanz erodiert

Zeit, das Kubernetes-Steuerrad wegzulegen?cdrin | shutterstock.com



Über Jahre hinweg hat Kubernetes in Sachen Enterprise IT einen nahezu mythischen Stellenwert eingenommen. Das Open-Source-Orchestrierungssystem galt lange als die Control Plane für die Zukunft, als Abstraktions-Goldstandard für Cloud-native Systeme und die Plattform, die Unternehmen endlich von der Bürde des Vendor-Lock-In befreien kann. Das ist in Teilen auch zutreffend: Kubernetes brachte Struktur in die Container-Orchestrierung, ermöglichte portable Deployment-Modelle und bot Architekten ein leistungsstarkes Framework, um verteilte Anwendungen in großem Maßstab zu managen.



Allerdings verändert sich der Markt und auch die Erwartungen der Unternehmen. Inzwischen ist die Frage nicht mehr, ob Kubernetes aus technischer Perspektive beeindruckend ist. Das ist es auf jeden Fall. Vielmehr wachsen Zweifel, dass Kubernetes noch die beste Lösung für eine wachsende Zahl von Mainstream-Anwendungsfällen darstellt. Immer öfter ist das nicht der Fall. Das ist nicht das Ende für Kubernetes – nur das seiner unangefochtenen Enterprise-Dominanz. In diesem Artikel beleuchten wir die Gründe dafür.



Explodierende Betriebskosten



Während sich Kubernetes immer weiter im Unternehmensumfeld ausbreitete, wollten sich viele Organisationen zunächst nicht eingestehen, dass eine Adoption auch ihren Preis hat. Dieser setzt sich aus einer höheren Komplexität im Betrieb, speziellem Knowhow und strenger Governance zusammen. Um Kubernetes erfolgreich einzusetzen, braucht es ausgereifte Skills in den Bereichen Entwicklung, Observability, Security, Netzwerke, und Life Cycle Management.



Kubernetes ist also deutlich mehr als nur ein „Nebenprojekt“. Der damit einhergehende Aufwand wurde vielfach unterschätzt: Was in Architekturdiagrammen elegant wirkte, wurde in der Praxis zu einer multiplen Belastung für die Operations-Teams:




Die Anzahl der Cluster stieg sprunghaft an,



die Toolchains wuchsen unkontrolliert,  



Upgrades wurden riskant und  



Richtlinien durchzusetzen, entwickelte sich zu einer eigenständigen technischen Disziplin.




Anwenderunternehmen mussten erkennen, dass sie nicht nur eine Orchestrierungsplattform eingeführt hatten. Mit Kubernetes hatten sie ein internes Produkt aufgebaut, das Wartungsaufwand, nachhaltige Investitionen und rares Fachwissen erforderte.



Für Digital-Native-Unternehmen, deren Größe und Komplexität diesen Aufwand rechtfertigen, ist das akzeptabel. Unternehmen, die auf zuverlässige Deployments, ausfallsichere Applikationen und angemessene Cloud-Kosten Wert legen, ist das aber schon deutlich schwerer zu „verkaufen“. Und das vollkommen zurecht: In diesen Fällen ist Kubernetes überdimensioniert. Wenn Organisationen am Ende mehr Zeit damit verbringen, eine Plattform zu managen als geschäftlichen Mehrwert aus ihr zu „ziehen“, verfliegt ihr anfänglicher Reiz relativ schnell.



Sinkender Portabilitäts-Stern



Weil Kubernetes es ermöglicht, Anwendungen auf lokalen Systemen, in der Cloud und am Netzwerkrand auszuführen, wurde es (auch) als Schutzmaßnahme vor Vendor-Lock-In vermarktet. Allerdings sahen sich die meisten Anwenderunternehmen mit Ökosystem-Abhängigkeiten konfrontiert – etwa im Hinblick auf Speicher, Netzwerk, Security, Identity Management oder Observability. Anders ausgedrückt: Der Lock-In wurde lediglich verlagert.  



Was Unternehmen in Sachen Workload-Portabilität gewannen, verloren sie so oft wieder an die Komplexität des Ökosystems: Sie standardisierten auf Kubernetes, waren aber weiterhin stark von den Managed Services und Betriebskonventionen eines bestimmten Cloud-Anbieters abhängig. Das Ergebnis war ein seltsamer Mittelweg: die volle Komplexität einer hochgradig abstrahierten Plattform – ohne die Simplizität der durchgängigen Nutzung von nativen Services.



Dies ist heute umso wichtiger, weil Vorstände und Führungsteams weniger an theoretischen architektonischen Optionen interessiert sind. Sie haben eher messbare Geschäftsergebnisse im Blick und sind auf Geschwindigkeit, Ausfallsicherheit, Kostenkontrolle und geringe(re)s Risiko aus. Wenn eine Managed-Application-Plattform, eine Serverless-Umgebung oder ein anbieterspezifisches Platform-as-a-Service-Angebot sie schneller ans Ziel bringt, sind viele bereit, ein gewisses Maß an Abhängigkeit in Kauf zu nehmen. Sie erkennen, dass strategische Flexibilität zwar wertvoll ist, aber eben nicht um jeden Preis. Portability ist ebenso wertvoll, rechtfertigt für viele Anwender jedoch nicht den damit verbundenen betrieblichen und organisatorischen Aufwand. Anders ausgedrückt: Kubernetes liefert in vielen Fällen weniger als ursprünglich versprochen.



Abstraktionsalternativen holen auf



Der vielleicht bedeutendste Shift besteht jedoch darin, dass Unternehmen zunehmend davon absehen, rein technische Grundbausteine zu kaufen. Stattdessen setzen sie auf übergeordnete Plattformen, die sich eher mit der Entwicklerproduktivität und den Geschäftszielen in Einklang bringen lassen. So „verstecken“ Platform-Engineering-Teams Kubernetes etwa zunehmend hinter internen Developer-Plattformen. Public-Cloud-Anbieter optimieren weiterhin gemanagte Container-Services, Serverless-Angebote und auch integrierte Anwendungsumgebungen, die den manuellen Infrastrukturmanagement-Aufwand reduzieren. Und dann sind da noch die Entwickler: Sie legen keinen Wert darauf, zu Cluster-Betreibern in Teilzeit zu werden. Sie wünschen sich schnelle Wege, um Applikationen zu bauen, bereitzustellen, abzusichern und zu überwachen – ohne dazu vorher ein Dutzend verschiedener Komponenten zusammenflicken zu müssen.



Kubernetes mag unter der Haube zwar weiterhin vorhanden sein, rückt jedoch immer mehr in den Hintergrund und spielt auch bei strategischen Kaufentscheidungen eine zunehmend geringere Rolle. Entsprechend beschäftigen sich Unternehmen auch weniger mit der Frage, wie sie Kubernetes einführen. Sondern eher damit, wie der schnellste, sicherste und kostengünstigste Weg aussieht, um moderne Apps bereitzustellen.



Die Antwort darauf finden sie zunehmend in kuratierten Plattformen, Dev-Umgebungen und auch Managed Services, die Kubernetes abstrahieren statt exponieren. Dabei geht es nicht darum, Cloud-Native-Prinzipien entgegenzutreten, sondern unnötige kognitive Belastung zu vermeiden. Die Anwender erkennen, dass sie nicht jeden Komplexitäts-Layer selbst „ownen“ müssen, um in den Genuss der Benefits moderner Architekturen zu kommen.



Selektive Komplexitätsakzeptanz



Wie eingangs bereits dargelegt, wird Kubernetes aber nicht von der Bildfläche verschwinden. Für großangelegte, heterogene und stark individualisierte Umgebungen bleibt die Open-Source-Plattform weiterhin wichtig. Zudem ist sie auch weiterhin hervorragend für Unternehmen geeignet mit:




ausgeprägter Plattformreife,



regulatorischen Auflagen oder



komplexen Multicloud-Betriebsanforderungen.




Das ist allerdings ein deutlich engerer Marktbereich, als der Hype Cycle einst vermuten ließ.



Als Technologie verliert Kubernetes nicht an Popularität, aber als unangefochtener Standard für Unternehmen. Diese werden immer selektiver darin, wo sie Komplexität akzeptieren und wo sie sie vermeiden. Dabei neigen sie weniger dazu, Infrastruktur zu idealisieren – sie sind eher bestrebt, sich für simple Lösungen zu entscheiden, wenn diese vorhanden sind.



Das ist wahrscheinlich auch eine gute Entwicklung: Die Aufgabe der Enterprise Architecture besteht schließlich nicht darin, elegante Technologie um ihrer selbst willen zu bewundern. Sie besteht darin, Technologieentscheidungen an betrieblichen Realitäten, wirtschaftlichen Zwängen und Geschäftsergebnissen auszurichten. Nach diesem Maßstab hat Kubernetes zwar immer noch seinen Platz, verliert aber seinen Freifahrtschein. (fm)



Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.