Wer hält das Ruder

Ein Nachmittag auf dem Canonical Day Frankfurt

Kubernetes ist ein griechisches Wort. Es bedeutet Steuermann. Nicht Kapitän, nicht Reeder, nicht Eigner der Ladung. Steuermann. Derjenige, der das Ruder hält, während andere die Route bestimmen und wieder andere besitzen, was im Laderaum liegt.

Es ist bemerkenswert, wie selten dieser Wortsinn jemanden interessiert, der täglich mit Kubernetes arbeitet, ob als k3s, k0s oder eine der vielen anderen Distributionen. Man deployt auf Kubernetes, man patcht Kubernetes, man flucht über Kubernetes (wie ich das gemacht habe), und das Wort selbst bleibt eine leere Vokabel. Dabei steckt in ihm die einzige Frage, die bei jeder Infrastrukturentscheidung wirklich zählt, beziehungsweise zählen sollte. Nicht, welche Technologie auf dem Schiff läuft. Das ist am Ende nebensächlich, es sind nur Werkzeuge. Sondern wer das Ruder hält.

Am 21. Mai war ich auf dem Canonical Day in Frankfurt, ein Event, auf das ich mich schon lange gefreut habe. Auf der Agenda standen Virtualisierungsalternativen, Ubuntu Pro, Containerorchestrierung, die üblichen, durchaus spannenden Stationen eines Vendor-Nachmittags. Hinter der Agenda stand, von der ersten Folie bis zum letzten Glas am Networking-Tisch, eine einzige Frage, und es war genau jene, die das Wort Kubernetes seit der Antike mit sich trägt. Wer steuert hier eigentlich.

Das klingt nach einer Frage, auf die eine Konferenz routiniert die erwartbare Antwort gibt. Digitale Souveränität, Unabhängigkeit, weg von den Hyperscalern, Souveränitätswashing, der ganze rhetorische Vorrat, der sich auf Folien gut macht und im Rechenzentrum leider viel zu selten ankommt. Aber so lief es nicht. Der interessanteste Teil dieses Tages war, dass die Antwort komplizierter ausfiel als die Parolen, und ehrlicher.

Der erste Vortrag des Nachmittags gehörte also Kubernetes, und er begann mit einem Geständnis, das man auf einer Herstellerbühne nicht erwartet. Der Kollege von Canonical erzählte nicht, wie einfach, wie elegant, wie alternativlos die Containerorchestrierung sei. Er sagte das Gegenteil. Kubernetes verspreche Vereinheitlichung, eine große Community, fertige Bausteine für jeden Zweck. Und dann halte es dieses Versprechen oft nicht. Es sei nicht einfach, sondern hart. Nicht aufgeräumt, sondern fragmentiert. Viele Organisationen würden mit Kubernetes nicht schneller, nicht sicherer und nicht günstiger, sondern langsamer, verwundbarer und teurer.

Man muss kurz innehalten, um zu würdigen, was da geschah. Einer der großen Anbieter, der einen erheblichen Teil seines Geschäfts mit genau dieser Technologie macht, stellt sich auf seine ureigene Veranstaltung und sagt dem Publikum, dass das Werkzeug, das er verkauft, die meisten Leute überfordert. Das ist kein Vertriebsgespräch. Das ist die seltene Sorte Ehrlichkeit, die entsteht, wenn jemand seine Sache gut genug kennt, um ihre Schattenseiten nicht fürchten zu müssen. Wir kennen alle genug Anbieter, bei denen die Welt nur aus makellosen Wolken besteht. Chapeau.

Diese Ehrlichkeit war kein Ausrutscher. Sie war für mich das Muster des Tages. Und hinter ihr lag ein Prinzip, das tiefer reicht als nur rhetorische Bescheidenheit.

Sichtbar wurde dieses Prinzip, als ein Gast eine Frage stellte. Sie klang zunächst technisch, war aber im Kern eine Provokation. Wenn ohnehin alles Open Source sei, könne ein Kunde, der volle Souveränität wolle, die Sicherheitsarbeit dann nicht auch selbst übernehmen? Bildet Canonical seine Kunden also dazu aus, am Ende ohne Canonical auszukommen?

Die Antwort hätte ausweichen können. Ein Anbieter, der vom Verkauf von Dienstleistungen lebt, hat keinen naheliegenden Grund, dem Kunden zu erklären, wie er ihn wieder loswird. Der Kollege antwortete trotzdem geradeheraus. Das Ziel eines Managed-Service-Vertrags seitens Canonical sei nicht, dauerhaft der Managed-Service-Provider zu bleiben. Das übliche Modell sehe rund zwei Jahre vor, in denen Canonical den Betrieb übernimmt und das Wissen an den Kunden übergibt. Danach, so die Formulierung, ziehe man sich zurück.

