1    Catch-22

»How hard can it be?«
– Jeremy Clarkson, Top Gear

Ja, wie schwer kann das alles schon sein ...

Nun, wenn ich an die mittlerweile weit mehr als 6.000 Seiten denke, die ich in den letzten 6 Jahren im Rahmen von nunmehr 5 deutsch- und englischsprachigen Container- und KI/ML-Infrastruktur- Publikationen zu Papier bzw. in E-Books gebracht habe, stellt sich die Frage von Mister Clarkson bei ernsthafter Betrachtung schon lange nicht mehr.

Denn mittlerweile sind Vanilla-Kubernetes-Cluster und die von ihnen für ein halbwegs produktivtaugliches Umfeld benötigten 3rd-Party Tool Stacks dank ihrer extremen Komplexität und hohen Volatilität oft nur noch eines: eine Arbeitsbeschaffungsmaßnahme erster Güte. Ein Selbstzweck, eine meist kaum noch seriös auflösbare Sisyphus-Schleife, die mittlerweile ein kleines bisschen an den legendären, koordinierten Wahnsinn aus dem im Titel benannten Antikriegsdrama Catch-22 erinnert.

Der Catch-22 besagt vereinfacht: Nur ein Pilot, der verrückt ist, kann beim Arzt einen Antrag auf Fluguntauglichkeit stellen. Ist der Pilot jedoch in der Lage, seinen Antrag auf Fluguntauglichkeit zu stellen, kann er anscheinend doch rational denken und ist daher nicht verrückt, ergo ist er diensttauglich.

Portieren wir das Ganze:

Kunde: »Wir wollen Vanilla Kubernetes einsetzen, damit wir effizienter arbeiten können.«

Neutraler Berater: »Aber mit Vanilla Kubernetes und allen benötigten 3rd-Party Stacks wird sich dank der hohen Volatilität und kurzen Lifecycles Ihr HR- und Kosten-Aufwand eher erhöhen.«

Kunde: »Aber dank des hohen Automationsgrades lässt sich das doch kompensieren.«

Berater: »Prinzipiell ja, wenn sich unter der Kubernetes-Haube nicht alles ständig verändern würde und selbst jede Drittkomponente bei jedem Update immer wieder an etliche andere neu angepasst werden müsste. Wie oft sollen Ihre DevOps-Teams die Automation denn neu aufsetzen? Zudem gibt es keinen Long Term Support. Stattdessen permanent change. Ist sogar der offizielle, stolze CNCF Tenor.«

Kunde: »Aber alle sind doch längst auf den Zug aufgesprungen und es scheint gut zu funktionieren, vor allem in der Cloud, also muss die Sache doch Hand und Fuß haben.«

Berater, in Gedanken: Sicher. Und im Fernsehen gibt es sprechende Knuffelhäschen. Berater, in Worten: »Wenn Sie statt Vanilla Kubernetes beispielsweise OpenShift einsetzen, dann wahrscheinlich.«

Kunde: »Aber das ist doch auch nur ein Kubernetes von Red Hat und kostet zudem Lizenzgebühren. Wir nehmen Vanilla Kubernetes. Punkt.«

Berater, in Gedanken: Ich hab’s versucht. Dann eben das dreifache Beratungskontingent. Ka-Tsching. Berater, in Worten: »Gern, selbstverständlich.«

Als ich mich 2017 entschloss, die erste Publikation über Container-Cluster auf den Weg zu bringen, dachte ich bereits damals, dass Kubernetes als legitimer Nachfolger der guten, alten Pacemaker-HA-Cluster aus der Legacy-Welt ganz sicher einiges umkrempeln würde.

So weit, so gut. Und die Veränderungen kamen, und sie hörten nicht auf. Und es wurden mehr und mehr. Ich begleitete Kubernetes und Co über die Jahre, versuchte mit meinen Büchern halbwegs am Innovationspuls zu bleiben, aber letztlich blieben meine Publikationen nur Snapshots eines bestimmten Evolutionsstandes.

Von Version zu Version beglückte und beglückt uns die CNCF-gesteuerte Innovationsmaschine dank Tausenden von Kontributoren und Millionen von Entwicklern weltweit mit unzähligen neuen Konzepten, Features und Changes, ausgespuckt vom High-Speed-CI/CD-Fließband, und oft genug ohne Backward-Compatibility. Neue Funktionen wurden und werden im gefühlten Sekundentakt eingeführt, alte verworfen, und bestehende, wichtige, aber unausgereifte Funktionalitäten krebsen oft jahrelang mit eklatanten Mankos herum, weil dank ADHS-Mentalität lieber fleißig an neuen Nischen-Features entwickelt wird, die eventuell irgendwann einmal irgendjemand gebrauchen kann, anstatt für den Unternehmensbereich wichtige Features rock-solid zu Ende zu denken.

Um das wortwörtliche Ausmaß etwas besser zu verdeutlichen: Der Punkt, an dem Ihnen eine einzelne Person einen Kubernetes-Cluster mit allen für Produktivsysteme benötigten Tool Stacks von der ersten bis zur letzten, einhundertmillionsten Schraube wirklich vollumfänglich, bis ins letzte Bit, erklären könnte, ist längst passé. Es sei denn, auf diesem Planeten existiert ein Superhirn, das mir persönlich nicht bekannt ist. Auch in Beratungen oder Workshops entdecke ich immer wieder den gleichen Verlauf bei Teilnehmern: die anfängliche Euphorie, sich ›mal eben‹ etwas Know-how zu Kubernetes anzuschaffen, die nach und nach der etwas bedrückenden Erkenntnis weicht, dass man selbst nach vier mit vielen Informationen angefüllten Tagen lediglich einen kleinen, oberflächlichen Blick in die gewaltige Tiefe geworfen hat, die Kubernetes-Cluster längst darstellen.