Diesen Satz sollte man zweimal lesen. Ein Unternehmen beschreibt als Normalfall seines Geschäfts, dass es sich nach zwei Jahren planmäßig selbst überflüssig macht. Die Unabhängigkeit des Kunden, sagte der Kollege, entstehe nicht durch ein Versprechen des Anbieters, sondern durch die Sache selbst. Die Software ist offen, jegliches Tooling frei verfügbar, man muss Canonical dafür nicht einmal anrufen, sich registrieren oder irgendeine Art von Cloud-Identity anlegen. Es bestehe keine Pflicht, irgendetwas von Canonical oder von sonst jemandem zu lizenzieren. Wer wolle, könne sich selbst versorgen.

Genau hier liegt der Unterschied, um den es an diesem Tag eigentlich ging. Souveränität ist nicht die Abwesenheit eines Anbieters. Wir wissen alle: Niemand baut ein Rechenzentrum im Alleingang, niemand betreibt eine kritische Plattform ohne Hilfe von außen. Souveränität aber ist die Frage, ob dieses Verhältnis den eigenen Ausstieg von Anfang an mitdenkt oder ihn verhindert, wobei verhindern nur das höfliche Wort für Lock-in ist, ob direkt oder indirekt. Der Steuermann darf, muss sich an Bord helfen lassen. Er darf nur das Ruder niemals aus der Hand geben.

Wie dieses Prinzip in der Praxis aussieht, führte am selben Nachmittag ein Unternehmen vor, das man im Zusammenhang mit digitaler Souveränität nicht zuerst auf dem Zettel hat. OEDIV ist die IT-Tochter von Dr. Oetker. Der Konzern dahinter steht für rund 130 Jahre Tradition, für Backpulver und die allbekannte Tiefkühlpizza, für eine solide deutsche Bürgerlichkeit, die man eigentlich gar nicht mit technischer Avantgarde zusammen sieht. Genau deshalb ist der Fall so interessant.

Hinter dieser unauffälligen Fassade arbeitet eine IT-Tochter mit etwa 500 Mitarbeitern, über 300 Kunden und eigenen Rechenzentren, die rund tausend Ubuntu-Systeme betreibt. Sie automatisiert nicht nur mit fertigen Werkzeugen, sondern hat sich einen eigenen, Git-zentrierten Orchestrator gebaut. Das ist das Steuermann-Prinzip in Reinform. Ein Dienstleister, der seine Infrastruktur nicht nur bedient, sondern versteht, und der die Werkzeuge dafür notfalls selbst herstellt.

Bemerkenswert war die Begründung. OEDIV setzt nicht auf Open Source, weil es modern klingt, sondern weil es das Risiko senkt. Der LTS-Zyklus von Ubuntu ist planbar und reicht deutlich weiter als bei den meisten Alternativen. Das erlaubt lange, ruhige Wartungshorizonte.

Zeit ist Souveränität.

Der Support deckt nicht nur das Betriebssystem ab, sondern die gesamte Bandbreite quelloffener Pakete, die das Unternehmen einsetzt, und zwar aus einer Hand statt von einem Dutzend einzelner Zulieferer. Das dreht das vertraute Klischee um. Open Source ist hier nicht das gewagte Experiment, sondern die besonnene Wahl. Ein konservativer Dienstleister entscheidet sich für sie, nicht obwohl er konservativ ist, sondern gerade weil er es ist.

OEDIV war an diesem Nachmittag nicht der einzige Beleg. Wenige Vorträge zuvor hatte das europäische Raumfahrtkontrollzentrum ESOC berichtet, wie es sein Missionskontrollsystem auf Kubernetes umstellt, um bis 2030 deutlich mehr Missionen gleichzeitig betreuen zu können. Auch dort fiel die Begründung nüchtern aus. Open Source sei wichtig, weil die Behörde den Anbieter einer Mission im Zweifel wechseln können müsse.

Das fügt sich in ein größeres Bild. Linux ist im Weltraum längst kein Exot mehr. SpaceX steuert Falcon 9 und Dragon mit einem selbst gepflegten Linux-Kernel, die Arbeitslaptops auf der ISS laufen seit über einem Jahrzehnt auf Debian, und der Marshubschrauber Ingenuity flog mit einem quelloffenen Framework, das das JPL frei auf GitHub bereitstellt. Ausgerechnet die Ingenieure, die sonst nur erprobte und maximal abgesicherte Komponenten mögen, nannten das einen Sieg für Open Source. Man kann lange über digitale Souveränität reden. Oder man schaut, was tatsächlich fliegt.

Zwischen der Tiefkühlpizza und der Asteroidenabwehr liegt technologisch eine ganze Welt. In der Frage, wer das Ruder hält, liegt dazwischen kein Unterschied.