Die Problematik wurde noch deutlicher, als ich in den Jahren 2020 bis 2022 zusammen mit NVIDIA an meiner Publikation über Skalierbare KI/ML-Infrastrukturen arbeitete, die Ende 2022 erschien.

Obwohl das KI-Infra-Buch mit einem Volumen von 468 Seiten gerade einmal einem Drittel des Umfangs meiner bisherigen Container-Publikation entsprach, dauerte die Arbeit daran erstmals ganze drei Jahre, und damit fast dreimal so lange wie die an einer meiner Container-Publikationen. Ursache: das hochvolatile und komplexe Kubernetes im Unterbau, und dazu der hochvolatile und hochkomplexe KI/ML-Stack mit GPU-, NFD- und AI-Workspace-Operatoren on top, dazu die Virtualisierungsschicht mit IaC-Automation, deren GPU-Hardware mithilfe Dutzender Einstellschrauben, die sich ebenfalls gern und schnell verändern, für den jeweiligen Anwendungsfall vernünftig und vollautomatisiert integriert werden will. Und alles in permanenter Veränderung.

Trauriger Fakt war, dass ich nach Beendigung der Arbeit an einem Themenblock oft genug den vorherigen, bereits fertiggestellten wieder überarbeiten oder gar komplett neu erstellen musste. Sisyphus lässt grüßen, aber wie üblich sucht sich jeder sein zu tragendes Päckchen meist selber aus.

Und das gilt auch für die Unternehmen, die sich entscheiden, Vanilla Kubernetes einzusetzen – und darunter fallen auch alle Managed-Cloud-Derivate wie GKE, AKS, EKS und Co. Die Gründe für die Ineffizienz im Vergleich zu echten Enterprise-Kubernetes-Lösungen sind vielfältig und werden später im Buch ausführlich thematisiert.

Aber die Vanilla-Kubernetes-basierten Lösungen sind zumindest eines: eine unlimitierte Gelddruckmaschine für Beratungsunternehmen, die mit oftmals brandgefährlichem Halbwissen ihren Kunden Kubernetes-Cluster nach wie vor als die simple Universal-Lösung für alle IT-Probleme schmerzfrei anpreisen. Zügige Migration? Kein Problem. Know-how-Transfer? Alles schnell erledigt, vertrauen Sie uns!

Na sicher.

Und genau diese Praktiken sind wiederum erfahrungsgemäß auch der Hauptgrund, warum ebenfalls zahllose Unternehmen – nach ebendiesen fragwürdigen Versprechungen – in den fatalen Irrglauben versetzt werden, dass die Migration ihrer hochkomplexen Legacy-Systeme in containerisierte Umgebungen in maximal zwei Wochen komplett abgefrühstückt ist. Und ihre Mitarbeiter nebenbei »mal eben«, am besten in maximal zwei Tagen, vollumfänglich zu hochkompetenten Container-Spezialisten ausgebildet werden können. Und wieder: Na sicher.

Willkommen im Schwurbel-Bingo-Einhorn-Land.

Eine höchst bedauerliche Problematik, auf die ich bereits in meinen letzten vier Container-Publikationen mehr als ausdrücklich hingewiesen habe und an der sich bis heute herzlich wenig geändert hat. Im Gegenteil. Aber was soll’s – denn den Sales-Fraktionen von AWS, GCP, Azure, Red Hat, VMware, NVIDIA und Co. bereitet das meist keine mächtigen Kopfschmerzen. Allen übrigen Beteiligten sehr wohl.

Denn im Grunde gilt nur noch eine Regel: dass nichts mehr gilt. Oder in Langform: Das meiste, was gestern noch superhip und State of the Art war, ist heute gern nur noch alter Krempel, der keinen mehr wirklich interessiert. LTS, Long Term Support ... was war das gleich noch?

Und das trifft auf fast alle Beteiligten zu – mit Ausnahme des Endkunden im Unternehmensbereich. Denn der würde sich gern einfach mal eine etwas langsamere Pace wünschen, deutlich weniger Komplexität und dass die mittlerweile unzähligen Schrauben einfach mal länger als gefühlte zwei Tage supported werden – Innovation hin oder her. Was schätzen Sie, wie viele Unternehmenskunden aktuell noch auf einer Vanilla-Kubernetes-Version herumjonglieren, deren EOL bereits vor einem Jahr oder deutlich längerer Zeit abgelaufen ist – ganz einfach, damit die Systeme beim längst überfälligen Upgrade nicht komplett explodieren und dann ohnehin from scratch neu aufgebaut werden müssen?

Seien Sie versichert, es sind nicht wenige. Und es sind einige durchaus bekannte Namen dabei.

Selbstverständlich ist das keine Info, die die CNCF oder die betroffenen Unternehmen gern an die große Glocke hängen. Fatalerweise müssen sich die Unternehmen aber ebendieser hochvolatilen und auf Dauer explosiven Gemengelage permanent neu stellen und anpassen, und dies oft zu einem – im wahrsten Sinne des Wortes – hohen Preis. Kosteneffizienz ist langfristig nun einmal nur mit maximaler Vollautomation zu erreichen. Und die kann mittel- und langfristig niemals erreicht werden, wenn sich das Kernsystem im Unterbau und alle wichtigen...