Den eigentlichen Höhepunkt des Tages lieferte nicht Canonical, sondern ein Partner. Dell trat als Sponsor auf und sprach über zertifizierte Hardware. Man könne, so die Botschaft, Dell-Geräte mit vorinstalliertem Ubuntu beziehen, getestet, abgesegnet, betriebsbereit. Das klingt gut, und es ist auch gut gemeint. Nur führt der Weg dorthin über einen Anruf und einen eigens eröffneten Vorgang, nicht immer über den Warenkorb, und die eingesparte Windows-Lizenz taucht im Preis vielleicht trotzdem auf. Das sind keine großen Beträge und vermutlich nicht einmal Dells Entscheidung, sondern das Echo von OEM-Verträgen, die weit über diesem Veranstaltungssaal geschlossen wurden. Erwähnenswert ist es trotzdem, als kleine Erinnerung daran, wie zäh sich gewachsene Strukturen halten, wie schwer eine simple OEM-Lizenz doch wiegen kann.

Interessant wurde es, als jemand aus dem Publikum eine schlichte Frage stellte. Worin denn, abgesehen von der Vorinstallation, der konkrete Mehrwert dieser zertifizierten Hardware liege. Die Antwort fiel zögernd aus. Ein Kollege von Canonical sprang ein und verwies auf zusätzlichen Service rund um die Zertifizierung. Aber der Gast hatte den wunden Punkt schon freigelegt, und er war kein kleiner.

Denn die ehrliche Antwort lautet: einen exklusiven technischen Mehrwert gibt es nicht. Ubuntu ist Open Source. Es gibt keine geheime, nur auf Dell-Geräten lauffähige Schicht, keine proprietäre Anpassung, die das zertifizierte Notebook von anderer Hardware unterscheidet. Wer dasselbe Ubuntu auf ein Gerät von Lenovo, HP oder einem beliebigen anderen Hersteller spielt, bekommt dasselbe System.

Das klingt nach einer Schwäche der Dell-Erzählung. Es ist das komplette Gegenteil. Genau weil es keinen exklusiven Vorteil gibt, bleibt der Kunde frei. Fällt der Hardware-Lieferant aus, wird er zu teuer oder schlicht unsympathisch, zieht das Betriebssystem mit auf das nächste Gerät um, ohne Bruch, ohne Neuaufbau, ohne Verhandlung. Die Zertifizierung ist ein Komfort, kein Käfig. Das ist nicht ein Fehler im Modell. Das ist das Modell selbst.

Und damit wird, fast nebenbei, auch Dell ein Kompliment gemacht, das ernster gemeint ist, als es klingt. Kein Hersteller ist gezwungen, sein Betriebssystem so zu wählen, dass der Kunde es jederzeit wieder verlassen kann. Dell tut es trotzdem. Die Zusammenarbeit mit einem Anbieter wie Microsoft ist für ein Unternehmen dieser Größe eine wirtschaftliche Notwendigkeit, kaum je eine freie Entscheidung. Die Zusammenarbeit mit Canonical, mit einem offenen und jederzeit entkoppelbaren System, ist beides nicht. Sie ist freiwillig. Und das ist, in einer Branche, die Bindung gern als Geschäftsmodell verkauft, bemerkenswerter, als eine routinierte Sponsorenfolie vermuten lässt.

Am Ende dieses Nachmittags ließ sich der rote Faden des Tages in einem einzigen Satz zusammenfassen. Ob Tiefkühlpizza, Raumfahrtbehörde oder zertifiziertes Notebook, ob OEDIV, ESOC oder Dell, es ging immer um dieselbe Frage. Wer hält das Ruder. Und die Antwort, die dieser Tag gab, war nicht die übliche Parole. Sie lautete nicht weg von den Anbietern, sondern hin zu einem Verhältnis, in dem der Anbieter helfen darf, ohne zu besitzen.

Es wäre allerdings zu einfach, hier mit einem Hochgefühl zu schließen. Denn das Ruder zu halten ist nicht nur ein Recht, es ist eine Last. Der ehrlichste Moment des Tages war nicht zufällig jenes Eingeständnis, dass Kubernetes hart ist. Souveränität ist es auch. Wer die Kontrolle über seine Infrastruktur behalten will, muss diese Kontrolle ausüben können, und das verlangt Wissen, Personal, Ausdauer. Die Werkzeuge sind frei verfügbar. Die Kompetenz, sie zu führen, ist es nicht.

Vielleicht ist das die eigentliche Erkenntnis dieses Tages. Die Frage der digitalen Souveränität ist längst keine Frage der Verfügbarkeit mehr. Die offenen Systeme sind da, erprobt, im Rechenzentrum wie im Orbit. Es bleibt eine Wahl: Opportunismus und Bequemlichkeit gegen Souveränität. Die Frage ist, ob man bereit ist, Steuermann zu sein. Nicht Passagier, nicht Fracht. Steuermann. Den Rest entscheidet nicht der Anbieter. Den entscheidet man selbst.