Stellen Sie sich einen Kubernetes-Cluster ohne eine einzige Netzwerkkarte vor. Seine Nodes wissen nichts von TCP/IP, nicht einmal von Ethernet; sie rufen sich über Funk in kurzen 32-Byte-Paketen zu, wie Poliere mit Walkie-Talkies auf einer Baustelle. Die Control Plane ist in einer Sprache aus den späten Achtzigern geschrieben und kommt samt Netzwerkprotokoll auf rund 1.250 Zeilen. Um einen Pod zu starten, wird nichts heruntergeladen: Der Node lädt einfach ein Modul und ruft darin eine Prozedur auf. Und das Beste: Das Ganze öffnet sich in einem Browser-Tab, in dem Sie einem Node den Stecker ziehen, den Funk stören, dem Cluster einen gefälschten Befehl unterschieben und zusehen können, was passiert.

Diesen Cluster habe ich in den letzten Wochen gebaut und Kube genannt. Es ist eine Kubernetes Control Plane, geschrieben in Oberon, der Sprache von Niklaus Wirth, und sie läuft auf Oberon-Maschinen, also auf dem Prozessor und dem Betriebssystem, die Wirth selbst entworfen hat, von der Schaltung bis zu den Fenstern auf dem Bildschirm. Auch Kubes Nodes sind Oberon-Maschinen, und sie kommunizieren über ein Funknetz aus demselben Buch: Wirth hat dieses Netzwerk schon Ende der Achtziger für seine Workstations geschrieben, und die Neuauflage des Projekts hat es auf ein billiges Funkmodul verlegt.

Lassen Sie mich gleich sagen, warum ich das mache, denn bei Geschichten wie dieser kommt diese Frage immer zuerst, meist mit einem Schmunzeln. Für mich ist das kein Projekt zum Spaß und auch kein Versuch, eine hübsche alte Technik ans Licht zu zerren, damit man sie bewundert und weitergeht. Es ist vor allem Forschung. Ich möchte verstehen, was aus der Infrastruktur der Vergangenheit hätte werden können, wenn die Ideen, die wir heute Kubernetes nennen, in den Jahren aufgekommen wären, als ein Computer klein war, von einem einzelnen Menschen vollständig verstanden werden konnte und mit seinen Nachbarn über das verbunden war, was gerade zur Hand war. Welche interessanten Prinzipien die vergessenen Technologien in sich trugen und was wir mit ihnen weggeworfen haben. Was diesen Technologien fehlte und warum man sie aufgegeben hat. Und wenn man beides ehrlich sortiert, kann man versuchen, in die Zukunft zu blicken und sich eine Infrastruktur vorzustellen, in der die Komplexität nicht schneller wachsen muss als der Nutzen.

Kubernetes ist dafür ein bequemer Bezugspunkt. Seine Kernidee passt in einen Satz: Man sagt dem System nicht, was es tun soll, sondern beschreibt, was existieren soll, und eine Reihe unabhängiger Schleifen vergleicht immer wieder Soll und Ist und schließt die Lücke Schritt für Schritt. Diese Idee weiß nichts von Go, Containern, etcd oder Clouds, und sie lässt sich auf jede Maschine übertragen. Wirths Maschine eignet sich dafür besser als jede andere, weil man sie vollständig lesen kann, von den Registern des Prozessors bis zum Pod-Scheduler, ohne dass sich etwas unter einem Framework versteckt. Wenn man ein großes System in ein so kleines verpflanzt, wird sofort klar, was daran Wesen und was Ablagerung ist, welche Entscheidungen erzwungen waren und welche bloße Gewohnheit.

Dies ist der zweite Teil meiner Serie über Paleocomputing. Im ersten Teil habe ich erzählt, wie ich Wirths Prozessor im Browser, in QEMU, in Kubernetes und in Cozystack zum Laufen gebracht habe, wo sich eine Oberon-Maschine inzwischen mit einem Klick aus dem Katalog installieren lässt. Sie müssen ihn nicht gelesen haben: Alles, was Oberon und Wirths Maschine betrifft, erkläre ich unterwegs, und Kubernetes kennen Sie vermutlich so gut wie ich. Der Artikel ist wieder lang geworden. Zuerst erzähle ich, wie Kube aufgebaut ist und wie es funktioniert, dann von den Prinzipien, die die Sprache und das Betriebssystem Oberon ihm aufgezwungen haben, worin es sich von echtem Kubernetes unterscheidet, wo es besser und wo es spürbar schlechter geworden ist. Danach folgen sechs Labs, die Sie direkt im Browser durchspielen können, eine Anleitung für alle, die das Ganze selbst installieren wollen, und zum Schluss meine Gedanken dazu, was solche Experimente denjenigen beibringen können, die heute Infrastruktur bauen.

Wenn Sie lieber zuerst anfassen und dann lesen, öffnen Sie das Cluster-Lab. Installieren müssen Sie nichts. Innerhalb einer halben Minute booten drei Maschinen, die Control Plane startet Kube, die Nodes treten bei, und rechts erscheint eine Cluster-Tabelle, die die Seite allein durch Mithören auf dem Funkkanal aufbaut. Quellcode, Dokumentation und sämtliche Messungen liegen im Repository github.com/tym83/paleocomputing.

Wie Kube aufgebaut ist

Oberon und Wirths Maschine in Kürze

Oberon ist zugleich eine Programmiersprache und ein Betriebssystem. Entwickelt haben beides Mitte der Achtziger an der ETH Zürich Niklaus Wirth, der Autor von Pascal und Modula-2, und Jürg Gutknecht. Die Sprache ist winzig: Module, Records, Arrays, Pointer, Garbage Collection und strenge Typisierung, dagegen keine Exceptions, keine Generics und nicht einmal vorzeichenlose Ganzzahlen. Das System passt zur Sprache. Es hat keine Prozesse, keine Threads und keinen Speicherschutz. Ganz unten dreht sich eine einzige Schleife, Oberon.Loop: Sie fragt Maus und Tastatur ab, ruft Kommandos nacheinander auf und ruft in den Pausen zwischen Eingabeereignissen Hintergrund-Tasks auf, Oberon.Task. Ein Task kann nicht unterbrochen werden, also muss er sein Stück Arbeit schnell erledigen und zurückkehren. Multitasking ist hier mit anderen Worten kooperativ und beruht auf den guten Manieren aller Beteiligten.

2013 veröffentlichte Wirth eine Neuauflage des Buchs Project Oberon und ergänzte das System um seinen eigenen Prozessor, RISC5, beschrieben in Verilog. In ein FPGA geladen, lief er auf einem Board mit einem Megabyte Speicher bei 25 MHz. Das ist Wirths Maschine. Bei uns lebt sie in drei Gestalten: Im Browser läuft Wirths tatsächliche Schaltung, nach C++ übersetzt und zu WebAssembly kompiliert; in QEMU läuft unser eigenes Modell der Maschine; und in Kubernetes läuft dasselbe QEMU-Modell innerhalb von KubeVirt.

Wie alles anfing

Die erste Version von Kube war ein reines Spielzeug, und das habe ich in einer eigenen Folge der Serie auch ehrlich gesagt. Sie bestand aus einem einzigen Oberon-Modul mit einem Objekt-Store und drei Controllern, für Deployments, ReplicaSets und Nodes. Die Nodes waren drei Namen, node-a, node-b und node-c, und ein Pod galt nur deshalb als laufend, weil ein Controller den Namen eines Nodes in ihn eingetragen hatte. Nirgends lief irgendetwas. Doch schon diese Version zeigte sehr deutlich, dass das Herz von Kubernetes nicht Container sind, sondern Reconcile-Loops, und dass diese Schleifen wunderbar zu Oberon passen.

Sie passen, weil Oberon bereits alles mitbringt, was eine Control Plane braucht, nämlich eine zentrale Schleife, die Hintergrundarbeit aufruft. Kube.Start installiert die drei Controller als drei Oberon.Tasks mit einer Periode von 50 Millisekunden, im selben Ring, in dem auch der Garbage Collector des Systems läuft, und von da an ruft Oberon.Loop sie auf, wann immer der Benutzer gerade nicht tippt oder die Maus bewegt. Die Controller rufen sich nicht gegenseitig auf und schicken sich nichts. Jeder betrachtet nur Objekte seiner eigenen Art und ändert nur, was ihm gehört, und das Ergebnis seines Durchlaufs wird beim nächsten Durchlauf zur Eingabe eines Nachbarn. Genau so interagieren auch die Controller des echten Kubernetes: über gemeinsamen Zustand, nicht über Nachrichten.

Um das Ganze einen Cluster nennen zu können, fehlten zwei Dinge. Erstens Nodes, also mehrere Maschinen und eine Möglichkeit, miteinander zu sprechen. Zweitens Rollouts, bei denen eine Version einer Anwendung eine andere ohne Downtime ablöst. Bei den Nodes dachte ich zuerst, ich sei in eine Sackgasse geraten, denn Wirths Maschine hat kein Netzwerk. Dann habe ich das Buch noch einmal gelesen und darin den Funk gefunden.

Wirths Funk

Die Oberon-Workstations an der ETH waren immer vernetzt. Wirth schrieb dieses Netzwerk schon Ende der Achtziger für die kabelgebundene Ceres-Workstation, und in der Ausgabe von 2013 verlegte Paul Reed, der mit ihm an der neuen Version des Projekts arbeitete, es auf Funk. Auf dem Board sitzt ein nRF24L01+-Transceiver, ein billiger Chip, den man bis heute in kabellosen Tastaturen und Bastelgeräten findet, und der Prozessor spricht mit ihm über SPI, einen einfachen seriellen Bus. Der Chip ist sehr bescheiden. Er sendet jeweils einen Frame von höchstens 32 Bytes, empfangene Frames warten in einem Puffer mit drei Plätzen, alle Stationen auf einem Kanal hören einander, und eine Kollisionsvermeidung gibt es überhaupt nicht: Sprechen zwei Stationen gleichzeitig, bekommt der Empfänger entweder Müll oder gar nichts.

Der Treiber des Chips, das Modul SCC, umfasst rund zweihundert Zeilen. Jedes seiner Pakete beginnt mit einem acht Byte langen Header mit Adressen, Typ und Länge, und ein langes Paket wird in mehrere 32-Byte-Frames zerlegt. Auf SCC sitzt das Modul Net, ein kleines Protokoll, mit dem sich Stationen Nachrichten und Dateien schicken. Wenn ich im Folgenden von Wirths Funk spreche, meine ich genau dieses Paar, und mit dem Funkkanal alles, was die Stationen auf einem Kanal hören.

Warum Funk und kein gewöhnliches Netzwerk? Weil Wirths Maschine schlicht kein anderes hat. Sie besitzt weder Ethernet noch einen TCP/IP-Stack, und die zu schreiben hieße, ein kleines Linux auf Oberon zu bauen. Der Funk dagegen ist im selben Buch beschrieben, und ich war neugierig, was für ein System herauskommt, wenn ich die Grenzen der Maschine ehrlich akzeptiere, statt ihr ein modernes Netzwerk überzustülpen.

Eine virtuelle Maschine hat natürlich keinen echten Funk. Deshalb emuliert unser QEMU-Modell den gesamten nRF24L01+-Chip samt Registern und Warteschlangen und verpackt jeden gesendeten Frame in ein UDP-Datagramm. Die Datagramme fließen zu einem Relay, einem kleinen Programm, das jeden Frame an alle anderen Maschinen weiterreicht. Das ist der Funkkanal. Das Relay kann einen vorgegebenen Anteil der Frames verlieren, und wenn man es anhält, ist der Funkkanal ganz weg. In Cozystack, unserer offenen Plattform auf Basis von Kubernetes, wurde das Relay zu einer Katalog-Anwendung, OberonAir, und im Browser spielt die Seite selbst den Funkkanal.

Drei Nachrichten, jede in einem Frame

Das Protokoll, das ich KubeNet genannt habe, kennt nur drei Nachrichten. Jede geht an alle gleichzeitig, denn ein Funkgerät kann ohnehin keinen Empfänger auswählen, und jede passt in einen einzigen Frame.

Ein Node sendet einmal pro Sekunde seinen Heartbeat mit seinem Namen und den IDs der Pods, die gerade tatsächlich auf ihm laufen. Die Control Plane sendet jedem lebenden Node einmal pro Sekunde eine Zuweisung mit den Pods, die an diesen Node gebunden sind. Die dritte Nachricht, eine Spec, kommt ebenfalls von der Control Plane und teilt mit, welches Image der Pod mit einer bestimmten ID hat. Specs gehen eine pro Tick hinaus, noch nicht gestartete Pods zuerst.

Warum ein Frame und nicht eine Nachricht beliebiger Länge? SCC kann Pakete bis zu einem halben Kilobyte senden, indem es sie in Frames zerlegt, aber der Funkkanal hat keine Kollisionsvermeidung. Beginnen zwei Stationen gleichzeitig, lange Pakete zu senden, werden ihre Frames bei jedem Empfänger ineinander verschachtelt, und der Empfänger kann nicht mehr erkennen, welcher Frame zu wem gehört. Man könnte eine Arbitrierung für den Funkkanal erfinden, Warteschlangen und Neuübertragungen, aber genau auf diesem Weg sind Netzwerke bei der Komplexität angekommen, der ich entkommen wollte. Also passt jede Nachricht in einen Frame, und nach dem SCC-Header bleiben 24 Bytes Nutzdaten.

In einem Heartbeat und einer Zuweisung sind diese Bytes so aufgeteilt: das Cluster-Tag, sechs Bytes Node-Name, die Anzahl der Pods, bis zu zehn Pod-IDs zu je einem Byte, zwei Bytes Zähler und vier Bytes Signatur. Genau vierundzwanzig. Daher kommen alle seltsamen Grenzen von Kube: Ein Node-Name hat höchstens sechs Zeichen, eine Pod-ID belegt ein Byte, und ein Node betreibt höchstens zehn Pods, weil nicht mehr in einen Heartbeat passen und der Scheduler auch nicht mehr bindet.

Die wichtigste Eigenschaft des Protokolls ist, dass es level-triggered ist wie die Controller von Kubernetes, nur nicht innerhalb der Control Plane, sondern im Netzwerk selbst. Ein Node betreibt genau das, was seine letzte Zuweisung sagt, und nicht eine Folge von „start“- und „stop“-Befehlen. Geht eine Zuweisung verloren, kommt eine Sekunde später eine mit demselben Inhalt, es gibt also nichts zu reparieren. Geht ein Heartbeat verloren, wartet die Control Plane auf den nächsten. Es gibt keine Bestätigungen, keine Neuübertragungen und keine Sequenznummern für die Zuverlässigkeit: Die gesamte Zuverlässigkeit entsteht daraus, dass jede Nachricht den vollständigen Zustand trägt und nicht eine Änderung. Selbst auf einem Funkkanal, der 30 Prozent seiner Pakete verliert, hat sich in einer Minute kein einziger Pod bewegt, und das habe ich geprüft.

Ein Pod ist ein Modul

Im echten Kubernetes ist das Image eines Pods ein Dateisystem-Archiv mit einem Programm darin: Das Kubelet holt es aus einer Registry und startet es in einem isolierten Container. Oberon hat nichts dergleichen, aber es hat einen Mechanismus, der ähnlich und viel schneller funktioniert. Das Image eines Pods ist in Kube einfach der Name eines Oberon-Moduls auf dem Node.

Erfährt das Kubelet von einem neuen Pod, ruft es Modules.Load mit dem Namen des Images auf. Ist das Modul noch nicht geladen, sucht das System seine kompilierte Datei auf der Festplatte, lädt sie in den Speicher, bindet sie mit allen Modulen, die sie importiert, prüft die Schlüssel ihrer Schnittstellen und führt den Rumpf des Moduls aus. Ein Schlüssel ist eine Art Prüfsumme der Schnittstelle, die der Compiler in jedes Modul schreibt. Hat sich eine Schnittstelle geändert, weigert sich das System, Module zu laden, die gegen die alte Version kompiliert wurden. Dann sucht das Kubelet das Kommando Start des Moduls und ruft es auf, und wenn der Pod verschwinden soll, ruft es das Kommando Stop desselben Moduls auf.

Ein Kommando ist in Oberon jede exportierte Prozedur ohne Parameter. Man führt es aus, indem man mit der mittleren Maustaste auf den Text Module.Procedure in einem beliebigen Fenster klickt, und braucht es Parameter, liest es sie selbst aus dem Text hinter seinem Namen. Die ID eines Pods lässt sich also nicht direkt übergeben, und dafür gibt es ein winziges Modul, Pods, mit zwei Variablen, der ID und dem Image. Das Kubelet füllt sie vor dem Aufruf, und das Workload-Modul liest sie. Nicht die eleganteste Lösung, aber ganz im Geiste von Oberon: Eine globale Variable eines Moduls ist hier ein legitimer Weg, Kontext weiterzugeben, denn zu jedem Zeitpunkt läuft nur ein Kommando, und Race Conditions können gar nicht entstehen.

Den Lehr-Workload gibt es in zwei Versionen, Ticker und Ticker2. Für jeden gestarteten Pod führt er einen Sekundenzähler, und das Kommando Ticker.Show zeigt an, welche Pods auf dieser Maschine laufen und wie viele Sekunden jeder schon lebt. So lassen sich Rollouts gut beobachten: Im Log des Nodes sieht man, wie die Pods der ersten Version stoppen und die der zweiten starten.

Gibt es auf dem Node kein Modul dieses Namens, lässt sich Start nicht aufrufen, und das Kubelet lässt den Pod einfach aus seinem Heartbeat weg. Die Control Plane sieht, dass der Pod zugewiesen ist, aber nicht läuft, und er bleibt Pending. In Kubernetes sieht ein Pod genau so aus, dessen Image nicht gezogen werden konnte.

Der Store auf der Festplatte

In Kubernetes liegt der gesamte Zustand des Clusters in etcd, und eine neu gestartete Control Plane liest ihn von dort. In Kube übernimmt ein Array aus 256 Einträgen im Speicher der Control-Plane-Maschine die Rolle von etcd, und damit es einen Neustart übersteht, schreibt ein Hintergrund-Task es bei jeder Änderung auf die Festplatte.

Geschrieben wird abwechselnd in zwei Dateien, Kube.Store0 und Kube.Store1, jede mit einer Generationsnummer und einer Prüfsumme. Fällt mitten im Schreiben der Strom aus, ist nur eine Datei beschädigt, und die andere, aus der vorherigen Generation, bleibt erhalten. Beim Start liest Kube.Start beide und nimmt die neuere der unbeschädigten. Die Dateien werden an Ort und Stelle überschrieben statt neu angelegt, und auch das verlangt Oberon: Sein Dateisystem gibt den Platz ersetzter Dateien erst beim nächsten Booten frei, und würde man für jede Änderung eine neue Datei anlegen, liefe einem viel beschäftigten Cluster schlicht die Festplatte voll.

Nach einem Neustart gibt die Control Plane den Nodes ein Heartbeat-Timeout Zeit, sich zu melden, und beginnt erst danach, sie als NotReady zu zählen. Kubernetes macht es nach einem Neustart seines Node-Controllers genauso. Den Beginn dieses Timeouts musste ich übrigens verschieben, vom Moment, in dem der Store gelesen ist, auf den Moment, in dem die Control Plane anfängt, den Funkkanal abzuhören. In der Cloud hatte jemand es geschafft, zwischen diesen beiden Befehlen etwas über VNC einzutippen, das Timeout lief ab, und alle Pods zogen um, obwohl keiner gestoppt war.

Rollouts und zwei Bugs, die Kubernetes gut kennt

Das Kommando Kube.Apply web 6 Ticker2, abgesetzt auf ein laufendes web 6 Ticker, ändert das Image. Der Deployment-Controller legt ein neues ReplicaSet an und beginnt, Pods einen nach dem anderen umzuziehen. Zuerst kommt ein Pod mit dem neuen Image hinzu. Sobald sein Kubelet meldet, dass er läuft, gibt es einen Pod mehr als gewünscht, und das alte ReplicaSet entfernt einen der eigenen. Das wiederholt sich, bis das alte ReplicaSet leer ist, dann wird es gelöscht.

Das klingt einfach, aber unterwegs tauchten zwei Bugs auf, und beide erwiesen sich als alte Bekannte von Kubernetes.

Der erste betrifft das Stoppen eines Pods. Löscht die Control Plane einen Pod aus dem Store, läuft der Pod auf seinem Node weiter, bis das Kubelet die nächste Zuweisung hört, und das kann bis zu einer Sekunde dauern. Bis dahin sieht der Controller schon einen Pod weniger und fügt einen neuen hinzu. So liefen für einen Moment acht Pods, wo sieben erlaubt waren. Das echte Kubernetes verhält sich genauso, und erst kürzlich hat das Deployment das Feld podReplacementPolicy bekommen, mit dem es wartet, bis alte Pods vollständig gestoppt sind, und auch das ist noch Alpha, hinter einem Feature Gate. In Kube habe ich das zum einzigen Verhalten gemacht: Pods, die die Nodes noch melden, die aber nicht mehr im Store stehen, gelten als stoppend, und solange es welche gibt, kommt kein neuer Pod hinzu.

Der zweite Bug betrifft die Pod-IDs. Ein Node kennt einen Pod nur an seiner Ein-Byte-ID. Anfangs bekam ein neuer Pod die niedrigste freie ID, und das war oft genau die ID des alten Pods, den er gerade ersetzt hatte. Das Kubelet sah in der Zuweisung eine bekannte ID und schloss, es habe sich nichts geändert. Der Store behauptete, Ticker2 laufe, während auf dem Node weiter Ticker lief. Genau deshalb verwendet Kubernetes die UID eines Pods niemals wieder. Kubes IDs werden jetzt reihum vergeben, und die Prüfung nach jedem Rollout verlangt, dass keine ID eines alten Pods mehr läuft.

Die Ausfälle, für die es Cluster gibt

Ein Cluster existiert, um Ausfälle zu überstehen, und ich wollte das so testen, wie ich einen echten testen würde. Ein eigener Test startet eine Control Plane und zwei Nodes und beurteilt sie ausschließlich anhand des Funkkanals. Dafür tritt dem Relay ein passiver Lauscher bei: Er sendet nichts, sondern zeichnet nur jeden Heartbeat und jede Zuweisung auf und prüft ihre Signaturen. Kube selbst fragt der Test fast nichts: Nur das Ergebnis eines Rollouts wird mit dem verglichen, was Kube auf die Festplatte geschrieben hat, und alles andere wird danach beurteilt, was tatsächlich auf dem Funkkanal passiert ist.

Schaltet man einen Node ab, markiert die Control Plane ihn nach fünf Sekunden Funkstille als NotReady und verschiebt zwei Sekunden später seine Pods auf einen anderen Node, sodass das Ganze rund acht Sekunden dauert. Schaltet man die Control Plane ab, betreiben die Nodes weiter ihre letzte Zuweisung, weil niemand ihnen etwas anderes sagt. Bootet sie wieder, kommt der Store von der Festplatte zurück, und keine einzige Zuweisung ändert sich. Fehlt den Nodes das Modul, bleiben die Pods Pending. Und gehen eine ganze Minute lang 30 Prozent der Pakete verloren, bewegt sich kein einziger Pod.

Anfangs lag das Timeout bei drei Sekunden. Auf einem Funkkanal mit 30 Prozent Verlust fielen mehrmals pro Minute drei Heartbeats in Folge aus, und die Control Plane hielt den Node für tot und verschob Pods, die nie irgendwohin verschwunden waren. Mit fünf Sekunden wurden Fehlalarme dutzendfach seltener, und der Preis war eine langsamere Erholung von einem echten Ausfall. Kubernetes geht denselben Handel in einem anderen Maßstab ein: Das Kubelet meldet sich alle zehn Sekunden, und die Control Plane wartet vierzig bis fünfzig.

Am lehrreichsten war der Verlust des Funkkanals. Verstummt das Relay für zwanzig Sekunden, verstummen alle Nodes auf einmal. Eine Control Plane, die einfach ihren Timeouts vertraut, schließt daraus, dass die Nodes gestorben sind, und versucht, jeden Pod zu verschieben, obwohl es nirgendwohin zu verschieben gibt. Und wenn der Funkkanal zurückkommt, erwachen die Nodes einer nach dem anderen: Der erste, der zurück ist, bekommt die Pods aller anderen, der zweite holt sich einen Teil davon zurück und so weiter. In der ersten Version änderten zwanzig Sekunden Ausfall 74 Zuweisungen. Die Nodes arbeiteten die ganze Zeit weiter und bemerkten nichts, während der Cluster sich selbst eine Katastrophe inszenierte.

Kubernetes kennt diese Falle: Werden alle Nodes einer Zone gleichzeitig NotReady, versetzt der Node-Controller die Zone in den Zustand FullDisruption und hört auf, Pods zu evicten, mit der Überlegung, dass alle Nodes im selben Moment weit seltener sterben, als eine Verbindung abreißt. Kube macht dasselbe, wenn alle Nodes NotReady werden oder, bei drei und mehr, mindestens 55 Prozent. Auf Anhieb funktionierte es aber nicht: Es brauchte zwei Details, die erst bei einer fehlgeschlagenen Prüfung ans Licht kamen.

Erstens werden Nodes nicht im selben Moment NotReady; ihre Heartbeats liegen bis zu einer Sekunde auseinander. Der erste verstummte Node verlor also seine Pods, bevor die anderen verstummten und klar wurde, dass es sich um einen Ausfall handelte. Jetzt ziehen die Pods eines Nodes erst um, wenn er zwei Sekunden lang NotReady ist, und bis dahin sind auch alle anderen verstummt. Kubernetes wartet darauf standardmäßig fünf Minuten. Zweitens kommen Nodes auch einzeln zurück, und schon der erste zurückgekehrte holte den Cluster aus diesem Zustand, bevor die anderen sich gemeldet hatten, sodass deren Pods sofort umzogen. Jetzt bekommen die stummen Nodes nach dem Verlassen des Zustands noch ein weiteres Timeout, um sich zu melden, wie es auch Kubernetes macht, das die Timer der Nodes zurücksetzt, wenn eine Zone FullDisruption verlässt. Mit diesen beiden Korrekturen ändern zwanzig Sekunden Ausfall keine einzige Zuweisung.

Fremde auf dem Funkkanal

Einmal landeten in der Sandbox zwei Cluster auf demselben Funkkanal, und beide hatten einen Node gleichen Namens. Ein Node des einen Clusters startete und stoppte ständig seine Pods, weil er abwechselnd den Zuweisungen beider Control Planes gehorchte. Also kam an den Anfang jeder Nachricht ein Cluster-Tag, ein aus dem Namen des Clusters berechnetes Byte, und ein Node begann, Nachrichten mit fremdem Tag zu ignorieren.

Doch ein Tag beweist nichts; senden kann es jeder, also kam als Nächstes eine Signatur. Jede Nachricht trägt einen Authentifizierungscode, einen MAC, berechnet aus der Nachricht selbst und dem geheimen Schlüssel des Clusters, und ohne den Schlüssel lässt sich der richtige Code nicht erraten. Berechnet wird er mit HalfSipHash-2-4, einer reduzierten Variante von SipHash, die mit 32-Bit-Wörtern arbeitet und ein 32-Bit-Ergebnis liefert. HMAC-SHA256 kommt hier nicht in Frage: Wirths Prozessor ist 32-bittig und läuft mit 25 MHz, und von den 24 Bytes der Nachricht darf die Signatur höchstens vier belegen. HalfSipHash wurde genau für solche kleinen Geräte entwickelt und umfasst in Oberon rund dreißig Zeilen. Zweiunddreißig Bit sind für ernsthafte Kryptografie etwas knapp, aber für einen Lehr-Cluster ein ehrlicher Kompromiss.

Eine Signatur verhindert nicht, dass eine aufgezeichnete echte Nachricht erneut eingespielt wird, deshalb trägt jede Nachricht auch einen 16-Bit-Zähler, und der Empfänger verwirft alles, was nicht neuer ist als die letzte vom selben Absender angenommene Nachricht. Auch das prüft der Ausfalltest. Direkt nach einer echten Zuweisung schickt er dem Node im Namen eines Fremden „nichts betreiben“, und zwar auf drei Arten: mit dem Tag eines anderen Clusters, mit dem falschen Schlüssel signiert und als früher aufgezeichnete echte Zuweisung. Der Node ignoriert alle drei. Derselben Nachricht, ehrlich mit dem Schlüssel und einem frischen Zähler signiert, gehorcht er, und das ist der Kontrollfall, ohne den die Prüfung nichts beweisen würde.

Was es aushält

Ein eigener Lasttest startet eine Control Plane und zwei bis acht Nodes mit drei Pods pro Node und misst anhand des Funkkanals, wie schnell der Cluster konvergiert und wie schnell er sich vom Verlust eines Nodes erholt. Bei jeder Größe konvergiert er in rund drei Sekunden, und der Verlust eines Nodes kostet rund acht: fünf Sekunden Timeout, zwei Sekunden Pause vor der Eviction und bis zu einer Sekunde bis zur nächsten Zuweisung. Ein falsches NotReady gab es nie.

Eine Obergrenze hat der Cluster dennoch, und sie liegt nicht im Funk selbst, sondern in Wirths Treiber. Vor jedem Senden wartet SCC 50 Millisekunden, damit die Bestätigung eines anderen zu Ende gehen kann, und die Maschine tut währenddessen nichts anderes. Eine Station kann also höchstens zwanzig Nachrichten pro Sekunde senden. Die Control Plane braucht jede Sekunde eine Zuweisung pro Node, mit acht Nodes verbringt sie also fast die Hälfte ihrer Zeit mit Warten, während sich empfangene Frames im Puffer mit drei Plätzen stauen und die überzähligen verloren gehen. Während eines Rollouts kommen zu den Zuweisungen noch Specs hinzu, eine pro Tick, und das Warten nimmt fast die gesamte Zeit ein. Nach meiner Rechnung trägt das Protokoll im Leerlauf rund zwanzig Nodes und während eines Rollouts rund zehn. Das ist eine Rechnung anhand des Codes, keine Messung. Außerdem belegt jede Oberon-Maschine einen ganzen Kern des Hosts, weil ihre Schleife nie untätig ist, und acht Nodes auf einer Maschine belasten eher diese Maschine als den Funkkanal.

Zwei Bugs in unserem QEMU

Damit all das funktioniert, mussten zwei Bugs behoben werden, nicht in Kube, sondern in unserem Maschinenmodell für QEMU, und ohne den Cluster hätte ich keinen davon gefunden. Die Operation MOD nach einer Multiplikation lieferte manchmal die falsche Hälfte des Produkts, sodass die Prüfsumme des Stores immer null ergab. Der Hintergrund-Task sah darin keine Änderungen, und der Store wurde kein einziges Mal geschrieben. Und eine Maschine, die einmal ihr Relay verloren hatte, hörte den Funkkanal für immer nicht mehr, weil der UDP-Kanal von QEMU nach einem fehlgeschlagenen Lesen stillschweigend seinen Leser fallen ließ. Beide Funde sind im Repository beschrieben, und sie sind ein gutes Beispiel dafür, warum ich es so mag, echte Programme auf einem Emulator laufen zu lassen: Das Booten des Systems hat keinen der beiden Bugs ausgelöst.

Befehle beim Start und OberonKube

Der letzte Schritt diente dem Komfort, aber ohne ihn hätte alles andere seinen Sinn verloren. Niemand startet einen Cluster ein zweites Mal, wenn auf jeder Maschine Befehle über VNC eingetippt werden müssen. Jede Maschine sollte beim Start wissen, wer sie ist, so wie eine Cloud-VM ihre Rolle aus cloud-init erfährt.

QEMU nimmt jetzt eine Zeichenkette mit Befehlen entgegen, die die Maschine beim Start ausführen soll, und speist sie in die serielle Schnittstelle ein, als wären sie an einer Konsole getippt worden. Ein kleines Modul, Boot, liest die Zeichenkette und führt die Befehle nacheinander aus, jeden mit seinen Parametern. Aufgerufen wird es ganz am Ende des Rumpfs von System, dem Modul, das beim Systemstart geladen wird. System selbst wird aus den Quellen des Images mit genau dieser einen zusätzlichen Zeile neu gebaut, sodass seine Schnittstelle und der Schlüssel, den jedes andere Modul prüft, gleich geblieben sind.

Hier hat mir der Cluster noch eine Lektion erteilt. Die Befehle beim Start laufen bei jedem Booten, nicht nur beim ersten. Steht Kube.Apply web 4 Ticker darunter, kehrt das Deployment nach einem Neustart der Control Plane zu dem zurück, was die Befehle sagen, und ein inzwischen von Hand durchgeführter Rollout wird stillschweigend rückgängig gemacht. Ob das gut oder schlecht ist, hängt davon ab, was man als Source of Truth betrachtet. In der Cloud ist es das Bestellformular, und dorthin zurückzukehren ist dort genau das richtige Verhalten. Im Browser-Lab dagegen, wo ein Mensch eine neue Version von Hand ausrollt, war es ein Bug, und gefunden hat ihn übrigens das Lab selbst, nicht die QEMU-Tests. Für solche Fälle gibt es jetzt das Kommando Kube.Ensure, das ein Deployment nur anlegt, wenn es noch keines gibt.

In Cozystack kam all das in einer einzigen Katalog-Anwendung zusammen, OberonKube. Ein Benutzer gibt an, wie viele Nodes er braucht, den Cluster-Schlüssel und eine Liste von Deployments, und der Katalog legt den Funkkanal, die Control-Plane-Maschine und die Nodes an und gibt jeder Maschine die Befehle für ihre Rolle. Der Cluster bildet sich von selbst. Das Formular ist hier die Source of Truth: Eine geänderte Liste von Deployments greift beim nächsten Neustart der Control Plane. Die Maschinen eines Funkkanals versuchen außerdem, auf verschiedenen Hosts zu landen, damit der Verlust eines Hosts so wenige Nodes wie möglich kostet.

Was Oberon erzwungen hat

Wenn man Kubernetes in Go für Linux schreibt, kann fast jede Entscheidung in jede Richtung fallen. Braucht man eine Queue, sind Channels zur Hand; braucht man eine Datenbank, gibt es etcd; braucht man ein Netzwerk, gibt es gRPC über TCP; braucht man Isolation, gibt es Kernel-Namespaces. Es gibt immer eine Wahl, und deshalb fallen Entscheidungen oft aus Gewohnheit. Bei Oberon gibt es fast nichts zu wählen, und das ist der interessanteste Teil: Jede Grenze der Sprache und des Systems hat eine ganz bestimmte Entscheidung erzwungen, und diese Entscheidungen zeigen deutlich, welche Eigenschaften von Kubernetes aus seiner Idee selbst folgen und welche aus dem, worauf es gebaut wurde.

Ich teile die Grenzen in solche, die von der Sprache kamen, und solche, die vom Betriebssystem und der Maschine kamen, obwohl die Grenze dazwischen bei Wirth eine Konvention ist: Alles stammt aus einer Hand.

Was die Sprache erzwungen hat

Größen sind vorab bekannt. In Oberon-07 ist die Größe eines Arrays fast immer zur Compile-Zeit bekannt, und dynamischer Speicher wird nur für Records angelegt, die über Pointer erreicht werden. Ein Programm, in dem alles nach Bedarf wächst, ist in einer solchen Sprache umständlich zu schreiben, und ich habe es gar nicht erst versucht. Kubes Store ist ein Array aus 256 Objekten, ein Node hat höchstens zehn Pods, ein Node-Name höchstens sechs Zeichen, ein Image-Name höchstens fünfzehn, eine Pod-ID belegt ein Byte. Jede dieser Zahlen hat einen Grund, und alle stehen in zwei Konstantenblöcken am Anfang der Module Kube und KubeNet. Dadurch allokiert Kube in seiner Arbeitsschleife keinen Speicher, kann ihn bei einer Flut von Objekten nicht erschöpfen und verhält sich an seinen Grenzen vorhersehbar: Ein überzähliger Pod wird schlicht nicht angelegt. Auch das echte Kubernetes lebt mit Grenzen, etwa standardmäßig 110 Pods pro Node oder anderthalb Megabyte pro Objekt in etcd, aber dort sind sie über die Dokumentation verstreut, während sie sich hier nicht verstecken lassen.

Ganzzahlen sind 32-bittig, und nur Bytes sind vorzeichenlos. HalfSipHash arbeitet mit genau 32-Bit-Wörtern und erzeugt eine 32-Bit-Signatur, die in den Frame passt. Daher auch die Zählerarithmetik modulo 65.536 mit einer sorgfältigen Prüfung „ist diese Zahl neuer“, die auch nach einem Überlauf korrekt bleibt. Daher auch die Prüfsumme des Stores, die so berechnet wird, dass sie nicht vom Vorzeichen abhängt. Eine Kleinigkeit, aber genau dort ist der Bug mit MOD in unserem QEMU aufgetaucht.

Kommandos ohne Parameter. Eine exportierte Prozedur ohne Parameter gilt als Kommando, eine mit Parametern nicht. Das Kubelet kann also nicht Start(pod) aufrufen: Es legt die ID des Pods im Modul Pods ab und ruft Start ohne Argumente auf. In jeder anderen Sprache gälte das als schlechter Stil, aber hier gibt es keinen anderen Weg, und es ist sicher, weil immer nur ein Kommando läuft.

Module mit Schlüsseln. Jedes kompilierte Modul trägt den Schlüssel seiner Schnittstelle, und beim Laden prüft das System ihn gegen das, womit die importierenden Module kompiliert wurden. Das Image eines Pods ist in Kube also nicht nur ein Name, sondern ein Name mit eingebauter Kompatibilitätsprüfung. Wurde ein Workload-Modul gegen eine alte Version von Pods kompiliert, weigert sich das System, es zu laden, und der Pod bleibt Pending, statt mitten in der Arbeit abzustürzen. In der Container-Welt kommt dem ein gepinnter Image-Digest am nächsten, aber der garantiert nur, dass man genau diese Bytes bekommen hat, keineswegs, dass sie zu ihrer Umgebung passen.

Die Sprache ist klein. Das klingt nach einem Nachteil, diszipliniert in der Praxis aber mehr als alles andere. Oberon hat keine generischen Collections, keine Exceptions, keine Interfaces, keine Goroutinen und keine Reflection, also ist ganz Kube als schlichte Schleifen über Arrays geschrieben und als Prozeduren, die einen Wahrheitswert zurückgeben, statt etwas zu werfen. Es liest sich fast wie Pseudocode, und genau so wollte ich es haben.

Was das System und die Maschine erzwungen haben

Eine Schleife und kooperative Tasks. Das ist die wichtigste Grenze. Oberon hat keine Threads, also laufen Kubes Controller als Tasks in der zentralen Schleife, und auch das Kubelet auf einem Node ist ein Task. Jeder Task erledigt ein kurzes Stück Arbeit und kehrt zurück, und daraus folgen sofort drei Dinge. Erstens hat Kube keinen einzigen Lock, keinen Mutex und keinen Channel, denn Race Conditions können nicht entstehen: Solange ein Controller läuft, stehen die anderen still. Zweitens ist das Verhalten deterministisch: Bei gleicher Eingabe tun die Controller dasselbe in derselben Reihenfolge, und ein solches System ist weitaus leichter zu debuggen. Drittens, und das ist ein Minus, friert jeder Task, der lange nachdenkt, die ganze Maschine ein, Kubelet und Funk inklusive. Ein Pod, dessen Kommando Start in eine Endlosschleife gerät, legt den gesamten Node lahm.

Kein Speicherschutz. Alle Module leben in einem Adressraum, und das Einzige, was ein Modul davon abhält, den Speicher eines anderen zu beschädigen, ist eine streng typisierte Sprache mit Prüfung der Array-Grenzen. Für Kube bedeutet das, dass Pods in keiner Weise isoliert sind, weder voneinander noch vom Kubelet. Das ist der gravierendste Unterschied zum echten Kubernetes, und ich komme darauf zurück, wenn es darum geht, was Oberon fehlte.

Die Oberfläche ist Text. In Oberon ist jede Zeile der Form Module.Command in jedem Fenster ein Kommando. Kube hat deshalb keinen API-Server, kein YAML und kein kubectl. Seine API besteht aus Kommandos wie Kube.Apply web 6 Ticker2, Kube.Get und Kube.DeletePod, die ein Mensch in ein beliebiges Fenster schreibt und mit einem Mittelklick ausführt, das Ergebnis liest er im Systemlog. Dasselbe Prinzip hat die Befehle beim Start möglich gemacht: Die Rolle einer Maschine wird durch eine gewöhnliche Befehlszeile festgelegt, die QEMU in die serielle Schnittstelle einspeist, und das Modul Boot führt sie genau so aus, wie es ein Mensch täte. Ein spezielles Konfigurationsformat war nicht nötig; die Konfiguration einer Maschine wurde zum Text ihrer Befehle.

Ein Dateisystem alter Schule. Oberon gibt den Platz ersetzter Dateien erst beim nächsten Booten frei. Deshalb wird Kubes Store an Ort und Stelle überschrieben, abwechselnd in zwei Dateien, statt bei jeder Änderung neu angelegt, und das hat ihn zugleich gegen einen Stromausfall mitten im Schreiben geschützt. Eine Lösung, zu der Datenbanken vor Jahrzehnten gekommen sind, ergab sich hier von selbst, aus einer Beschränkung des Dateisystems.

Funk statt Netzwerk. Das habe ich schon ausführlich behandelt: ein 32-Byte-Frame, Broadcast an alle, keine Kollisionsvermeidung. Daraus folgt ein Protokoll aus Nachrichten mit je einem Frame, vollständiger Zustand statt Bestätigungen, ein Cluster-Tag und eine Signatur in jeder Nachricht. Und daraus folgt auch die unerwartetste Eigenschaft des ganzen Systems, um die es im nächsten Abschnitt geht: Alles, was der Cluster weiß, ist auf dem Funkkanal zu hören.

Fünfundzwanzig Megahertz. Die Geschwindigkeit der Maschine hat die Perioden bestimmt: Controller laufen alle 50 Millisekunden, das Kubelet alle 100, ein Heartbeat geht einmal pro Sekunde hinaus. Die Control Plane braucht sehr wenig echte Rechenarbeit, und fast ihre gesamte Zeit geht ins Warten. Doch leider ist auch das Warten nicht umsonst: Vor jedem Senden dreht der Funktreiber fünfzig Millisekunden lang eine Schleife, und genau dieses Warten, nicht die Rechenarbeit, begrenzt die Größe des Clusters.

Worin sich Kube von echtem Kubernetes unterscheidet

Damit keine Illusionen entstehen, hier ein kurzer Vergleich. Kube verkörpert die Idee von Kubernetes, nicht Kubernetes selbst, und der Unterschied zwischen beiden ist gewaltig.

Diese Tabelle zeigt, dass Kube für nichts taugt, wofür Kubernetes taugt. Sie zeigt aber noch etwas anderes: Die gesamte Logik, für die es Kubernetes gibt, also der Sollzustand, unabhängige Reconcile-Loops, Rollouts ohne Downtime, Erholung vom Verlust eines Nodes und Vorsicht bei einer abgerissenen Verbindung, passt in ein kleines System, das fast nichts von dem hat, was in der mittleren Spalte steht. Alles andere in Kubernetes ist dazu da, dass diese Logik auf Tausenden Maschinen funktioniert, für Tausende Benutzer und für Anwendungen, denen niemand vertraut. Sehr wichtige Dinge, aber nicht das Fundament.

Wo Kube besser wurde und wo Oberon versagte

Einen Spielzeug-Cluster auf Funk mit dem Kubernetes zu vergleichen, auf dem das halbe Internet läuft, wirkt unfair, und ich werde nicht behaupten, Kube sei besser. Mich interessiert etwas anderes: welche Qualitäten in Kube ganz von selbst entstanden sind, ohne jede Mühe, einfach weil es auf Oberon herangewachsen ist. Ich meine die Eigenschaften, die dem gewöhnlichen Kubernetes entweder fehlen oder für die es viel zu viel bezahlt. Ich habe sechs gezählt.

Der ganze Cluster lässt sich an einem Abend lesen

Die Control Plane umfasst rund achthundert Zeilen, das Netzwerkmodul mit Kubelet und Signaturen rund vierhundert, und mit dem Lehr-Workload und dem Modul für die Befehle beim Start kommt man auf rund vierzehnhundert. Darunter liegt nur noch das Oberon-System, das sich ebenfalls vollständig lesen lässt, und Wirths Prozessor in Verilog, für den ein paar Abende genügen. Der ganze Weg von „Ich will sechs Replikas von Ticker2“ bis zum Register des Funkchips, über das eine Zuweisung zu einem Node hinausfliegt, lässt sich also mit bloßem Auge verfolgen, ohne ein einziges Mal auf eine Bibliothek zu stoßen, die nie jemand gelesen hat.

Mit Kubernetes ist das schon lange nicht mehr möglich, und zwar nicht, weil es schlecht geschrieben wäre: Es löst eine riesige Zahl von Problemen, die Kube schlicht nicht hat. Am Ende weiß aber selbst ein erfahrener Engineer, der es seit Jahren betreibt, meist, wie es sich verhält, aber nicht, warum, und erfährt es erst während eines Ausfalls. In Kube steht die Antwort auf jedes „Warum“ in einer einzigen Prozedur.

Der Funkkanal ist die Observability

Diese Eigenschaft habe ich nicht geplant; sie ist von selbst entstanden, und sie gefällt mir am besten. Weil jede Nachricht an alle geht und den vollständigen Zustand statt einer Änderung trägt, ist auf dem Funkkanal in jedem Moment alles zu hören, was der Cluster über sich weiß: welche Nodes leben, was auf jedem läuft, was an jeden gebunden ist und welches Image jeder Pod hat. Ein passiver Lauscher, der nichts sendet, rekonstruiert das ganze Bild des Clusters, ohne ihm eine einzige Frage zu stellen.

Alle meine Prüfungen funktionieren so. Weder der Ausfalltest noch der Lasttest noch die Browser-Labs fragen jemals die Control Plane, was los ist. Sie hören den Funkkanal ab und vergleichen, was tatsächlich auf den Nodes lief, mit dem, was ihnen zugewiesen war. Ein Bug in Kube selbst kann eine solche Prüfung nicht täuschen, denn sie schaut nicht auf Kubes Berichte, sondern auf das Verhalten der Nodes. Im gewöhnlichen Kubernetes braucht man dafür Metriken, Logs, Audit, Exporter und ein eigenes System, das all das einsammelt, und trotzdem sieht man nur, was die Komponenten über sich selbst erzählen wollten.

Ein Pod startet im Handumdrehen

In Kubernetes heißt einen Pod starten: ein Image ziehen, Layer entpacken, Namespaces anlegen und einen Prozess starten, und das dauert Sekunden, bei kaltem Cache und großem Image sogar Minuten. In Kube heißt einen Pod starten: ein Oberon-Modul laden, falls es noch nicht geladen ist, und sein Kommando aufrufen, und ist das Modul bereits im Speicher, reduziert sich der Start eines Pods auf einen Prozeduraufruf. Der ganze Cluster konvergiert in drei Sekunden, und fast diese ganze Zeit geht ins Warten auf den nächsten Heartbeat, nicht in Arbeit.

Diese Geschwindigkeit wurde natürlich mit der Isolation bezahlt, der Vergleich ist also unfair. Aber er zeigt, wohin die Zeit tatsächlich geht. Wenn heute von Kaltstarts, von WebAssembly auf dem Server oder von V8-Isolates die Rede ist, geht es genau um diese Frage: Lässt sich eine Deployment-Einheit so klein und so modulartig machen, dass ihr Start so viel kostet wie ein Funktionsaufruf, ohne auf Isolation zu verzichten?

Kompatibilität wird beim Laden geprüft

Darüber habe ich im Abschnitt über die Prinzipien schon geschrieben, aber es lohnt sich, es zu wiederholen, denn es ist eine starke Idee. Das Image eines Pods ist in Kube ein Modul mit einem Schnittstellenschlüssel, und das System weigert sich, es zu laden, wenn es gegen eine inkompatible Version dessen kompiliert wurde, was es importiert. Ein Pod mit inkompatiblem Image stürzt nicht nach einer Stunde Arbeit bei einem unerwarteten Aufruf ab: Er startet einfach nicht, bleibt Pending, und das sieht man sofort. In der Container-Welt prüft niemand die Kompatibilität eines Images mit seiner Umgebung außer Ihren Tests, und die Kompatibilität von Images, die einander aufrufen, prüft bestenfalls ein API-Schema, und auch nur, wenn Sie eines haben.

Keine Locks und daher keine Race Conditions

Kubes Code hat keine Mutexe, keine Channels und keine atomaren Operationen. Controller, Kubelet, das Schreiben des Stores auf die Festplatte und der Empfang von Funkpaketen laufen alle als Tasks einer Schleife und werden streng nacheinander ausgeführt. Data Races, Deadlocks und Bugs, die einmal in tausend Durchläufen auftreten, können in Kube also gar nicht entstehen. Das Verhalten ist deterministisch: Führt man dasselbe Szenario zweimal aus, tun die Controller dasselbe in derselben Reihenfolge.

Die Kehrseite kommt etwas weiter unten, aber schon der Gedanke, dass eine Control Plane nicht multithreaded sein muss, scheint mir unterschätzt. Die Control Plane von acht Nodes braucht sehr wenig Rechenarbeit. Die Control Plane von tausend Nodes braucht natürlich mehr, aber auch dort geht der größte Teil der Zeit nicht ins Rechnen, sondern ins Warten auf Netzwerk und Festplatte, und Single-Threaded-Event-Loops haben längst bewiesen, dass sich solches Warten ohne Threads bedienen lässt.

Sicherheit ab der ersten Nachricht

Das frühe Kubernetes ließ standardmäßig vieles offen; das Kubelet etwa akzeptierte lange Zeit anonyme Anfragen, und solche Löcher zu schließen dauerte Jahre. In Kube kamen Signatur und Replay-Schutz, bevor der Cluster überhaupt etwas Nützliches konnte, einfach weil der Funk keine Wahl ließ: Auf dem Funkkanal kann jeder alles sagen, und das ist vom ersten Tag an offensichtlich. Die Signatur ist 32-bittig, was für die reale Welt zu wenig ist, aber architektonisch ist das Protokoll richtig: Jede Nachricht ist authentisch und gehört zu ihrem Cluster, und die Prüfung kostet rund dreißig Zeilen.

Der ganze Cluster in einem Browser-Tab

Und die letzte, nicht über die Architektur, sondern über das, was aus ihr folgt. Eine Oberon-Maschine ist so klein, dass drei von ihnen samt Funkkanal in einen Browser-Tab passen. Alles, was ich beschreibe, lässt sich also nicht nur lesen, sondern ohne jede Installation nachvollziehen: einen Node abschalten, den Funk stören, eine gefälschte Zuweisung einschleusen. Für Kubernetes gibt es gute Lern-Sandboxes, aber das ist immer jemandes Cluster irgendwo in einer Cloud, während der Cluster hier auf Ihrem Rechner lebt und sich nach Belieben kaputtmachen lässt, ohne jemanden zu stören.

Was Oberon fehlte

Nun dazu, wo Oberon zu eng war und warum solche Systeme höchstwahrscheinlich verloren haben. Für die Forschung ist dieser Teil nicht weniger wichtig.

Isolation. Das ist der Hauptpunkt. In Oberon leben alle Module in einem Adressraum und vertrauen einander. Ein Pod, der über SYSTEM.PUT Speicher beschädigt, beschädigt damit auch das Kubelet, den Funk und alles andere. Ein Pod, der in eine Endlosschleife gerät, friert den ganzen Node ein, weil ein kooperativer Task, der nicht zurückkehrt, das gesamte System anhält. Solange auf der Maschine Code eines einzigen Autors läuft, der diesem Code vertraut, ist alles gut, und genau so hat Wirth sein System entworfen: für einen Menschen an einem Computer. Ein Cluster existiert aber gerade dazu, fremden Code auszuführen, und ohne Isolation ist das unmöglich. Kubernetes auf Linux bekommt die Isolation vom Kernel, Oberon dagegen bräuchte dafür Speicherschutz im Prozessor, präemptives Multitasking und Ressourcen-Accounting, müsste also ein ganz anderes System werden.

Präemption. Neben der Isolation kann die Control Plane weder einen Pod unterbrechen, der zu lange rechnet, noch die Prozessorzeit unter den Pods aufteilen. Keine Quotas, keine Prioritäten, keine Limits, nur gute Manieren. Einem Lehr-Workload, der einmal pro Sekunde einen Zähler um eins erhöht, ist das egal, aber jeder echte Workload stolpert sofort darüber.

Ein Netzwerk. Funk mit 32-Byte-Frames eignet sich hervorragend zur Steuerung, aber für Anwendungsdaten ist darin kein Platz. Kubes Pods haben keine Adressen, keine Services und keine Möglichkeit, miteinander zu sprechen. Über Wirths Funk lassen sich Dateien verschicken, aber das wäre eher ein USB-Stick als ein Netzwerk.

Flexible Größen. Die Grenzen, die ich für ihre Vorhersehbarkeit gelobt habe, werden zur Obergrenze: zehn Pods pro Node, 256 Objekte im Store, sechs Zeichen pro Name und zwanzig Nachrichten pro Sekunde und Station. Jede dieser Obergrenzen lässt sich anheben, aber nicht beliebig, denn alle folgen aus dem 24-Byte-Frame, statischen Arrays und einem einfachen Treiber. Kubernetes hat dafür, keine solchen Obergrenzen zu haben, mit enormer Komplexität bezahlt, und mit Blick auf Kube versteht man, dass dieser Preis bewusst gezahlt wurde.

Eine hochverfügbare Control Plane. Kube hat eine einzige Control-Plane-Maschine. Stirbt sie endgültig samt ihrer Festplatte, steht der Cluster ohne Master da. Die Nodes betreiben weiter ihre letzte Zuweisung, was eine gute Eigenschaft ist, aber die Control Plane lässt sich nicht durch eine andere Maschine ersetzen, weil es keinen konsistenten Store über mehrere Maschinen gibt. Raft lässt sich in Oberon schreiben, aber über einen Funk ohne Zustellgarantien und mit 32-Byte-Frames wäre das ein großes Forschungsvorhaben für sich.

Mehrere Benutzer. Oberon hat einen Benutzer, Kube einen Schlüssel pro Cluster. Keine Namespaces, keine Rollen, keine Rechtetrennung, und wer den Schlüssel kennt, kann alles. Kubernetes verwendet den größten Teil seiner Komplexität genau darauf, dass viele Menschen und Teams sich einen Cluster sicher teilen können, während Kube eine solche Schicht überhaupt nicht hat.

Nimmt man all diese Punkte zusammen, wird klar, dass Oberon nicht verloren hat, weil es schlecht entworfen war, sondern weil es für eine andere Welt entworfen wurde, in der ein Computer einem Menschen gehört, der gesamte Code darauf von diesem Menschen oder von Leuten seines Vertrauens geschrieben ist und ein Netzwerk eine Möglichkeit ist, dem Nachbarn eine Datei zu geben. Sobald Computer geteilt wurden und Code fremd wurde, brauchte man Isolation, Präemption und Rechte, und einfache Systeme mussten komplexen weichen.

Sechs Labs in Ihrem Browser

Anfangs bezweifelte ich, dass sich der Cluster überhaupt im Browser betreiben lässt. Die Oberon-Maschine aus den Labs des vorigen Artikels lief bereits in einem Tab: Es ist Wirths tatsächliche Schaltung, nach C++ übersetzt und zu WebAssembly kompiliert. Aber sie hatte keinen Funk, und ein Cluster braucht drei Maschinen, die einander hören. Also bekam die Browser-Maschine dasselbe Modell des nRF24L01+-Transceivers wie die QEMU-Maschine und lernte, die von ihr gesendeten Frames nach außen zu geben und die Frames anderer Maschinen entgegenzunehmen. Jede Maschine läuft in einem eigenen Hintergrund-Thread, und die Seite nimmt ihre Frames und reicht sie an die anderen weiter, die Seite selbst ist also der Funkkanal. Sie kann außerdem einen vorgegebenen Anteil der Frames verlieren, eine einzelne Maschine vom Funkkanal trennen und Kubes Nachrichten samt Prüfung ihrer Signaturen lesen, weshalb rechts eine aus dem Funkverkehr aufgebaute Cluster-Tabelle erscheint.

Auch eine serielle Schnittstelle war nötig, damit die Maschinen ihre Rollen beim Einschalten erfahren, wie in der Cloud. Die Control Plane erhält die Befehle Kube.Start, KubeNet.Serve kube 00c0ffee00c0ffee und Kube.Ensure web 4 Ticker, die Nodes KubeNet.Join mit ihren Namen, sodass nichts eingetippt werden muss. Kube.Ensure steht dort nicht zufällig, aber dazu mehr im sechsten Lab.

Die Geschwindigkeit wurde zu einer eigenen Aufgabe. In WebAssembly führt Wirths Schaltung weniger als eine Million Instruktionen pro Sekunde und Maschine aus, also dutzendfach langsamer als das 25-MHz-Board. Kube zählt die Zeit dagegen in Maschinensekunden: ein Heartbeat pro Sekunde, ein Timeout von fünf. Hätte ich die Uhren der Maschinen ehrlich gehen lassen, bräuchte der Cluster mehrere Minuten, um sich zu bilden, und das Lab mit einem abgeschalteten Node dauerte rund fünf Minuten. Deshalb lässt die Seite die Uhren der Maschinen zehnmal schneller laufen als ihre Instruktionen, und die Maschinen glauben, sie liefen mit 2,5 MHz. Ihre Sekunden vergehen in einem Tempo, dem das Auge folgen kann, und dem Protokoll ist es egal: Es hat keine Ahnung, wie viele Instruktionen in eine Sekunde passen.

Hintergrund-Tabs hielten eine weitere unerwartete Falle bereit: Der Browser bremst Timer dort stark aus, und der Cluster fror fast ein. Deshalb drehen die Maschinen jetzt ihre eigene Schleife und hängen nicht von den Timern der Seite ab. Die letzte Falle war die Eingabe. Die Seite tippt einen Befehl mit Tasten und Mausklicks in eine Maschine, und anfangs tat sie das in einem Rutsch. Das sind rund elf Millionen Instruktionen, mit der schnellen Uhr also über vier Sekunden Maschinenzeit, in denen die Maschine den Funkkanal nicht hört. Nach jedem Tastendruck erklärte die Control Plane beide Nodes für NotReady, und gerettet hat sie nur, dass Evictions in FullDisruption ausgesetzt werden. Jetzt geht die Eingabe in kleinen Portionen hinein, abwechselnd mit der Arbeit der Maschine, und dazwischen wird der Funkverkehr zugestellt.

Jedes Lab prüft sich selbst und zeigt einen Haken, wenn das Beschriebene tatsächlich auf dem Funkkanal passiert ist. Einen Knopf zu drücken und einen Haken zu bekommen, funktioniert nicht: Die Prüfung schaut auf Heartbeats und Zuweisungen, nicht darauf, was Sie getan haben.

Lab öffnen

1. Der Cluster bildet sich von selbst

Nichts zu tun außer warten. Die Maschinen booten, und auf dem Bildschirm der Control Plane sieht man, wie das Modul Boot die Befehle ausführt, die über die serielle Schnittstelle gekommen sind. Kube installiert drei Controller, beginnt den Funkkanal abzuhören und legt das Deployment web mit vier Pods an, und ein paar Sekunden später erscheinen im Log die Zeilen „node node1 Ready“ und „node node2 Ready“.

Unterdessen zeigen die Nodes, wie das Kubelet seine Zuweisung empfängt und die Pods des Moduls Ticker startet.

Rechts auf der Seite füllt sich die Cluster-Tabelle. Für jeden Node zeigt sie, wann er zuletzt gehört wurde, welche Pods er nach eigener Aussage betreibt und welche an ihn gebunden sind. Unterscheiden sich diese beiden Spalten, ist der Cluster noch nicht konvergiert, oder etwas ist schiefgegangen.

2. Neuen Code ausrollen

Drücken Sie den Knopf web 4 Ticker2. Die Seite tippt Kube.Apply web 4 Ticker2 ~ auf der Control Plane und führt es mit einem Mittelklick aus, wie es ein Mensch täte. Kube legt ein neues ReplicaSet an und beginnt, Pods einen nach dem anderen umzuziehen. Die Prüfung lässt den Rollout gelten, wenn jeder Pod das neue Image betreibt, und nur dann, wenn die Zahl der Pods während der ganzen Zeit nie unter vier fiel und nie über fünf stieg. Gezählt wird anhand der Heartbeats, also anhand dessen, was die Nodes tatsächlich betrieben haben.

Ist der Rollout abgeschlossen, drücken Sie auf einem Node Ticker2.Show, und er zeigt die neue Version beim Zählen. Die ganze Geschichte steht im Log des Nodes: Die Pods von Ticker v1 wurden gestoppt, die von Ticker v2 gestartet, und die neuen Pods haben andere IDs als die alten.

3. Ein Node stirbt

Drücken Sie Power off über dem Bildschirm eines Nodes, der Pods betreibt. Sein Bildschirm wird dunkel, seine Heartbeats verstummen, und nach fünf Maschinensekunden markiert die Control Plane den Node als NotReady und verschiebt zwei Sekunden später seine Pods auf den verbliebenen. Schalten Sie den Node wieder ein, bootet er, tritt dem Funkkanal bei und wird Ready, aber seine Pods gibt ihm niemand zurück: Wie der echte Scheduler verschiebt Kube laufende Pods nicht auf einen Node, der später hinzugekommen ist. Neue Pods aus einem Hochskalieren landen dagegen auf ihm, als dem am wenigsten ausgelasteten Node.

4. Der Funkkanal stirbt

Drücken Sie Switch the air off und warten Sie eine halbe Minute. Alle Nodes werden gleichzeitig NotReady, aber Kube schließt daraus, dass die Verbindung abgerissen ist und nicht die Nodes ausgefallen sind, und verschiebt nichts. Schalten Sie den Funkkanal wieder ein, und ein paar Sekunden später laufen dieselben Pods auf denselben Nodes. Das Lab gilt nur als bestanden, wenn sich während des Ausfalls und danach keine einzige Zuweisung geändert hat.

Am interessantesten ist es hier, unter dem Lab „what is going on“ aufzuklappen und von den 74 Neuzuweisungen zu lesen, die die erste Version in zwanzig Sekunden Ausfall vorgenommen hat. Und wenn Sie mögen, schalten Sie den Funkkanal für ein paar Sekunden ab, kürzer als das Timeout, und sehen Sie, dass überhaupt nichts passiert.

5. Ein Eindringling

Der Abschnitt „An intruder on the air“ hat vier Knöpfe. Jeder schickt im Namen eines Fremden die Zuweisung „nichts betreiben“ an den Node, der Pods betreibt, und zwar direkt nach einer echten Zuweisung der Control Plane, damit die Fälschung das Letzte ist, was der Node gehört hat. Der erste Knopf versieht sie mit dem Tag eines anderen Clusters, der zweite signiert sie mit dem falschen Schlüssel, der dritte spielt eine früher aufgezeichnete echte Zuweisung erneut ein. Der Node ignoriert alle drei und betreibt seine Pods weiter.

Der vierte Knopf signiert die Fälschung mit dem echten Cluster-Schlüssel und einem frischen Zähler. Das ist der Kontrollfall, und der Node gehorcht und stoppt seine Pods. Ohne ihn würde das Lab nichts beweisen: Vielleicht hört der Node ja einfach auf niemanden außer der Control Plane? Eine Sekunde später sendet die Control Plane ihre nächste Zuweisung, und die Pods kommen zurück, weil das Protokoll den vollständigen Zustand trägt und keine Befehle.

Die Fälschungen sind übrigens auch im Funk-Log zu sehen: Die Seite prüft die Signaturen selbst und markiert Nachrichten mit fremdem Tag oder ungültiger Signatur.

6. Die Control Plane startet neu

Schalten Sie die Control Plane ab und ein paar Sekunden später wieder ein. Sie bootet, führt ihre Befehle erneut aus, liest ihren Store von der Festplatte, und kein einziger Pod bewegt sich. Die Nodes haben die ganze Zeit ihre letzte Zuweisung betrieben, und die zurückgekehrte Control Plane hat ihnen ein Timeout Zeit gegeben, sich zu melden, und das haben sie alle getan.

Genau dieses Lab hat den letzten Bug vor der Veröffentlichung gefunden. In den Befehlen beim Start stand zuerst Kube.Apply web 4 Ticker, und nach einem Neustart kehrte das Deployment zu Ticker zurück und machte den Rollout aus dem zweiten Lab rückgängig. Die QEMU-Tests haben das nicht bemerkt, weil sie die Control Plane vor jedem Rollout neu gestartet haben. Hier, wo ein Mensch eine neue Version von Hand ausrollt, ist es richtig, das Getane zu bewahren, deshalb steht in den Befehlen jetzt Kube.Ensure, das ein Deployment nur anlegt, wenn es noch keines gibt. In der Cloud ist dagegen das Bestellformular die Source of Truth, und dort ist Kube.Apply geblieben.

Was Sie sonst noch ausprobieren können

Die Seite kann mehr als die Labs. Mit dem Verlust-Schieberegler können Sie den Funkkanal verschlechtern, etwa 30 Prozent der Frames verlieren lassen, und sehen, dass die Pods sich nirgendwohin bewegen. Treiben Sie die Verluste deutlich höher, fallen früher oder später fünf Heartbeats in Folge aus, und Kube hält einen lebenden Node für tot; das ist der Preis eines Timeouts. Cut off the air isoliert eine Maschine, ohne sie abzuschalten, und Sie können zusehen, wie der abgeschnittene Node seine Pods weiter betreibt, obwohl die Control Plane sie bereits anderen übergeben hat. Das ist genau der Fall eines Pods, der an zwei Orten läuft, und Kubernetes lebt damit auf genau dieselbe Weise. Im Befehlsfeld können Sie jedes Oberon-Kommando eingeben, zum Beispiel Kube.Apply api 2 Ticker ~, um ein zweites Deployment anzulegen, oder Sie klicken direkt in den Bildschirm einer Maschine und arbeiten darin von Hand. Die mittlere Maustaste ist dort ein Klick mit Alt.

So probieren Sie es selbst aus

Es gibt vier Wege, vom ganz einfachen, bei dem nichts installiert werden muss, bis zur eigenen Cloud. Alles Folgende ist offen: Der Quellcode liegt im Repository tym83/paleocomputing, Kubes Code im Ordner impl/kube, eine ausführliche Beschreibung mit Messungen in impl/kube/README.md.

Im Browser

Öffnen Sie das Cluster-Lab und warten Sie eine halbe Minute. Installieren müssen Sie nichts: Alles läuft im Tab, der Server liefert nur Dateien aus. Am wohlsten fühlt sich die Seite in einem aktuellen Chrome oder Firefox auf einem Rechner mit mehreren Kernen, denn jede der drei Maschinen belegt einen eigenen Kern. Lassen Sie den Tab im Vordergrund: Im Hintergrund bremst der Browser ihn aus, und der Cluster bleibt zwar nicht stehen, lebt aber spürbar langsamer.

Um dieselbe Seite lokal zu betreiben, klonen Sie das Repository, starten im Ordner impl/web einen beliebigen statischen Server, zum Beispiel python3 -m http.server 8765, und öffnen http://127.0.0.1:8765/kube.html. Und wenn Sie gar keinen Browser brauchen, läuft derselbe Cluster aus drei Maschinen in Node.js mit node impl/web/kube-test.mjs. Er bootet drei Maschinen auf Wirths tatsächlicher Schaltung, wartet, bis sich der Cluster gebildet hat, und prüft anhand des Funkkanals, dass alle Pods laufen und alle Signaturen gültig sind. Die Uhren der Maschinen gehen hier ehrlich, deshalb dauert es rund eine Minute.

In QEMU auf Ihrem Rechner

Sie brauchen Docker, git und make. Bauen Sie zuerst unser Maschinenmodell für QEMU. Der Build läuft in einem Container, sodass die Abhängigkeiten von QEMU Ihrem System fernbleiben, dauert aber rund zehn Minuten:

git clone https://github.com/tym83/paleocomputing
cd paleocomputing
make -C qemu build

Die Systemplatte, auf der Kube, KubeNet, der Lehr-Workload und das Modul für die Befehle beim Start bereits kompiliert liegen, nehmen Sie am einfachsten aus dem veröffentlichten Image. Jede Maschine braucht ihre eigene Kopie der Platte, vergrößert auf acht Megabyte, damit das System Platz hat, seinen Store zu schreiben:

docker create --name payload ghcr.io/tym83/paleocomputing/oberon-run:v0.1.21
docker cp payload:/opt/oberon/payload/prom.bin .
docker cp payload:/opt/oberon/payload/oberon.dsk .
docker rm payload
for m in plane node1 node2; do cp oberon.dsk $m.dsk; truncate -s 8M $m.dsk; done

Als Nächstes brauchen Sie den Funkkanal, also ein Docker-Netzwerk mit einem Relay darin:

docker network create kube-air
docker run -d --name relay --network kube-air -v "$PWD/qemu/radio:/r" \
  qemu-build:risc5 'python3 -u /r/relay.py'

Und schließlich drei Maschinen, jede mit ihren Befehlen beim Start. Die Zeichenkette nach commands= ist genau das, was die Maschine nach dem Booten ausführt, die Befehle durch Semikolons getrennt:

run() {
  docker run -d --name $1 --network kube-air -p 127.0.0.1:$2:5900 \
    -v "$PWD/.qemu-work:/src:ro" -v "$PWD:/w" -w /w qemu-build:risc5 \
    "/src/build/qemu-system-risc5 -machine 'oberon,radio=air,commands=$3' \
     -bios prom.bin -drive if=none,id=sd0,file=$1.dsk,format=raw -vnc :0 \
     -chardev udp,id=air,host=relay,port=7524,localaddr=0.0.0.0,localport=7524"
}
KEY=00c0ffee00c0ffee
run plane 5900 "Kube.Start;KubeNet.Serve kube $KEY;Kube.Apply web 4 Ticker"
run node1 5901 "KubeNet.Join node1 kube $KEY"
run node2 5902 "KubeNet.Join node2 kube $KEY"

Hier steht Kube.Apply und nicht Kube.Ensure wie im Browser-Lab: Release v0.1.21 kennt Kube.Ensure noch nicht. Der Unterschied zeigt sich nur, wenn Sie eine neue Version von Hand ausrollen und die Control Plane neu starten: Mit Kube.Apply kehrt das Deployment zu dem zurück, was die Befehle sagen.

Die Bildschirme der Maschinen liegen auf den VNC-Ports 5900, 5901 und 5902. Das Booten in Software-Emulation dauert bis zu einer Minute, danach zeigt das Log der Control Plane Zeilen über bereite Nodes und die Logs der Nodes Zeilen über gestartete Pods. Die Maus von Oberon hat drei Tasten, und die mittlere führt das Kommando aus, auf das sie zeigt. Kube.Get in einem beliebigen Fenster der Control Plane zeigt also alle Objekte, und Ticker.Show auf einem Node zeigt seine Pods. Um eine neue Version auszurollen, schreiben Sie Kube.Apply web 4 Ticker2 ~ auf der Control Plane und klicken mit der mittleren Taste auf diese Zeile.

Den Funkkanal können Sie von der Seite abhören, so wie es die Tests tun. Der Lauscher tritt dem Relay als weitere Maschine bei, sendet nichts und gibt mit --json jeden Heartbeat und jede Zuweisung aus, samt der Angabe, ob die Signatur gültig ist:

docker run --rm -it --network kube-air -v "$PWD/qemu/radio:/r" \
  qemu-build:risc5 'python3 -u /r/listen.py relay --json --key 00c0ffee00c0ffee'

Und dann können Sie Dinge kaputtmachen. docker stop node2 schaltet einen Node ab, docker stop relay legt den Funkkanal lahm, und docker start bringt beides zurück. Bekommt das Relay nach einem Neustart eine andere Adresse, finden die Maschinen es selbst: Nach einem fehlgeschlagenen Senden löst unser Modell die Adresse erneut über den Namen auf. Im selben Ordner liegt inject.py, das den Eindringling spielen kann.

Die Prüfungen im Repository starten den Cluster genau auf diese Weise, nur automatisch. Nachdem Sie QEMU und die Werkzeuge mit make -C impl tools gebaut haben, können Sie sie selbst ausführen: python3 qemu/test/kube_dr_check.py prüft alle oben besprochenen Ausfälle (ihre Tabelle steht in impl/kube/README.md), python3 qemu/test/kube_boot_check.py prüft, dass sich der Cluster allein aus den Befehlen beim Start bildet, und python3 qemu/test/kube_load_check.py --nodes 4 misst die Last. Diese Prüfungen bauen die Platte aus den Quellen, haben also bereits Kube.Ensure. Bedenken Sie, dass jede Oberon-Maschine einen ganzen Kern belegt, weil ihre Schleife nie untätig ist, und acht Nodes auf einem Laptop eher den Laptop messen als den Cluster.

Wenn Sie fertig sind, entfernen Sie die Container mit docker rm -f plane node1 node2 relay und das Netzwerk mit docker network rm kube-air.

In Ihrem eigenen KubeVirt

Eine Oberon-Maschine läuft auch in einfachem KubeVirt, ohne Cozystack. Sie braucht dafür unser virt-launcher-Image, das die Architektur RISC5 kennt, und die eingeschaltete Fähigkeit von KubeVirt, Hooks an virtuelle Maschinen anzuhängen. Wie das geht, beschreibt ausführlich der Guide, der auch eine Beispiel-VirtualMachine enthält. Ein Cluster braucht drei solcher Maschinen, ein Relay als gewöhnlichen Pod mit einem UDP-Service und die Befehle beim Start in der Annotation der Maschine, die der Hook an QEMU weiterreicht. Genau das erledigt der Cozystack-Katalog für Sie, ohne Cozystack ist es daher am einfachsten, sich anzusehen, was seine Charts im Ordner marketplace anlegen.

In Cozystack

Wenn Sie Cozystack haben, binden Sie unseren Katalog einmalig mit cozypkg ein:

cozypkg tap oci://ghcr.io/tym83/paleocomputing/machines:v0.1.21
cozypkg add paleocomputing.machines

Der Cluster-Administrator muss dafür zwei Dinge tun: das Feature Gate Sidecar in KubeVirt einschalten und unser virt-launcher-Image für Ihre KubeVirt-Version installieren. Die Details stehen auf der Projektseite.

Danach sehen Benutzer im Dashboard einen Abschnitt Paleocomputing, darin unter anderem OberonVM, OberonAir und OberonKube. Ein Kube-Cluster wird mit einem Formular oder einer Ressource bestellt:

apiVersion: apps.cozystack.io/v1alpha1
kind: OberonKube
metadata:
  name: farm
spec:
  nodes: 3
  key: 00c0ffee00c0ffee
  deployments: web 4 Ticker; api 2 Ticker2

Aus dieser Bestellung legt der Katalog einen Funkkanal, eine Control-Plane-Maschine und drei Nodes an, und der Cluster bildet sich von selbst. Den Bildschirm jeder Maschine öffnen Sie mit virtctl vnc unter den eigenen Rechten des Tenants, und die Namen der Maschinen stehen im Dashboard. Source of Truth ist hier das Formular: Seine Deployments werden bei jedem Start der Control Plane angewendet, ein geändertes Formular greift also nach einem Neustart, und eine über VNC vorgenommene Änderung hält nur bis dahin. Wird die Bestellung gelöscht, werden auch alle ihre Bestandteile gelöscht.

Sie können einen Cluster auch von Hand aus einzelnen Maschinen bauen. Legen Sie dann einen OberonAir an und tragen Sie in jeder OberonVM diesen Funkkanal im Feld air ein, die Rolle in kubeRole (plane für die Control Plane und node für die Nodes), den Node-Namen in kubeNode und denselben Schlüssel in kubeKey. Die Deployments der Control Plane gehören ins Feld commands, und der Cluster-Name, falls er nicht kube sein soll, in kubeCluster. Das macht mehr Spaß, wenn Sie zum Beispiel zwei Cluster mit unterschiedlichen Schlüsseln auf einen Funkkanal setzen und zusehen wollen, wie sie einander nicht in die Quere kommen.

Was all das über die Infrastruktur von morgen sagt

Am Anfang habe ich erwähnt, dass dies auch Forschung ist und nicht nur ein Scherz, also will ich versuchen, in Worte zu fassen, was mich der Cluster auf Wirths Funk gelehrt hat. Nicht in dem Sinne, dass alle Kubernetes in Oberon neu schreiben sollten, sondern in dem Sinne, welche Ideen es wert sind, aus diesem kleinen System in ein großes mitgenommen zu werden.

Zustand statt Ereignisse. Innerhalb seiner Control Plane arbeitet Kubernetes schon lange nach dem level-triggered Prinzip, aber zwischen den Komponenten gibt es nach wie vor Events, Watches, Änderungsströme und langlebige Verbindungen. Kube ist weiter gegangen, schlicht weil der Funk ihm keine Wahl ließ: Jede Nachricht trägt den vollständigen Zustand, und das Protokoll braucht keine Bestätigungen, keine Wiederholungen und keine Wiederherstellung nach einer abgebrochenen Verbindung. Ich glaube, dieser Ansatz ist weit breiter anwendbar, als gemeinhin angenommen wird. Überall dort, wo sich der Zustand knapp genug beschreiben lässt und das Netzwerk unzuverlässig ist, ob Edge-Netze, Satellitenverbindungen, Industrienetze oder Cluster aus Tausenden kleiner Geräte, erweist sich ein Protokoll, in dem jede Nachricht für sich steht, als zugleich einfacher und zuverlässiger.

Observability als Eigenschaft des Protokolls. Weil auf dem Funkkanal alles zu hören ist, was der Cluster über sich weiß, musste ich keine Observability bauen. In einem großen System kann man natürlich nicht alles an alle senden, aber schon der Gedanke, dass man die Nachrichten zwischen den Komponenten beobachten sollte und nicht die Berichte der Komponenten über sich selbst, scheint mir interessant. Eine Prüfung, die auf das Verhalten der Nodes schaut und nicht darauf, was die Control Plane über sie denkt, fängt die eigenen Bugs der Control Plane ein, und so wurden fast alle Bugs von Kube gefunden.

Eine Deployment-Einheit in Modulgröße. Ein Oberon-Modul mit Schnittstellenschlüssel kommt dem sehr nahe, wohin sich WebAssembly gerade mit seinem Komponentenmodell bewegt: ein kleines Stück Code mit explizit beschriebener Schnittstelle, das sich schnell laden und vor der Ausführung auf Kompatibilität prüfen lässt. Oberon fehlte die Isolation, und WebAssembly liefert sie ohne separaten Prozess oder Kernel. Bringt man beides zusammen, erhält man einen Pod, der startet wie ein Funktionsaufruf, isoliert ist wie ein Container und dessen Kompatibilität beim Laden geprüft wird, wie in Oberon. Ich halte es für gut möglich, dass die Infrastruktur von morgen auf solchen Prinzipien aufgebaut wird.

Grenzen, die im Code stehen. Alle Obergrenzen von Kube stehen in zwei Konstantenblöcken, und jede hat einen Grund. Auch Kubernetes hat Grenzen, aber sie sind über Flags, Dokumentation und Betriebserfahrung verstreut, und von vielen erfährt man erst, wenn man an sie stößt. Ich wünschte mir, große Systeme würden ihre Grenzen und deren Gründe ehrlicher deklarieren, statt so zu tun, als gäbe es keine.

Einfachheit, die in einen Kopf passt. Kube lässt sich an einem Abend lesen, und das ist keine Zierde, sondern eine Arbeitseigenschaft: Wenn etwas schiefging, fand ich die Ursache, indem ich eine Prozedur las, nicht indem ich Issues in einem Tracker durchging. So wird Kubernetes nie wieder sein, aber neue Systeme lassen sich so entwerfen, dass ihr Kern, der Teil, der für die Hauptidee zuständig ist, überschaubar bleibt und alles andere in Schichten darum herum gebaut wird, die man nicht lesen muss.

Sicherheit schon in der ersten Version. Der Funk hat erzwungen, Nachrichten von Anfang an zu signieren, und das hat rund dreißig Zeilen gekostet. Systeme, die mit einem vertrauenswürdigen Netzwerk begannen und Schutz später nachrüsteten, haben dafür mehr bezahlt. Die Lehre ist banal, aber Oberon illustriert sie gut: Ist die Umgebung vom ersten Tag an feindlich, entsteht die richtige Architektur von selbst.

Und gesondert dazu, was man nicht tun sollte. Kube zeigt deutlich, dass Isolation, Präemption und Rechtetrennung keine überflüssige Komplexität sind, die man um der Einfachheit willen über Bord werfen sollte, sondern das, ohne das ein geteilter Computer nicht möglich ist. Genau hier hat Oberon verloren, und jedes System, das zugleich einfach und geteilt sein will, wird einen Weg finden müssen, Isolation zu bekommen, ohne die Überschaubarkeit zu verlieren. Mir scheint, dass es heute zum ersten Mal passende Bausteine dafür gibt, von WebAssembly bis zu kleinen verifizierbaren Kerneln, und die einzige Frage ist, ob jemand daraus ein System bauen will, das sich wieder vollständig lesen lässt.

Statt eines Fazits

Ich wollte prüfen, ob die Idee von Kubernetes in eine Maschine passt, die von Anfang bis Ende von einem einzigen Menschen entworfen wurde. Sie passt, samt Rollouts, Disaster Recovery, einem signierten Protokoll und einem Store auf der Festplatte, in rund vierzehnhundert Zeilen einer Sprache aus den späten Achtzigern. Unterwegs stellte sich heraus, dass die Grenzen der Maschine nicht nur im Weg standen, sondern auch Lösungen nahelegten, und manche davon erwiesen sich als besser als die, an die wir gewöhnt sind. Klar wurde auch, wo genau solche Systeme an ihre Decke stoßen, und das ist vielleicht der wertvollste Teil, weil es erklärt, warum die Welt einen anderen Weg eingeschlagen hat.

Als Nächstes stehen auf der Liste eine Bereitschaftsprüfung, die der Workload selbst beantwortet, damit ein Rollout wartet, bis neuer Code wirklich bereit und nicht bloß gestartet ist, und eine Möglichkeit, Deployments von außerhalb der Control Plane ohne VNC anzuwenden. Und vielleicht Isolation, zumindest teilweise, um zu sehen, wie viel Einfachheit sie kosten würde.

Das Projekt ist offen. Der Quellcode liegt im Repository; unser Code steht unter der Lizenz Apache-2.0, das QEMU-Maschinenmodell wie QEMU selbst unter der GPL. Das Cluster-Lab finden Sie unter tym83.github.io/paleocomputing/oberon/kube.html, die übrigen Labs der Serie und die Seite zum Cozystack-Katalog auf der Projektseite. Über Cozystack selbst können Sie auf cozystack.io lesen. Ich freue mich, wenn jemand im Lab den Funkkanal nicht für eine halbe Minute, sondern auf eine raffiniertere Weise abschaltet und herausfindet, wo Kube bricht. Solche Funde gab es in dieser Geschichte schon viele, und jeder hat etwas gelehrt.

Im nächsten Teil der Paleocomputing-Serie bauen wir anhand der Spezifikationen und der Ausschreibungsunterlagen Adas Rivalen nach: die Programmiersprachen, die am Wettbewerb des US-Verteidigungsministeriums teilnahmen, ihn aber nicht gewannen.

Am 1. Januar 2024 starb Niklaus Wirth – der Mann, der uns Pascal, Modula-2 und Oberon geschenkt hat, den Turing Award bekam und sein ganzes Leben lang einen hartnäckigen Krieg gegen aufgeblähte Software führte. Weniger bekannt ist, dass er sich, schon weit über siebzig, hinsetzte und einen eigenen Prozessor entwarf: klein und einfach, damit er Studierenden einen ganzen Computer auf einmal zeigen konnte, von den Logikgattern bis zu den Fenstern auf dem Bildschirm.

Im September 2026 habe ich diesen Prozessor genommen und versucht, ihn überall zum Laufen zu bringen, wo ich nur hinkam. Zuerst direkt in einem Browser-Tab – und zwar nicht als Emulator, sondern als genau die Schaltung, die Wirth gezeichnet hat. Dann in QEMU, als ganz gewöhnliche virtuelle Maschine. Dann in Kubernetes, wo normalerweise eine ganz andere Sorte VM zu Hause ist, nämlich die, auf der Ubuntu und Datenbanken laufen. Und schließlich in Cozystack, unserer Cloud-Plattform, wo sich Wirths Maschine jetzt mit einem einzigen Klick aus dem Katalog installieren lässt, so wie man PostgreSQL installiert. Nebenbei habe ich endlich etwas gemessen, worüber Programmierer seit Jahrzehnten streiten: was die Prüfung von Array-Grenzen tatsächlich kostet. Ich habe außerdem ein kleines Sprachmodell auf Wirths Prozessor laufen lassen. Und, wenn wir schon ehrlich sind: Mit einer unbedachten Bewegung habe ich sämtliche virtuellen Maschinen in einem produktiven Cluster auf Migration geschickt (verletzt wurde niemand, aber es waren ein paar unangenehme Sekunden).

Daraus ist ein sehr langer Artikel geworden, weil in neun Tagen sehr viel passiert ist und ein guter Teil davon meine eigenen Fehler waren, die ich anschließend finden und beheben musste. Ich habe versucht, so zu schreiben, dass auch jemand folgen kann, der noch nie von Oberon gehört hat, und alles, was nur Spezialisten interessiert, unter Spoilern versteckt. Sie können den Text am Stück lesen oder direkt zu dem Teil springen, der Sie interessiert. Zuerst kommt die Geschichte von Oberon selbst, dann, wie mein ursprünglicher Plan zerfiel, dann der Prozessor und die Bounds-Prüfung, dann der Browser und die Laborübungen, dann QEMU, Kubernetes und Cozystack und ganz am Ende das Sprachmodell und wie Sie das alles selbst installieren.

Der gesamte Quellcode, die Notizen und Anleitungen liegen im Repository github.com/tym83/paleocomputing, die Projektseite ist tym83.github.io/paleocomputing. Wer lieber erst selbst Hand anlegt und danach liest, öffnet das Labor: Es muss nichts installiert werden, die Maschine bootet direkt im Browser.

Was Oberon ist

Oberon ist zugleich eine Programmiersprache und ein Betriebssystem, entstanden Mitte der 1980er-Jahre an der ETH Zürich, entwickelt von Niklaus Wirth und Jürg Gutknecht. Sie begannen im Herbst 1985, und 1988 lief das System tatsächlich. Nach Wirths eigener Darstellung haben es zwei Leute in den Stunden geschrieben, die neben ihrer eigentlichen Arbeit übrig blieben – was, das müssen Sie zugeben, ziemlich verrückt klingt, wenn man bedenkt, wie viele Menschen heute nötig sind, um irgendein Betriebssystem zu schreiben. Es lief auf der Workstation Ceres, die ebenfalls an der ETH gebaut wurde, und bis etwa Anfang der 2000er-Jahre wurde darauf unterrichtet.

Der Name stammt übrigens von Voyager. Im Januar 1986 schickte die Sonde Bilder von Uranus und seinen Monden zur Erde, und Wirth – der Voyager für ein vorbildliches Ingenieurprojekt hielt, ein Gerät, das weit über seine geplante Lebensdauer hinaus funktionierte – benannte das System nach dem Mond Oberon. Im Buch nennt er Oberon den größten Uranusmond, tatsächlich ist aber Titania größer; auch Wirth hat Tippfehler. Und als Zugabe ist Oberon auch der König der Elfen, was als Namenspate ebenfalls nicht schlecht ist.

Die Leitidee des ganzen Unterfangens steht im Vorwort zum Buch des Projekts: Ein von Grund auf neu gebautes System sollte etwas sein, das man vollständig beschreiben, erklären und verstehen kann – ein einzelner Mensch sollte das Ganze lesen und verstehen können, vom Prozessor bis zur Fensteroberfläche. Nach heutigen Maßstäben klingt das fast wie Fantasy, denn niemand auf der Welt versteht ein modernes Betriebssystem samt Compiler und Prozessor vollständig.

2013 veröffentlichte Wirth eine Neuausgabe des Projekts und zog die Idee darin konsequent bis zum Ende durch. Der Prozessor, auf dem Ceres lief, wurde längst nicht mehr hergestellt, und Wirth entschied: Wenn alles andere im System von ihm stammt und verständlich ist, soll auch der Prozessor von ihm sein. Er entwarf einen einfachen RISC-Prozessor – in den Quellen heißt er RISC5 – und beschrieb ihn in Verilog, der Sprache, mit der man digitale Schaltungen beschreibt. Eine solche Schaltung lässt sich auf ein FPGA flashen, einen programmierbaren Chip, und heraus kommt ein echter, funktionierender Computer. Wirths Exemplar lief auf einem preiswerten Board mit einem Megabyte Speicher bei 25 MHz. Das ist ungefähr hundertmal langsamer als ein einzelner Kern Ihres Smartphones, für Oberon aber mehr als genug, denn der Compiler übersetzt sich, wie Wirth schreibt, in etwa drei Sekunden selbst. Das Buch und die Quellen von System, Compiler und Prozessor sind offen zugänglich, und genau das macht Oberon einzigartig. Noch ein Detail, das für uns wichtig wird: Das System selbst stammt aus den späten 1980er-Jahren, der Prozessor, auf dem wir es betreiben werden, entstand dagegen erst in den 2010er-Jahren.

Warum sich 2026 mit einem Museumsstück beschäftigen? Ich habe drei Gründe. Der erste: wie tief Oberon das geprägt hat, was wir heute benutzen. Go – die Sprache, in der die halbe heutige Cloud-Infrastruktur geschrieben ist, Kubernetes eingeschlossen – nennt Oberon ausdrücklich als einen seiner Vorfahren; das steht direkt in der Go FAQ. Und Robert Griesemer, einer der drei Autoren von Go, hat bei Wirth an der ETH promoviert und zeichnet in seinem Vortrag “The Evolution of Go” einen Stammbaum, in dem eine gerade Linie von Oberon zu Go führt. Der zweite Grund: Oberon passt wirklich in einen Kopf. Wer verstehen will, wie ein Computer vom Gatter bis zum Fenster funktioniert, für den kenne ich kein besseres Lehrmittel. Und der dritte Grund: 1995 schrieb Wirth “A Plea for Lean Software”, ein Manifest gegen aufgeblähte Software – die Quelle des Wirthschen Gesetzes, wonach Software schneller langsamer wird, als Hardware schneller wird, wobei Wirth die Beobachtung redlicherweise seinem Kollegen Martin Reiser zuschrieb –, und Oberon war sein Beweis, dass es auch anders geht. Dreißig Jahre später ist es, vorsichtig gesagt, nur schlimmer geworden.

Und Oberon lebt erfreulicherweise noch. Es gibt aktive Forks, die erst vor wenigen Tagen aktualisiert wurden, und eine russischsprachige Community, OberonCore, die das alles lebhaft diskutiert.

Woher die ganze Idee kam

Ich führte schon lange eine Liste vergessener Systeme. Betriebssysteme, Sprachen und ganze Maschinen, die einmal funktionierten, manchmal sehr gut, und dann verschwanden – oft samt Ideen, die seither niemand richtig nachgebaut hat. Die Burroughs B5000, die schon 1961 Datentypen direkt in der Hardware prüfte. KeyKOS, für das ein aus der Wand gerissenes Stromkabel ein normales Ereignis war und keine Katastrophe. Transputer, Lilith, der iAPX 432. Über alle wurden Artikel und Bücher geschrieben, aber fast niemand betreibt sie tatsächlich, und genau das wollte ich – sie wirklich laufen lassen, mit allen Innereien, und sehen, was sie können.

So entstand die Reihe, die ich Paleocomputing genannt habe. Die Idee dahinter ist einfach. Viele dieser Systeme haben nicht verloren, weil sie schlecht waren, sondern weil sie teuer waren. Eigenes Silizium für eine eigene Sprache kostete Unsummen, während gewöhnliche Intel-Prozessoren schneller billiger wurden, als irgendjemand etwas Kluges bauen konnte. Heute sieht die Wirtschaftlichkeit anders aus. Programmierbare Chips kosten Centbeträge, die offene Architektur RISC-V erlaubt offiziell, dem Prozessor eigene Instruktionen hinzuzufügen, und das Projekt CHERI – dazu unten noch viel mehr – bringt im Grunde genau den Hardware-Speicherschutz in moderne Prozessoren zurück, den Burroughs schon vor meiner Geburt beherrschte. Das heißt, die alten Ideen lassen sich wieder von Hand ausprobieren, und genau das habe ich mir vorgenommen.

Für die erste Folge habe ich Oberon gewählt, obwohl ich eigentlich lieber Burroughs gemacht hätte. Der Grund ist simpel: Bei Oberon ist absolut alles vorhanden, was man zum Arbeiten braucht. Die Quellen des Prozessors, der Compiler, das Betriebssystem, das Buch, das alles erklärt, lebendige Emulatoren und fertige Disk-Images. Man kann sofort in die volle Tiefe eintauchen, statt einen Monat lang Dokumentation auszugraben – und für den Start einer Reihe brauchte ich genau diese Größenordnung.

Wie es gemacht wurde

Ich gebe gleich vorweg zu, dass der Großteil des Codes in diesem Projekt nicht von mir geschrieben wurde, sondern von einem neuronalen Netz. Genauer gesagt von mehreren KI-Agenten, denen ich verschiedene Rollen zugeteilt habe. Die einen schrieben Code, die anderen prüften ihn, und wieder andere bekamen die Aufgabe herauszufinden, warum das Ganze nicht funktionierte – und nahmen das sehr ernst. Sie tauchen im Text immer wieder als Reviewer und Auditoren auf, und ich möchte von Anfang an klarstellen, dass das keine lebenden Menschen sind, sondern dieselben neuronalen Netze, denen ich die Rolle eines pedantischen Lesers, eines Hardware-Spezialisten oder eines Messmethodikers zugewiesen habe. Sie arbeiteten unabhängig voneinander und unabhängig von dem Agenten, der den Code schrieb, und das war, glaube ich, die mit Abstand nützlichste Erfindung des ganzen Projekts. Bei mir blieben das Design, die Entscheidungen, die endlosen Fragen, ob wirklich alles geprüft wurde, und ein produktiver Cluster, den man, wie sich herausstellte, sehr leicht aus der Fassung bringt.

Ich erwähne das nicht, um auf einem Modethema mitzureiten, sondern weil der Rest der Geschichte ohne diesen Umstand keinen Sinn ergibt. Erstens wurde alles, was hier beschrieben ist, in neun Tagen erledigt, vom 21. bis zum 29. September, und dieses Tempo wäre unmöglich gewesen, hätte ich alles von Hand geschrieben. Zweitens ist es der Grund, warum sich ein Teil des Codes nicht an die großen Open-Source-Projekte übergeben lässt; dazu komme ich im Abschnitt über QEMU. Und drittens hat ein neuronales Netz eine sehr charakteristische Angewohnheit: Es meldet liebend gern, dass alles erledigt ist und alle Checks grün sind. In der Praxis hieß das oft, dass der Check schlicht gar nichts prüfte. Deshalb ging der größte Teil dieser neun Tage nicht ins Codeschreiben, sondern darein, den Checks beizubringen, ehrlich zu erröten, wenn etwas kaputt ist – ein roter Faden, der sich durch den ganzen Artikel zieht.

Der Plan, der an einem Tag zerfiel

Auf dem Papier klang der Plan großartig. Wirths echter Prozessor sollte direkt in einem Browser-Tab laufen, Takt für Takt – und nicht als Emulator, der nach der Dokumentation geschrieben wurde, sondern als seine eigene Schaltung. Ein Leser könnte den Befehlssatz dieses Prozessors direkt auf der Seite ändern, einen Knopf drücken und ein paar Sekunden später zusehen, wie das Betriebssystem auf der veränderten Hardware weiterläuft. Und obendrauf wollte ich drei laute Behauptungen setzen. Dass der ganze Computer, von den Gattern bis zu den Fenstern, in einem Browser läuft. Dass ein kleines neuronales Netz mindestens doppelt so schnell läuft, wenn man dem Prozessor eine spezielle Instruktion hinzufügt, die in einem Zug multipliziert und addiert, und dass man das in etwa einer Minute erledigt. Und dass man, wenn man dem Prozessor eine Hardware-Prüfung der Array-Grenzen hinzufügt, zum ersten Mal ehrlich messen kann, was eine solche Prüfung kostet – denn, wie ich im Entwurf selbstbewusst schrieb, diese Zahl hat niemand.

Ich gab mir zwei bis vier Wochen. Na klar.

Bevor ich mich ans Codeschreiben machte, schickte ich den Plan an fünf Reviewer, jeder mit eigenem Fachgebiet: Zeitplan, Hardware, Compiler, Messmethodik und Browser. Die Aufgabe war für alle dieselbe: herausfinden, warum das nicht funktionieren wird. Die Kommentare summierten sich auf mehr als achtzig Kilobyte Text, und danach stand vom Plan nicht mehr viel.

Am ärgerlichsten war, dass der Platz für neue Instruktionen im Prozessor, den ich gefunden zu haben glaubte, gar nicht frei war. Ich hatte in der Instruktionskodierung ein Bit gesehen, das immer null ist, und wollte dort meine neuen Instruktionen unterbringen. Der Hardware-Reviewer öffnete Wirths Schaltung und zeigte, dass der Prozessor dieses Bit schlicht nicht beachtet – auf einem echten Prozessor würden also alle meine neuen Instruktionen stillschweigend als die häufigste Instruktion überhaupt ausgeführt, als Datentransfer, und das Programm würde in aller Ruhe etwas völlig anderes tun als das, was geschrieben steht. Freien Platz gab es im Befehlssatz überhaupt nicht. Später fand sich zwar doch eine kleine Stelle, an der Wirths Compiler immer Nullen schreibt, und darüber, wie ich mich dort hineinzuquetschen versuchte, gibt es eine eigene Geschichte.

Auch die Verdopplung der Geschwindigkeit für das neuronale Netz überstand das Review nicht. Die Reviewer zählten direkt an der Schaltung ab, wie viele Takte jede Operation braucht, und selbst wenn die neue Instruktion völlig kostenlos wäre, könnte sie das Programm grundsätzlich nicht um mehr als den Faktor zwei beschleunigen – und die tatsächlich gebaute würde mit Glück ein paar Prozent schaffen. Und genau hier lag der entscheidende Punkt, der sich später bestätigte: Der Engpass ist gar nicht die fehlende Instruktion, sondern Wirths sehr langsamer Multiplizierer, der das Produkt mit einem Bit pro Takt berechnet.

Die Zahl, die angeblich niemand hat, wurde zur ziemlichen Blamage. Der Methodiker brachte eine Liste von Arbeiten mit, in denen die Kosten von Hardware-Speicherschutz vielfach gemessen worden waren, auch auf modernen Arm-Prozessoren und im CHERI-Projekt. Relativ neu war eigentlich nur, dass ich als Last ein System verwenden wollte, das sich selbst neu baut – aber auch das ist eher ein Detail als eine Entdeckung.

Außerdem stellte sich heraus, dass man in Oberon die Prüfung der Array-Grenzen in gewöhnlichem Code überhaupt nicht abschalten kann; sie ist fest in den Compiler eingeschweißt. Es gab schlicht nichts, womit man Wirths System ohne Prüfungen hätte vergleichen können, und ich musste von Anfang an einen eigenen Compiler-Patch einplanen, der einen Build ohne Prüfungen erzeugt.

Nach dem Review habe ich den Plan neu geschrieben. In der ersten Folge blieben zwei Behauptungen übrig. Erstens, dass der ganze Computer in einem Browser läuft. Zweitens, dass man die Kosten der Bounds-Prüfung auf einem vollständig offenen System ehrlich messen kann, auf dem alles sichtbar ist, von der Prozessorschaltung bis zum Compiler. Das neuronale Netz und seine neue Instruktion habe ich in eine eigene Folge verschoben. Und in der Risikotabelle tauchte ein Satz auf, den ich sehr mag: dass die Zahl höchstwahrscheinlich langweilig ausfallen wird, um die sechs Prozent – und dass genau das das Ergebnis ist.

Um vorzugreifen: Ich habe am Ende doch ein neuronales Netz auf Wirths Prozessor laufen lassen, und in der Hauptsache hatten die Reviewer recht – alles lief auf den Multiplizierer hinaus. Aber dazu mehr gegen Ende.

Wirths echten Prozessor zum Laufen bringen

Alles beginnt ganz einfach. Wirth hat seinen Prozessor in Verilog beschrieben, und diese Beschreibung ist kein Programm, sondern eine Schaltung – Register, Leitungen und die Logik dazwischen. Um eine solche Schaltung ohne echten Chip auszuführen, gibt es ein Werkzeug namens Verilator, das daraus ein C++-Programm macht, das in jedem Takt jede Leitung des Prozessors getreu neu berechnet. Das läuft langsamer als echte Hardware, aber genau wie sie, ohne Näherungen. An den Prozessor müssen noch Bildschirm, Festplatte, Tastatur und Maus angeschraubt werden. Diese Umgebung habe ich selbst gebaut und dabei exakt die Schnittstelle nachgebildet, die das System erwartet, den Prozessor selbst aber um keine einzige Zeile verändert. Das war mir grundsätzlich wichtig, denn alles, was ich später messe, muss auf seiner Schaltung gemessen werden, nicht auf meiner.

Der erste Arbeitstag begann am 22. September um ein Uhr nachts, und bis zum Mittag hatte Wirths echte Schaltung das echte Project Oberon gebootet. Der Bootvorgang umfasst etwa zwölf Millionen Instruktionen, und auf meinem Laptop schafft die Simulation das in vier Sekunden. Das Bild ganz oben im Artikel stammt aus genau diesem Lauf.

Es zum Laufen zu bringen, ist nur die halbe Arbeit; man muss sicher sein, dass es korrekt läuft. Dafür gibt es eine Technik namens Lockstep-Vergleich. Man nimmt eine Referenz, der man vertraut, und lässt sie parallel zur eigenen Maschine dasselbe Programm abarbeiten, Instruktion für Instruktion, wobei nach jeder einzelnen der Inhalt sämtlicher Register verglichen wird. Weicht irgendwo auch nur ein einziges Bit ab, erfährt man es sofort und weiß genau, bei welcher Instruktion es passiert ist. Als Referenz nahm ich den Emulator aus dem Projekt Norebo, und über den gesamten Systemstart – fast fünfzehn Millionen Instruktionen – wich meine Schaltung kein einziges Mal von ihm ab. Anfangs gab es allerdings eine Abweichung, und die ging auf mein Konto: Auf Anraten eines Reviewers hatte ich vorsorglich einen Verwaltungswert in den Speicher geschrieben, den der Emulator nur in einer bestimmten Situation schreibt, die in diesem Lauf gar nicht eintrat. Richtig war, gar nichts anzufassen.

Hier sollte ich sagen, warum das überhaupt wichtig ist. Alle Taktzahlen in diesem Artikel berechnet ein separates schnelles Modell, weil die echte Schaltung unter schwerer Last viel zu lange braucht. Und diesem Modell kann man genau so weit trauen, wie es mit der Schaltung übereinstimmt. Ich habe die beiden auf demselben Bootvorgang gegeneinander geprüft und eine perfekte Übereinstimmung bekommen, bis auf den Takt genau – aber zunächst behauptete der Vergleich, das Modell liege um fast sechzehn Prozent daneben, und ich hätte es beinahe geglaubt. Gelogen hatte der Vergleich selbst, weil er die Instruktionsadresse einen Takt früher abgriff als vorgesehen. Hätte ich damals veröffentlicht, dass das Modell um 16 % danebenliegt, wäre jede Zahl im Projekt entwertet gewesen. Seitdem habe ich eine Regel: Ein negatives Ergebnis muss genauso sorgfältig geprüft werden wie ein positives, denn man kann sich in beide Richtungen irren.

Was die Prüfung von Array-Grenzen kostet

Nun zur zentralen Frage der ersten Folge. Schreibt man in C a[i] und ist i zufällig größer als das Array, liest oder schreibt das Programm stillschweigend fremden Speicher. Aus diesem simplen Fehler ist ein riesiger Teil der Sicherheitslücken der letzten fünfzig Jahre erwachsen, von den Buffer Overflows der Neunziger bis zu den heutigen Sicherheitsbulletins der Browser. Sich davor zu schützen, ist sehr einfach: Vor jedem Array-Zugriff wird der Index mit der Länge verglichen und, falls er außerhalb liegt, das Programm angehalten. Viele Sprachen tun genau das, Oberon tut es immer, und in C und C++ wird diese Prüfung traditionell nicht geschrieben, weil sie als langsam gilt. Ich wollte also herausfinden, wie langsam sie tatsächlich ist, und zwar auf einem System, auf dem absolut alles sichtbar ist.

Dafür braucht man drei Varianten desselben Systems. Die erste ohne jede Prüfung – ein solches Oberon gibt es nicht, also habe ich es selbst gebaut, indem ich eine einzige Zeile im Compiler geändert habe. Die zweite mit der Software-Prüfung, wie bei Wirth, bei der der Compiler vor jedem Zugriff einen Vergleich und einen Sprung zum Fehlerbehandler einfügt. Und die dritte mit einer Hardware-Prüfung, bei der der Prozessor eine neue Instruktion bekommt, die all das selbst in einem Takt erledigt. Diese Instruktion bekommt einen eigenen Abschnitt. Als Last nahm ich den Oberon-Compiler, der mehrere Module des Systems selbst übersetzt, denn das ist ein echtes, großes Programm und kein synthetischer Test.

Die erste Zahl, die ich bekam, lag unter einem halben Prozent, und ich freute mich, dass Prüfungen fast nichts kosten. Dann merkte ich, dass ich das Falsche verglichen hatte. Ich hatte zwei verschiedene Compiler laufen lassen, einen mit Prüfungen und einen ohne, und der Compiler ohne Prüfungen hatte schlicht weniger Arbeit, weil er niemandem sonst Prüfungen in den Code einfügen musste. Vergleichen muss man dieselbe Arbeit – also ein und denselben Compiler in zwei Varianten bauen und beiden dieselbe Aufgabe geben. Nachdem ich das korrigiert hatte, wuchs die Zahl um ein Mehrfaches.

Danach gab es noch einige Durchgänge, und die ehrliche Antwort lautete so. Solange die Prüfungen nur aus dem Compiler selbst entfernt werden, kosten sie etwa zwei Prozent der Zeit. Entfernt man sie aus dem gesamten System, auf dem der Compiler läuft, einschließlich der Verarbeitung von Text, Dateien und Speicher, sind es fast fünf Prozent. Von je hundert Takten Compilerarbeit gehen also zwischen zwei und fünf dafür drauf, dass das Programm nie über das Ende eines Arrays hinausläuft. Ob das viel oder wenig ist, mag jeder Leser selbst entscheiden; für meinen Geschmack ist es sehr billig dafür, dass eine ganze Klasse von Sicherheitslücken wegfällt. Mit einem Vorbehalt, den die Reviewer schon am ersten Tag gemacht hatten: Ich habe nur eine einzige Last, das ist also eine Zahl über den Oberon-Compiler und nicht über alle Programme der Welt.

Hier wartete die erste Überraschung auf mich. Als ich nachzählte, welche Prüfungen tatsächlich im Code stehen, stellte ich fest, dass es in Oberon sehr wenige Prüfungen von Array-Grenzen gibt und die überwältigende Mehrheit Prüfungen darauf sind, dass ein Zeiger nicht leer ist – also nicht NIL. Allein im Compiler sind es mehr als dreihundert davon gegenüber einer Handvoll Indexprüfungen. Die Kosten der Sicherheit in Oberon entstehen also hauptsächlich dadurch, dass das Programm keinen Nullzeiger dereferenzieren kann, und Arrays als solche sind hier Nebensache.

Wie ich dem Prozessor beibrachte, selbst zu prüfen

Jetzt zur Hardware-Prüfung. Die Idee ist einfach. Statt zweier Instruktionen – eines Vergleichs und eines bedingten Sprungs – bekommt der Prozessor eine neue Instruktion, die ich CHK genannt habe. Sie nimmt einen Index und eine Array-Länge und springt, wenn der Index außerhalb des Bereichs liegt, selbst zum Fehlerbehandler. Alles in einem Takt statt in zweien.

Die Schwierigkeit lag darin, wo in der Instruktion die Array-Länge unterzubringen ist. Eine Instruktion auf Wirths Prozessor hat 32 Bit, und fast alle sind schon belegt. Die einzige Stelle, die der Prozessor wirklich nicht nutzt – was ich durch Aufzählen aller möglichen Werte bewiesen habe –, sind zwölf Bit in der Mitte der Instruktion. Zwölf Bit bedeuten Arrays mit bis zu viertausend Elementen, und das ist in Oberon die überwältigende Mehrheit, also war ich zufrieden und legte die Länge dorthin.

Und bekam ein sehr hässliches Ergebnis. Schlägt in Oberon eine Prüfung an, meldet das System, wo und welcher Fehler genau aufgetreten ist, und die Fehlernummer entnimmt es genau den Bits der Instruktion, in die ich die Länge gelegt hatte. Ich machte ein Experiment mit einem echten Fehler, einem Programm, das über das Ende eines Arrays mit hundert Elementen hinausgreift. Das gewöhnliche System meldete ehrlich, dass der Index außerhalb der Array-Grenzen lag. Meines, mit der neuen Instruktion, meldete ebenso selbstbewusst, es habe eine Nullzeiger-Dereferenzierung gegeben, weil ein Stück der Zahl 100 im Feld für die Fehlernummer gelandet war. Ein Programmierer, der diese Meldung bekommt, würde einem nicht existierenden Zeiger-Bug hinterherjagen und einen halben Tag damit verlieren. Das ist schlimmer, als wenn das System gar nichts sagt.

Danach versuchte ich ein paarmal, mich herauszuwinden, indem ich die Länge auf acht Bit verkürzte, und beide Male ging es schief. Zuerst zeigte die Statistik, dass acht Bit für die meisten Arrays reichen, dann stellte sich aber heraus, dass die Mehrheit in dieser Statistik aus identischen Puffern für Dateinamen bestand, die kaum je benutzt werden, während die heißen Schleifen, die millionenfach laufen, gerade mit den großen Arrays arbeiten und nicht in acht Bit passen. Die Lösung fand sich an anderer Stelle. Die neue Instruktion braucht nämlich kein Zielregister, weil sie nichts berechnet, sondern nur prüft, und die vier Bit, die gewöhnlich dieses Register bezeichnen, sind frei. Die Länge lässt sich in zwei Teile schneiden: Die vier oberen Bit kommen dorthin, die acht unteren in die Mitte der Instruktion, so platziert, dass sie die Fehlernummer nicht berühren. Das ergab sowohl die zwölf Bit Länge als auch korrekte Fehlermeldungen.

`ifdef WITH_CHK
assign CHK     = ~p & ~q & ~u & v & (op == 1);
assign chkFail = CHK & (B >= chkLim);
`else
assign CHK     = 1'b0;
assign chkFail = 1'b0;
`endif

Wie viel spart die Hardware-Prüfung also am Ende? Beim Compiler fällt etwa ein Sechstel der Prüfkosten weg, bei einer gemischten Last mit Arrays unterschiedlicher Größe ein Zehntel und bei rein rechnendem Code mit kleinen Arrays die Hälfte. Die Hälfte ist übrigens die Obergrenze, mehr wird es nie, denn aus zwei Instruktionen wurde eine. Der Unterschied zwischen den Lasten hat eine ganz einfache Erklärung. Die Instruktion hilft nur dort, wo die Array-Länge in zwölf Bit passt. Wo das Array größer ist, greift der Compiler auf die alte Software-Prüfung zurück, und es gibt keinen Gewinn.

Und noch eine schöne Geschichte aus diesem Abschnitt. Für die zweite Last schrieb ich ein kleines Programm mit einer Sortierung und einer Matrixmultiplikation. In der Variante mit Prüfungen stürzte es sofort mit einer Out-of-Bounds-Meldung ab, und der Fehler steckte in meinem Programm selbst: Ich hatte einen Index falsch berechnet und lief um das Dreieinhalbfache über das Array hinaus. Die Variante ohne Prüfungen lief stillschweigend durch, als sei alles in Ordnung, und schrieb in aller Ruhe zweieinhalbtausend Zahlen in fremden Speicher. Gefunden wurde der Bug nur, weil die Prüfungen eingeschaltet waren, und ehrlich gesagt fällt mir keine bessere Werbung für Bounds-Checking ein.

Wie viel die neue Instruktion in Hardware kostet – wie viel Platz sie auf dem Chip einnimmt und ob sie den Prozessor verlangsamt –, habe ich ebenfalls gemessen, und die Antwort fiel langweilig aus. Sie fügt weniger als ein Prozent Logik hinzu und berührt die Taktfrequenz überhaupt nicht. Interessant ist hier, wie ich zu dieser langweiligen Antwort kam, denn unterwegs erwies sich das Rauschen bei solchen Messungen als größer als der Effekt selbst.

Die Auditoren haben die Arbeit nicht abgenommen

Am Abend des ersten Tages hatte ich viele hübsche Zahlen und übergab sie fünf Auditoren zur Abnahme. Um 17:40 meldeten sie sich zurück, und alle fünf schrieben dasselbe Wort: NICHT ABGENOMMEN, in Großbuchstaben.

Am unangenehmsten und zugleich am nützlichsten war das Mutations-Audit. Seine Idee ist einfach und sehr grausam. Der Auditor baut absichtlich plausible Fehler in den Prozessor ein – ändert etwa in einem Vergleich „größer oder gleich“ in „größer“ – und schaut, ob meine Tests es bemerken. Bleiben die Tests auf einem kaputten Prozessor grün, prüfen sie gar nichts. Von dreißig eingebauten Fehlern fingen meine Tests zehn. Zwei Drittel der kaputten Prozessoren bestanden jede Prüfung als einwandfrei.

Die Gründe waren sehr lehrreich. An einer Stelle zählte ein Check, der gar nicht gelaufen war, als bestanden, und der Bericht verkündete stolz, drei von fünf Fällen seien geprüft und keine Fehler gefunden worden. An einer anderen war der Test-Build so konfiguriert, dass sein Scheitern den Lauf nicht stoppte, und Erfolg wurde an einem Smiley in der letzten Ausgabezeile festgemacht, sodass null ausgeführte Tests einen vollständig grünen Bericht ergaben. Und eine Instruktion, die angeblich den Systemstart prüfte, prüfte in Wahrheit überhaupt nichts: Mit einem Prozessor, bei dem eine seiner Instruktionen kaputt war, blieb die Maschine gleich zu Beginn des Bootvorgangs hängen, und der Check meldete trotzdem Erfolg. Obendrein enthält der Systemstart keine einzige Operation mit Gleitkommazahlen, meine Behauptung, der Vergleich habe die gesamte Arithmetik des Prozessors geprüft, war also schlicht falsch.

Die Hauptschlussfolgerung der Auditoren war, dass fast alle Fehler beim Übertragen der Ergebnisse in den Text passierten. Eine Zahl, die unter bestimmten Bedingungen gewonnen wurde, wanderte als allgemeine Aussage in die Zusammenfassung. Wir haben alles umgeschrieben, was wir fanden, dieselbe Art absichtlicher Sabotage in den automatischen Check bei jeder Änderung aufgenommen und eine Regel eingeführt: Jeder Check muss scheitern können, und das muss vorgeführt werden. Und am nächsten Tag tauchte noch ein Juwel auf. In allen gut zweihundert Prozessortests wurde die allererste Instruktion des Programms gar nicht ausgeführt, und zwar wegen genau jenes Bus-beim-Reset-Bugs, über den ich oben geschrieben habe. Bemerken konnte man das unmöglich, weil jeder Test mit einer Instruktion begann, deren Ergebnis ohnehin keine Rolle spielte. Am ärgerlichsten: Ich hatte diesen Bug auf einem anderen Prüfstand schon gefunden und behoben und dort sogar einen Kommentar hinterlassen, dass ich genau darüber gestolpert war.

Und um 19:30 am ersten Tag schloss sich der Kreis. Der Oberon-Compiler, der auf Wirths echter Schaltung lief, übersetzte sich selbst, und das Ergebnis stimmte Byte für Byte mit dem überein, was der Emulator erzeugt. Am nächsten Tag gelang dasselbe innerhalb des Systems selbst, mit Fenstern und Maus. Ein Skript aus Klicks und Tastendrücken ließ das System sich vollständig neu bauen, und jede Datei kam genau so heraus wie im ursprünglichen Disk-Image. Nebenbei stellte sich heraus, dass das offizielle System-Image von 2016 nicht ganz mit sich selbst konsistent ist: Ein paar seiner Module waren veraltet, und eines fehlte ganz. Der ganz normale Alltag eines lebendigen Projekts – und ehrlich gesagt hat mich das ziemlich gerührt.

Oberon in einem Browser-Tab

Jetzt zur ersten Behauptung dieser Folge, der über den Browser. Wirths Schaltung, die Verilator in ein C++-Programm verwandelt hat, lässt sich weiter nach WebAssembly übersetzen – in das Format, in dem ein Browser gewöhnlichen kompilierten Code mit nahezu nativer Geschwindigkeit ausführen kann. Und dann dreht sich im Tab kein Emulator, den jemand nach der Dokumentation geschrieben hat, sondern genau die Schaltung, die Wirth auf sein FPGA geflasht hat, mit allen ihren Leitungen und Takten. Ich betone noch einmal: Bildschirm, Festplatte, Tastatur und Maus rund um den Prozessor stammen von mir, gebaut nach derselben Schnittstelle wie bei Wirth, und der Videocontroller, der auf einer echten Maschine ein wenig Prozessorzeit beansprucht, geht in die Messungen nicht ein.

Anfangs hieß es, das sei eine schlechte Idee, weil das Neuberechnen jeder Leitung für einen Browser zu langsam sei. In der Praxis läuft die Browser-Version fast so schnell wie dieselbe Simulation, die direkt auf dem Rechner gestartet wird – der Unterschied liegt bei ein paar Prozent. Das ist etwa sechsmal langsamer als Wirths echte Maschine, das System braucht also ein paar Sekunden zum Booten, danach kann man ganz entspannt damit arbeiten. Und die ganze Maschine samt Disk-Image wiegt etwa dreihundert Kilobyte – weniger als ein durchschnittliches Bild auf einer beliebigen Nachrichtenseite.

Dadurch lässt sich die Maschine mit zwei Zeilen in jede beliebige Seite einbetten:

<script type="module" src="https://tym83.github.io/paleocomputing/oberon/embed.js"></script>
<oberon-machine base="https://tym83.github.io/paleocomputing/oberon/"></oberon-machine>

Details und Einstellungen stehen auf der Seite Embed it. Dort können Sie die Maschine auch auf den Prozessor mit der neuen Prüfinstruktion umschalten und vor dem Booten eigene Dateien auf ihre Festplatte legen.

Die Seite, auf der man den Prozessor wechselt

Ursprünglich wollte ich, dass der Leser den Befehlssatz des Prozessors selbst ändern kann, direkt auf der Seite. Das habe ich, wie ich offen zugebe, nicht umgesetzt, weil sich das Neubauen der Schaltung aus Verilog direkt im Browser als zu schwer erwies. Stattdessen funktionierte die Ausweichidee aus demselben Plan: mehrere Prozessorvarianten vorab bauen und zwischen ihnen umschalten lassen. Auf der Seite Change the processor gibt es zwei Kerne – den gewöhnlichen, wie bei Wirth, und einen mit der neuen Instruktion CHK –, und auf jedem lässt sich dieselbe Schleife ausführen, die ein Array durchläuft.

Auf dem gewöhnlichen Prozessor braucht ein Array-Zugriff in dieser Schleife elf Takte, von denen zwei auf die Software-Prüfung entfallen. Auf dem Prozessor mit der neuen Instruktion sind es zehn, weil die Prüfung einen Takt statt zwei braucht. Ein Takt von elf, genau wie beabsichtigt. Jener langweilige Satz aus der Risikotabelle hat sich bewahrheitet.

Und das Wichtigste, was diese Seite prüft, sind nicht einmal die Kosten der Prüfung. Das gewöhnliche System, ganz ohne neue Instruktionen, muss auf beiden Prozessoren exakt gleich booten, mit demselben Bild auf dem Bildschirm und derselben Anzahl ausgeführter Instruktionen. Verhalten sich die alten Programme nach dem Hinzufügen der neuen Instruktion auch nur ein wenig anders, dann habe ich die Kompatibilität gebrochen und eine andere Maschine erhalten.

Dreizehn Laborübungen

Da die Maschine im Browser läuft, kann man an ihr lernen. Das Labor umfasst dreizehn Übungen, und jede wird von der Maschine geprüft, statt auf Treu und Glauben angenommen zu werden. Die Prüfung schaut in den Speicher, die Register oder die Festplatte des emulierten Computers selbst und sieht nach, ob Sie getan haben, was verlangt war. Die Übungen sind nach Stufen gegliedert: zuerst nur anschauen, dann verändern, kaputt machen, messen und schließlich selbst bauen.

Und so sieht die Oberfläche von Oberon in Aktion aus. Ein Mittelklick auf den Text System.ShowModules öffnet die Liste der geladenen Module, ein weiterer, auf Hilbert.Draw, zeichnet eine Hilbert-Kurve. Keine Buttons, nur Text:

Standardmäßig öffnet sich das Labor auf Englisch und wechselt per Button oder über einen Link mit ?lang=ru auf Russisch, die Wahl wird gespeichert. Daneben gibt es ein Handbuch mit acht Kapiteln, das damit beginnt, was hier echt ist, und damit endet, was wir gemessen haben; es gibt auch eine englische Fassung. Wenn Sie Rechnerarchitektur unterrichten und diese Übungen für sich übernehmen möchten, schreiben Sie mir, und ich helfe Ihnen beim Einrichten. Sie sind offen, und die Maschine lässt sich mit demselben Tag in Ihre eigene Seite einbetten.

Eine eigene Blamage dieses Abschnitts ist, dass das Labor auf der Website eine Zeit lang tot war. Die Übungsliste war leer, und auf dem Bildschirm drehte sich ein ewiger Spinner. Zuerst fand und behob ich einen Fehler im Code der Seite, aber das half nicht. Die eigentliche Ursache war, dass in der Datei der Seite das schließende Tag eines Scripts fehlte. Ich hatte das für harmlos gehalten – der Browser verzeiht das schon – und sogar dem automatischen Check der Website beigebracht, es ebenfalls zu verzeihen. Nach dem HTML-Standard markiert der Browser ein Script jedoch, wenn eine Datei innerhalb eines nicht geschlossenen Scripts endet, als bereits ausgeführt und führt es schlicht nicht aus, ohne Fehler und ohne Warnung. Inzwischen öffnet der automatische Check die Website in einem echten Browser und verlangt, dass die Seite so viele Übungen hat wie die Quellen. Kurz: Ich sage nicht mehr, dass der Browser alles verzeiht.

Und was kostet die Prüfung auf modernen Prozessoren?

Schön – auf Wirths Prozessor kostet die Software-Prüfung zwei Takte von elf und die Hardware-Prüfung einen einzigen. Aber Wirths Prozessor ist eine sehr einfache Maschine, die eine Instruktion nach der anderen ausführt und nichts errät. Wie sieht es auf den Prozessoren in unseren Laptops und Servern aus?

Ich nahm dieselbe Array-Schleife und schrieb sie in C und in Rust in drei Varianten. In der ersten gibt es überhaupt keine Prüfung, in der zweiten ist sie so geschrieben, wie die Sprache selbst sie schreibt, und in der dritten ist es dem Compiler verboten, sie wegzuwerfen. Alle drei Varianten ließ ich überall laufen, wo ich hinkam. Gleich vorweg, weil man die Zahlen sonst nicht lesen kann: Die Schleife ist absichtlich so gewählt, dass sie für die Prüfung so günstig wie möglich ist. Das Array ist klein und liegt immer im schnellsten Speicher des Prozessors, und die Prüfung geht immer durch, sodass der Prozessor ihr Ergebnis leicht vorhersagen kann. Obendrein habe ich dem Compiler das Vektorisieren verboten – also mehrere Array-Elemente mit einer Instruktion zu verarbeiten –, obwohl Prüfungen in echtem Code vor allem deshalb teuer sind, weil sie genau dabei im Weg stehen. Ich wollte die Prüfung für sich sehen, ohne alles andere.

Erstens hat sich die Prüfung selbst in vierzig Jahren überhaupt nicht verändert – überall ist es derselbe Vergleich mit bedingtem Sprung wie auf Wirths Maschine. Zweitens kostete die Prüfung, so wie die Sprache sie schreibt, nirgends irgendetwas, denn moderne C- und Rust-Compiler fanden selbst heraus, dass der Index in dieser Schleife nie die Grenzen überschreitet, und warfen die Prüfung weg. Wirths Compiler kann das nicht; er lässt die Prüfung immer drin.

Und warum ist die Prüfung auf AMD und Apple unsichtbar, auf dem Server-Arm aber sichtbar? Das halte ich für das interessanteste Ergebnis der ersten Projekthälfte. Ein moderner Prozessor führt mehrere Instruktionen pro Takt aus und ordnet sie selbst um, damit alle seine Ausführungseinheiten beschäftigt sind. Hat ein Programm wenig Arbeit, fallen die zusätzlichen Prüfinstruktionen einfach in die freien Slots und kosten nichts, wie ein Fahrgast, der in einen halb leeren Bus steigt und niemanden bedrängt. Ich habe das überprüft, indem ich der Schleife schrittweise Arbeit und Prüfungen hinzufügte und beobachtete, ab wann die Prüfungen Zeit kosten. Auf AMD kosten eine oder zwei Prüfungen tatsächlich nichts, ab der vierten fangen sie an zu kosten. Auf dem Server-Arm fügt jede Prüfung von Anfang an ein wenig Zeit hinzu, weil dieser Kern weniger freie Slots hat. Wirths Prozessor hat überhaupt keine freien Slots – er führt eine Instruktion nach der anderen aus, und jede Prüfinstruktion ist ein Takt, der immer bezahlt wird.

Was CHERI macht

CHERI ist eine Architektur, in der ein Zeiger seine eigenen Grenzen kennt – er speichert also neben der Adresse, wo der Speicherbereich beginnt und endet, auf den er zugreifen darf, und der Prozessor prüft diese Grenzen bei jedem Speicherzugriff selbst. Ein solcher Zeiger ist doppelt so breit wie eine gewöhnliche Adresse, und ein Programm kann ihn nicht fälschen. Ich wollte CHERI auf dieselbe Leiter stellen, und zwar nicht auf einem großen, komplexen Prozessor, auf dem eine zusätzliche Instruktion alles Mögliche kosten kann, sondern auf dem nächsten Verwandten von Wirths Prozessor. Ich nahm CHERIoT-Ibex, einen einfachen 32-Bit-Kern, der ebenfalls Instruktionen eine nach der anderen ausführt und keinen Cache hat, und ließ dieselbe Schleife auf seiner Schaltung laufen.

Das Ergebnis war sehr aufschlussreich. Auf CHERI kostet die Prüfung in der Schleife keine einzige Instruktion, weil sie in den Speicherzugriff selbst eingebaut ist. Die Schleife mit Schutz ist exakt so lang wie die Schleife ohne. Um sicherzugehen, dass der Schutz wirklich greift, habe ich die Grenzen des Zeigers auf 32 Elemente verengt, und das Programm stürzte genau beim 33. ab. Eine Variante ohne Prüfung gibt es auf CHERI nicht und wird es nie geben, weil es schlicht nichts gibt, womit man sie abschalten könnte. Die veröffentlichten Arbeiten bestätigen das. Auf CHERI ist die Prüfung selbst nahezu kostenlos, bezahlt wird die Zeigerbreite, denn breite Zeiger belegen doppelt so viel Platz im Speicher und im Cache.

So entstand eine Leiter. Auf Wirths Prozessor kostet die Software-Prüfung zwei Instruktionen und zwei Takte, die neue Instruktion CHK eine Instruktion und einen Takt, und CHERI null Instruktionen. Die breiten modernen Prozessoren stehen abseits: Sie haben genauso viele Instruktionen wie Wirths, aber solange der Kern freie Slots hat, kosten diese Instruktionen fast nichts. Und zwischen CHK und CHERI klaffte auf dieser Leiter lange eine Lücke – die ich erst ganz am Ende dieser neun Tage geschlossen habe.

Wirths Maschine in QEMU

Der Browser ist wunderbar, aber ich wollte, dass Wirths Maschine dort lebt, wo gewöhnliche virtuelle Maschinen leben, mit eigener Konsole, Festplatten, Neustarts und allem, was zu einem richtigen Hypervisor gehört. Fast jede VM unter Linux wird auf die eine oder andere Weise von QEMU gestartet, einem Programm, das Computer der unterschiedlichsten Architekturen nachahmen kann. Wirths Prozessor ist natürlich nicht darunter, er musste also von Grund auf geschrieben werden – QEMU musste lernen, sämtliche Instruktionen von RISC5 und seine eigenwillige Gleitkommaarithmetik zu verstehen, und dann musste um den Prozessor herum ein Board zusammengebaut werden, mit Speicher, Festplatte, Tastatur, Maus und Bildschirm.

Wir hatten hier einen Vorteil, den fast niemand hat, der eine neue Architektur für QEMU schreibt. Normalerweise wird die Korrektheit einer solchen Arbeit gegen Dokumentation und Testsuiten geprüft, wir dagegen hatten die Schaltung des Prozessors selbst und einen Referenzemulator, der bereits über fünfzehn Millionen Instruktionen gegen sie geprüft war. Also prüften wir QEMU nicht gegen Papier, sondern gegen die Schaltung, Instruktion für Instruktion, mit derselben Lockstep-Technik. Über anderthalb Millionen Instruktionen des Bootvorgangs fand sich keine Abweichung, das Bild auf dem Bildschirm stimmte bis auf den letzten Punkt mit der Schaltung überein, und die Modulliste, die sich nach einem Klick auf System.ShowModules öffnet, war exakt dieselbe, mit denselben Adressen im Speicher. Die Zahl der dunklen Punkte auf dem Bildschirm nach dem Booten – 18.607 – wurde von da an meine Referenz, und wo auch immer die Maschine lief, verglich ich den Bildschirm damit.

Bauen und starten lässt sich das so (ausführlich im QEMU-Leitfaden):

git clone https://github.com/tym83/paleocomputing && cd paleocomputing
make -C qemu build        # builds QEMU in a Docker container
docker create --name oberon-payload ghcr.io/tym83/paleocomputing/oberon-run:v0.1.17
docker cp oberon-payload:/opt/oberon/payload/prom.bin .
docker cp oberon-payload:/opt/oberon/payload/oberon.dsk .
docker rm oberon-payload
.qemu-work/build/qemu-system-risc5 -machine oberon -bios prom.bin \
  -drive if=none,id=sd0,file=oberon.dsk,format=raw -vnc :0

Der erste Befehl baut QEMU mit unserem Prozessor, die nächsten drei holen den Bootloader und die Systemfestplatte aus einem fertigen Image, und der letzte startet die Maschine. Den Bildschirm sehen Sie mit jedem VNC-Client unter 127.0.0.1:5900, und wenn Sie chk=on an -machine oberon anhängen, bekommen Sie den Prozessor mit der Hardware-Prüfung. Das Booten ohne Hardwarebeschleunigung dauert bis zu einer Minute, erschrecken Sie also nicht, wenn Sie zunächst nur den Bildschirm des Bootloaders sehen.

Warum das ein eigener Build ist und kein Patch für das Mainline-QEMU, sollte ich ebenfalls erklären. Die Projekte QEMU und libvirt nehmen keinen Code an, an dessen Entstehung ein Sprachmodell beteiligt war – selbst wenn das nur vermutet wird. Ich habe ein öffentliches Repository, in dem ehrlich steht, wie es entstanden ist, upstream kann das also nur gehen, wenn jemand den Code von Hand neu schreibt. Die GPL erlaubt einen eigenen Build ausdrücklich, und der schwierigste Teil der Arbeit – eine exakte Beschreibung des Prozessorverhaltens und eine Möglichkeit, jede Implementierung davon zu prüfen – bleibt ohnehin nützlich. Ein weiteres Ärgernis: Unser Prozessor ist gegen die allerneueste Entwicklungsversion von QEMU geschrieben, bereits veröffentlichte Versionen bauen ihn also nicht.

libvirt, das einem nicht aufs Wort glaubt

Die nächste Schicht ist libvirt. Das ist die Bibliothek, über die fast alles, was unter Linux VMs verwaltet, mit QEMU spricht, vom Kommandozeilenwerkzeug virsh bis zu KubeVirt, um das es gleich geht. Die Frage war, ob sich eine neue Architektur ganz ohne Änderungen anbinden lässt. Es ging nicht – aber nicht aus dem Grund, den ich erwartet hatte.

Zuerst trug ich einfach die Architektur risc5 in die Maschinenbeschreibung ein, und libvirt lehnte sofort ab mit dem Hinweis, eine solche Architektur kenne es nicht. Also wurde ich schlau, gab mich als eine Architektur aus, die es kannte, und schob ihm mein eigenes Programm unter. libvirt lehnte wieder ab, diesmal aber tiefer. Es traut nicht dem, was in der Maschinenbeschreibung steht, sondern fragt QEMU selbst, was es nachahmen kann, QEMU nennt sich ehrlich risc5, und diesen Namen gibt es in der Liste von libvirt nicht. Es über die Maschinenbeschreibung zu täuschen, ist unmöglich.

An einer Änderung an libvirt führt also kein Weg vorbei, und die Änderung war winzig – etwa zehn Zeilen an fünf Stellen. Ich habe es so gebaut, dass die Liste der Architekturen aus einer separaten Datei gelesen wird und die nächste alte Maschine eine neue Zeile in dieser Datei ist statt neuen Codes. Der Build prüft jede Änderung einzeln, denn eine Änderung, die sich stillschweigend nicht anwenden ließ, ist schlimmer als gar keine: libvirt würde ohne Fehler bauen, die Architektur aber nicht kennen. Das zahlte sich sofort aus, als in einer neuen Version von libvirt das betreffende Stück Code in eine andere Datei wanderte und der Build das laut verkündete, statt stillschweigend eine kaputte Bibliothek zu bauen.

Und gleich hier eine schöne Geschichte darüber, warum man seinen Augen nicht trauen darf. Der erste Screenshot unter libvirt sah völlig korrekt aus, aber ein byteweiser Vergleich mit der Referenz fand mehrere tausend Unterschiede. Ich verdächtigte nacheinander die Maus, den Zeitpunkt des Screenshots und libvirt selbst – dabei hatte ich schlicht die Adresse des Videospeichers falsch von hexadezimal nach dezimal umgerechnet und um 512 Byte danebengelegen. Das sind genau vier Bildschirmzeilen, und der Unterschied ist mit bloßem Auge völlig unsichtbar. Nach der Korrektur stimmte der Bildschirm Byte für Byte mit der Referenz überein.

KubeVirt ohne Fork

Eine Schicht darüber sitzt KubeVirt. Es erlaubt, virtuelle Maschinen in Kubernetes genauso zu betreiben wie gewöhnliche Container und sie mit denselben Werkzeugen zu verwalten. Im Inneren hat jede solche VM einen Verwaltungs-Pod, und dort leben libvirt und QEMU. Ich musste eine Maschine mit einer völlig anderen Architektur dort hineinschmuggeln, und zwar ohne eine eigene Kopie von KubeVirt oder Cozystack anzulegen. Eine private Kopie eines großen Projekts bleibt für immer an einem hängen, und man muss sie bei jedem Update von Hand mitschleppen, deshalb wollte ich das unbedingt vermeiden.

Zu Hilfe kam ein Standard-Erweiterungspunkt, den nur wenige kennen. Bevor KubeVirt eine VM startet, kann es ihre Beschreibung an einen externen Handler übergeben und dann ausführen, was der Handler zurückliefert. Der Handler kann ein gewöhnliches Skript sein, das in der Kubernetes-Konfiguration liegt, man muss dafür also nicht einmal ein eigenes Image bauen. Unser Handler bekommt die Beschreibung einer ganz gewöhnlichen VM – mit Intel-Prozessor, Festplatten und Netzwerk – und formt sie zu Wirths Maschine um. Er ändert die Architektur, schaltet die Hardwarebeschleunigung ab (die es für eine fremde Architektur ohnehin nicht gibt), setzt unseren Emulator, Bootloader und unser Disk-Image ein und wirft alles hinaus, was Wirths Maschine nicht hat – also fast alles, was KubeVirt standardmäßig hinzufügt.

Den Emulator selbst und das gepatchte libvirt muss man allerdings in das Verwaltungs-Image legen, aus dem KubeVirt alle seine VMs startet. Alles andere erledigen KubeVirt und Cozystack selbst. Für Wirths Maschine braucht der Cluster also genau zwei Dinge, die ein gewöhnlicher Benutzer nicht tun kann: externe Handler erlauben und unser Verwaltungs-Image installieren. Der Administrator stimmt dem einmal zu, und danach installiert jeder Benutzer die Maschine aus dem Katalog, ungefähr so, wie man ein Treiberpaket installiert.

Mit dem Verwaltungs-Image gab es noch eine stille Falle. Wir nehmen das Standard-Image von KubeVirt und ersetzen darin nur libvirt, und die Version unseres libvirt muss exakt der entsprechen, die bereits im Image steckt. Liegt man daneben, baut das Image ohne einen einzigen Fehler, aber unsere Bibliothek landet neben der Standardbibliothek statt an ihrer Stelle, und ausgeführt wird die Standardbibliothek. Deshalb prüft der Build inzwischen, dass im Image genau ein libvirt steckt, und die Zuordnung zwischen KubeVirt- und libvirt-Versionen ist in einer einzigen Datei festgehalten und lässt sich nicht von Hand setzen.

Sechzehn Sekunden bis zur clusterweiten Migration

Das ist wahrscheinlich die lehrreichste Geschichte des Projekts, und sie handelt von meiner eigenen Unaufmerksamkeit; der Code hat damit nichts zu tun.

Das Verwaltungs-Image, aus dem KubeVirt VMs startet, wird für den gesamten Cluster auf einmal festgelegt. Um es auszutauschen, änderte ich die KubeVirt-Konfiguration direkt im laufenden Cluster – unserem Arbeitsstand, auf dem unter anderem die VMs anderer Leute liefen. Sechzehn Sekunden später begann KubeVirt, sämtliche virtuellen Maschinen im Cluster auf das neue Image zu migrieren, ohne sie anzuhalten. Die Sache ist die: In Cozystack sind automatische Updates laufender Maschinen standardmäßig eingeschaltet, und KubeVirt tat genau, was man ihm gesagt hatte – da sich das Verwaltungs-Image geändert hatte, mussten alle Maschinen auf das neue umziehen. Im Laufe von fünf Stunden versuchte es mehr als hundertmal, Maschinen zu migrieren, und mehr als die Hälfte der Versuche scheiterte. Nichts stürzte ab und keine Daten gingen verloren, und die erfolgreichen Migrationen zeigten nebenbei, dass unser Image Maschinen migrieren kann – aber ein schönes Bild war das nicht. So habe ich es gestoppt:

kubectl -n cozy-kubevirt patch kubevirt kubevirt --type=merge \
  -p '{"spec":{"workloadUpdateStrategy":{"workloadUpdateMethods":[]}}}'

Dieser Befehl schaltet automatische Updates der Maschinen ab, ist aber eine Notbremse und keine Lösung. Er bricht bereits laufende Migrationen nicht ab, die Einstellung kommt beim nächsten Cozystack-Update zurück, und ganz ohne automatische Updates auszukommen, ist ebenfalls schlecht, denn nach einem KubeVirt-Update blieben die Maschinen auf dem alten Verwaltungs-Image. Am ärgerlichsten an dieser Geschichte ist, dass ich wusste, wo ich hätte nachsehen müssen. Ich habe nur geprüft, dass das neue Image existiert, und nicht daran gedacht zu prüfen, was es mit dem Cluster anstellen würde.

Warum die Hälfte der Migrationen scheiterte, wurde aus den Logs klar, und mit dem Image hatte das nichts zu tun. Standardmäßig migriert KubeVirt nicht mehr als zwei Maschinen gleichzeitig von einem Server weg; die übrigen warten, bis sie an der Reihe sind, und kommen oft gar nicht dran. Auch Quotas standen im Weg. Während einer Migration existiert eine Maschine gleichzeitig in zwei Kopien und belegt doppelt so viel Speicher, eine Maschine, die das gesamte Quota ihres Benutzers aufgebraucht hat, wird also nie live migriert. Das Quota braucht Spielraum, mindestens so viel wie die größte Maschine.

Ein Katalog für Cozystack

Cozystack ist eine offene Plattform, aus der man auf Basis von Kubernetes seine eigene Cloud zusammenbaut. Wir bei Ænix entwickeln sie gemeinsam mit der Community, und sie gehört zur CNCF, der Foundation, in der auch Kubernetes selbst zu Hause ist. Die Plattform hat eine Weboberfläche, Benutzer – hier Tenants genannt (so etwas wie getrennte Konten in einer Cloud) –, virtuelle Maschinen und einen Anwendungskatalog mit Datenbanken, Kubernetes-Clustern, Caches und so weiter. Und vor Kurzem ist in der Community ein Mechanismus für einsteckbare Kataloge entstanden. Jeder kann seinen eigenen Satz Anwendungen veröffentlichen und in seine Plattform einbinden, und dann erscheinen diese Anwendungen für die Benutzer neben den eingebauten. Für Paleocomputing habe ich genau einen solchen Katalog gebaut und dabei nichts erfunden, was es in der Plattform nicht schon gibt.

Der Katalog ist in vier Teile gegliedert, weil man ihnen unterschiedlich weit vertrauen muss. Der erste enthält die Maschinen und Umgebungen für die Benutzer – die echte VM mit Wirths Prozessor, das Browser-Labor, das Handbuch und ein Bundle, das alles auf einmal installiert. Der zweite enthält die Oberon-Sprachumgebung, in der man Oberon-Programme als gewöhnliche Jobs im Cluster ausführen kann. Der dritte legt Boot-Images in den gemeinsamen Speicher der Plattform, und der vierte tauscht jenes Verwaltungs-Image von KubeVirt aus. Diese beiden letzten betreffen den gesamten Cluster und werden deshalb nur mit ausdrücklicher Zustimmung des Administrators installiert.

Eingebunden wird der Katalog so:

cozypkg tap oci://ghcr.io/tym83/paleocomputing/machines:v0.1.17
cozypkg tap oci://ghcr.io/tym83/paleocomputing/languages:v0.1.17
cozypkg add paleocomputing.machines
cozypkg add paleocomputing.languages
# what touches the whole cluster is installed only with the administrator's explicit consent
cozypkg tap oci://ghcr.io/tym83/paleocomputing/images:v0.1.17
cozypkg tap oci://ghcr.io/tym83/paleocomputing/platform:v0.1.17
cozypkg add paleocomputing.platform --allow-privileged

Der Befehl tap bindet den Katalog nur in die Plattform ein; add installiert seinen Inhalt. Dieser Unterschied hat auch mich einmal verwirrt, und anfangs stand er überhaupt nicht in der Dokumentation.

Bevor Sie den letzten Teil installieren, schauen Sie sich unbedingt die Einstellung für automatische Maschinen-Updates in KubeVirt an. Mit den Standardeinstellungen von Cozystack schickt eine Änderung des Verwaltungs-Images jede VM im Cluster auf Migration, und zwar bei der Installation, bei der Deinstallation und bei jedem KubeVirt-Update. Genau das ist mir passiert. Dieses Loch hat einer der Reviewer beim Prüfen genau dieses Artikels gefunden; ist das automatische Update eingeschaltet, ändert die Komponente deshalb jetzt nichts und wartet, bis der Administrator die Migration ausdrücklich erlaubt. Erlauben lässt sie sich mit der Einstellung allowWorkloadUpdate: true bei der Installation oder mit der Annotation paleocomputing.io/allow-workload-update=true an der KubeVirt-Ressource. Und noch etwas. Das Werkzeug zum Einbinden von Katalogen prüft die digitale Signatur bisher nicht; wenn Sie das also irgendwo installieren, wo es ernster zugeht als auf einem Heim-Prüfstand, prüfen Sie die Signatur selbst – wie, steht in der Anleitung.

Nach dem Einbinden erscheint in den Katalogen der Benutzer ein eigener Bereich Paleocomputing. Allerdings gibt es einen Haken, auf den ich beim Anfertigen der Screenshots für diesen Artikel gestoßen bin. Die aktuelle Weboberfläche von Cozystack zeigt in ihrer Seitenleiste nur drei Bereiche – die, die fest in ihren Code eingebaut sind – und versteckt alle übrigen ganz am Ende der vollständigen Anwendungsliste. Zuerst fand auch ich meinen eigenen Bereich nicht. Dabei ist der ganze Sinn eines einsteckbaren Katalogs, eigene Bereiche mitzubringen, statt sich in fremden aufzulösen. Wir werden das also in Cozystack selbst beheben, und die Oberfläche wird alle Bereiche anzeigen müssen, die ein Katalog mitbringt.

Installiert wird die Maschine über ein Formular in der Weboberfläche oder mit einer kurzen Beschreibung:

apiVersion: apps.cozystack.io/v1alpha1
kind: OberonVM
metadata:
  name: wirth
spec:
  memory: 128Mi
  hardware: chk     # or base, the ordinary Wirth processor

Einen Bildschirm für die Maschine gibt es in der Weboberfläche noch nicht; in den aktuellen Versionen haben ihn nur gewöhnliche VMs. Ansehen können Sie sie mit dem Werkzeug virtctl, mit den Rechten des Benutzers selbst und einem beliebigen VNC-Client:

virtctl -n tenant-sandbox vnc oberon-vm-oberon-vm-habr

Das Ganze ist so angelegt, dass die nächste alte Maschine keinen neuen Code erfordert. Alles, was Wirths Maschine von den anderen unterscheidet, steht in einer kleinen Datei, die ich den Pass der Maschine nenne: Architektur, Emulator, Bootloader, Festplatte, Prozessorvarianten und Speichergrenzen. Alles andere ist gemeinsam, und der Handler für KubeVirt ist für alle Maschinen ein und derselbe – er liest einfach den Pass. Die nächste Maschine, etwa Lilith, ist ein neuer Pass und keine Kopie des Codes. Um zu beweisen, dass das kein leeres Gerede ist, enthalten die Tests eine zweite, fiktive Maschine mit anderer Architektur, und sie baut ohne eine einzige Änderung am Code.

kind: Machine
name: oberon
image: ghcr.io/tym83/paleocomputing/oberon-run:v0.1.17
domain:
  arch: risc5
  machine: oberon
  emulator: /usr/local/bin/qemu-system-risc5
  vcpus: 1
  graphics: vnc
  terminationGracePeriodSeconds: 0
payload:
  path: /payload
  files:
    - {name: prom.bin,   role: firmware, qemu: ["-bios", "{path}"]}
    - {name: oberon.dsk, role: disk,     qemu: ["-drive", "if=none,id=sd0,file={path},format=raw"]}
variants: {base: {}, chk: {chk: "on"}}
memory: {default: 128Mi, min: 128Mi, max: 1Gi}

Alles grün, und nichts funktioniert

Während ich mit dem Cluster hantierte, tauchte dieselbe Falle an einem Abend sechsmal auf, und ich legte eine Notiz mit genau diesem Titel an. Jedes Mal meldete ein Check Erfolg, während in Wirklichkeit nichts funktionierte. Der Katalog ist gebaut, aber die Hauptdatei steckt nicht darin. Die Installation war erfolgreich, aber die Maschine läuft nicht. Der Server antwortet, alles sei in Ordnung, aber das Image enthält die Maschine selbst nicht. Der Build ist grün, aber die Datei, die kopiert wird, existiert nicht. Dann gab es noch ein siebtes Mal – eben jene sechzehn Sekunden.

Am Abend des 27. September gab es eine Episode, für die ich mich bis heute ein wenig schäme. Wir bauten gerade um, wie die Maschine im Cluster beschrieben wird, und die Releases kamen in einer Schlange. Das erste blieb an seinen eigenen Checks hängen. Das zweite hing mausetot, weil die Aufgabe, die die Festplatte der Maschine vorbereitet, darauf wartete, dass die Maschine startet, und die Maschine auf die Festplatte wartete. Das dritte fand zwei weitere Bugs. An diesem Punkt riss mir der Geduldsfaden, und ich fragte den Agenten, warum wir ein Release nach dem anderen ausliefern und ob er die Dinge nicht einfach beim ersten Mal ordentlich prüfen könne (im Original war das deutlicher formuliert).

Er konnte, und danach änderte sich der Release-Prozess. Inzwischen wird jede Änderung zuerst als Testversion gebaut, eine separate Sandbox im Cluster wechselt auf sie, und ein Szenario installiert in der Rolle eines gewöhnlichen Benutzers die Maschine, prüft, dass sie auf dem richtigen Prozessor gestartet ist, vergleicht den Bildschirm mit der Referenz, startet sie neu, löscht sie und bestätigt, dass nichts zurückgeblieben ist. Nur wenn all das durchgeht, landet die Änderung im Hauptzweig und wird zum Release. Ein zweites solches Szenario prüft die Komponente, die das Verwaltungs-Image austauscht, und startet zur Sicherheit ein gewöhnliches Ubuntu auf unserem Image, um zu bestätigen, dass wir die Nachbarn nicht kaputt gemacht haben. Das erste Release, das all das vor der Veröffentlichung bestand, war v0.1.14, und die hängengebliebenen Maschinen kamen danach von selbst hoch.

Amüsanterweise hatte das Szenario selbst eigene Bugs, obwohl das System funktionierte. Zum Beispiel wurde der Start von Ubuntu anfangs über ein Hilfsprogramm im Gast geprüft, das es in einem sauberen Ubuntu-Image schlicht nicht gibt, der Check hätte also ewig gewartet. Dann wurde er über den Login-Prompt auf der Konsole geprüft, und eine Konsole ohne echtes Terminal bleibt stumm. Und die Wartefunktion zählte nur die Pausen, nicht die insgesamt vergangene Zeit, sodass aus zwanzig Minuten Warten zwei Stunden wurden. Das Skript wartete sehr geduldig neben einem längst gebooteten Ubuntu.

Die Komponente, die das Verwaltungs-Image überwacht

Das Verwaltungs-Image von KubeVirt von Hand auszutauschen, ist aus drei Gründen eine schlechte Idee. Es wird von allen VMs des Clusters gemeinsam genutzt, ein Fehler macht also alle kaputt. Es muss zur KubeVirt-Version passen und bleibt nach einem Cozystack-Update alt und macht dann alle Maschinen kaputt. Und meine erste manuelle Methode hat nebenbei mehrere andere KubeVirt-Einstellungen eingefroren, die ich gar nicht anfassen wollte.

Deshalb hat der Katalog eine eigene Komponente, die alle halbe Minute in die KubeVirt-Konfiguration schaut und ihren eigenen Teil in Ordnung bringt. Haben wir ein Image für die aktuelle KubeVirt-Version, installiert sie es. Wenn nicht, entfernt sie ihre Änderung, und der Cluster kehrt zum Standard-Image zurück. Wirths Maschinen starten dann nicht, aber alles andere funktioniert. Sieht irgendetwas fragwürdig aus, entfernt sie ihre Änderung ebenfalls, und konnte sie die Konfiguration nicht lesen, fasst sie nichts an. Ihre Änderung nimmt sie so vor, dass sie, falls KubeVirt jemals die Form seiner Konfiguration ändert, das Image nicht an die falsche Stelle setzt, sondern sich lautstark weigert, angewendet zu werden.

Und auch diese Komponente hat die Sandbox erwischt. Auf dem lebenden Cluster stürzte sie ab, weil sie einem der Werkzeuge Informationen über alle Server des Clusters auf einmal übergab, und auf einem echten Cluster sind diese Informationen riesig. In den Tests waren die Server winzig, und der Testcluster bestand aus einem einzigen, deshalb stürzte dort nichts ab. Inzwischen wird ein Test mit einem Cluster aus dreitausend großen Servern auf dem alten Code rot.

Server mit Intel und mit Arm

Als ich anfing, das alles auch für Arm-Server zu bauen, wurde ich gefragt, wozu überhaupt Builds für verschiedene Prozessoren nötig seien, wenn wir die Oberon-Architektur doch schon zu KubeVirt hinzugefügt haben. Eine gute Frage, und die Verwirrung ist natürlich, denn hier gibt es zwei Architekturen. Die eine ist die Architektur von Wirths Maschine, die QEMU nachahmt, und sie hängt nicht vom Server ab. Die andere ist der echte Prozessor des Servers, Intel oder Arm. Der Emulator und libvirt sind gewöhnliche Programme und müssen für jeden Serverprozessor separat gebaut werden. Das ist wie bei einem Emulator für eine Spielkonsole: Die Konsole ist eine, aber die Builds des Emulators für Windows und für Mac sind verschiedene.

Unser Verwaltungs-Image war nur für Intel gebaut. Und da es für jede VM im Cluster das Standard-Image ersetzt, würde auf einem Cluster aus Arm-Servern keine einzige Maschine starten – nicht nur Oberon. Der Arm-Build ging sofort durch, der eigentliche Start auf Arm blieb aber dreimal stecken. Zuerst, weil das Image mit Bootloader und Festplatte nur für Intel existierte. Dann, weil eines der Build-Werkzeuge ebenfalls nur für Intel veröffentlicht wird. Und das dritte Problem war das interessanteste. Auf Arm gibt KubeVirt einer VM immer moderne Firmware mit eigenem Flash-Speicher, und Wirths Maschine hat überhaupt keinen Flash-Speicher, also beendete sich QEMU sofort nach dem Start. Auf Intel sieht man das nicht, weil dort die Standard-Firmware eine andere ist. Keines dieser drei Probleme war im Code oder im gebauten Image zu sehen – nur auf einem lebenden Server mit dem richtigen Prozessor.

Inzwischen funktioniert all das auf zwei KubeVirt-Versionen und auf beiden Prozessortypen, und der Bildschirm stimmt in allen vier Kombinationen mit der Referenz überein. Der Fairness halber sei gesagt, dass ich auf Arm reines KubeVirt in einem Wegwerf-Testcluster getestet habe; Cozystack auf Arm-Servern habe ich noch nicht laufen lassen.

# 1. allow external handlers (on servers without /dev/kvm you also need useEmulation: true)
kubectl -n kubevirt get kubevirt kubevirt -o json \
  | jq '.spec.configuration.developerConfiguration.featureGates |= ((. // []) + ["Sidecar"] | unique)' \
  | kubectl replace -f -

# 2. install the housekeeping image for your KubeVirt version
git clone --depth 1 -b v0.1.17 https://github.com/tym83/paleocomputing && cd paleocomputing
KV=$(kubectl -n kubevirt get kubevirt kubevirt -o jsonpath='{.status.observedKubeVirtVersion}')
echo "$KV ghcr.io/tym83/paleocomputing/virt-launcher:$KV-paleo-v0.1.17" > /tmp/launchers.txt
kubectl -n kubevirt create configmap kubevirt-paleo-launcher-status
export KUBECTL=kubectl KUBEVIRT_NAMESPACE=kubevirt LAUNCHER_TABLE=/tmp/launchers.txt
R=marketplace/repos/platform/packages/system/kubevirt-paleo-launcher/files/reconcile.sh
until sh $R once && [ "$(kubectl -n kubevirt get cm kubevirt-paleo-launcher-status \
  -o jsonpath='{.data.state}')" = Applied ]; do sleep 10; done

# 3. install the machine with ordinary Helm and open its screen
python3 marketplace/tools/pin-images.py --release v0.1.17
helm install wirth marketplace/repos/machines/packages/apps/oberon-vm \
  -n oberon --create-namespace --set storageClass=<your StorageClass>
virtctl -n oberon vnc oberon-vm-wirth

Die zweite Folge: ein Sprachmodell auf Wirths Prozessor

Erinnern Sie sich an die Behauptung aus jenem allerersten Plan, eine neue Instruktion, die in einem Zug multipliziert und addiert, würde die Geschwindigkeit eines neuronalen Netzes auf Wirths Prozessor verdoppeln? Die Reviewer haben sie zerlegt, aber in meiner Liste aufgeschobener Aufgaben blieb danach eine Zeile mit ihren Schätzungen stehen. Die neue Instruktion würde nach ihrer Rechnung ein paar Prozent bringen, ein schneller Multiplizierer mehr als das Anderthalbfache. Das klang nach einem Ergebnis, aber hinter diesen Zahlen standen weder ein Programm noch eine Möglichkeit, sie nachzuvollziehen – nur Arithmetik anhand der Takttabelle. Ich wollte das von Anfang an von Hand überprüfen.

Die Aufgabe lief auf Folgendes hinaus. Ein kleines Sprachmodell sollte im Oberon-System selbst laufen. Ein Programm in Oberon, übersetzt mit dem systemeigenen Compiler, liest die Gewichte des Modells aus einer Datei und gibt Text aus, und all das läuft auf Wirths echter Schaltung, Takt für Takt. Und dann müsste ich herausfinden, wohin die Zeit geht, und beide Schätzungen der Reviewer überprüfen.

Wirths Maschine hat nicht viel Speicher – ein Megabyte für alles, den Bildschirm eingeschlossen –, das Modell fiel also wirklich winzig aus. Es sagt den nächsten Buchstaben aus den vorangegangenen acht vorher und hat etwa dreiundvierzigtausend Parameter. Zum Vergleich: Die Modelle, mit denen wir chatten, haben millionenfach mehr. Und doch belegt selbst ein solches Modell fast die Hälfte des freien Speichers der Maschine. Trainiert habe ich es auf einem gewöhnlichen Laptop in ein paar Dutzend Sekunden, mit dem Text von Alice’s Adventures in Wonderland, der längst gemeinfrei ist.

Das schreibt das Modell, wenn man es mit alice was startet:

alice was one thought all the tell you spo

Shakespeare kann ruhig schlafen. Uns interessiert hier aber nicht die Literatur, sondern die Stoppuhr.

Die Hauptanforderung war, dass der Text, den das Modell auf Wirths Schaltung ausgibt, Byte für Byte mit einer Referenz übereinstimmt, die auf einem gewöhnlichen Computer berechnet wurde. Dafür durfte die Referenz nicht mit den üblichen Python-Mitteln berechnet werden, sondern in exakt derselben Arithmetik wie auf Wirths Prozessor, wobei jede Operation in derselben Reihenfolge wiederholt wird. Andernfalls hätte nichts übereingestimmt. Ich habe gesondert ausgerechnet, wie weit Wirths Arithmetik vom Standard abweicht, und festgestellt, dass sich fast alle Zwischenwerte in den letzten Stellen unterscheiden. Der erzeugte Text wich dabei allerdings kein einziges Mal ab, aber das ist schlichtes Glück. Ein Vergleich gegen gewöhnliches Python hätte fast immer gestimmt und eines Tages unerklärlich danebengelegen – die schlimmste Sorte Bug, weil er sich weder reproduzieren noch erklären lässt.

Der Text stimmte überall überein. Auf dem Emulator, wo dieser Check inzwischen bei jeder Änderung automatisch läuft; auf Wirths Schaltung; auf der Schaltung mit dem schnellen Multiplizierer, zu dem gleich mehr; und im echten System mit Fenstern. Programm und Gewichte werden auf die Festplatte gelegt, zwei Mittelklicks übersetzen erst das Programm und starten dann die Generierung, und der fertige Text wird von der Festplatte gelesen und stimmt mit der Referenz überein. In QEMU ebenso.

Wohin die Zeit geht

Auf Wirths Prozessor mit seinem nativen Multiplizierer gibt das Modell etwa neun Buchstaben pro Sekunde aus. Auf einer lebenden Maschine, auf der der Videocontroller etwas Prozessorzeit beansprucht, etwas weniger. Kurz: neun Buchstaben pro Sekunde, mit Glück.

Als ich mir ansah, womit der Prozessor die ganze Zeit beschäftigt war, ergab sich ein sehr klares Bild. Fast vierzig Prozent aller Takte gehen auf Gleitkommamultiplikation, und den größten Teil dieser Zeit wartet er einfach darauf, dass der langsame Multiplizierer fertig zählt. Wirths Multiplizierer arbeitet seriell und berechnet das Produkt mit einem Bit pro Takt, eine einzige Multiplikation dauert also sechsundzwanzig Takte. Ein weiteres Viertel der Zeit geht auf das Lesen aus dem Speicher. Und hier zeigte sich noch etwas Interessantes. Die einfachste Zeile des Programms, in der ein Produkt zu einer Summe addiert wird, macht Wirths Compiler zu siebenundzwanzig Instruktionen, von denen nur vier nützlich sind. Der ganze Rest ist Lesen und Schreiben der Summe im Speicher, der Schleifenzähler und – ja – wieder Bounds- und NIL-Prüfungen. Die Sache ist die: Wirths Compiler kann Variablen nicht in den Registern des Prozessors halten und geht jedes Mal in den Speicher, um sie zu holen. Einer der Reviewer hatte das am ersten Tag aus den Quellen vorhergesagt und die Taktzahl fast genau erraten. Das ist übrigens kein Versehen, sondern bewusste Einfachheit: Wirths gesamter Compiler hat weniger als dreitausend Zeilen und baut sich in Sekunden selbst, und eine komplexe Optimierung passte schlicht nicht in dieses Budget.

Der schnelle Multiplizierer

Da alles auf den Multiplizierer hinausläuft, habe ich einen schnellen geschrieben. Er tut dasselbe wie Wirths, aber nicht ein Bit pro Takt, sondern alles auf einmal, in einem oder zwei Takten – mit Rundung und anderen Feinheiten exakt nach Wirths Vorbild nachgebaut. Eingeschaltet wird er genauso wie die Instruktion CHK, mit einem einzigen Schalter beim Bauen des Prozessors.

Die Hauptanforderung an ihn war so streng wie an alles andere: Die Ergebnisse müssen bis aufs letzte Bit mit Wirths Multiplizierer übereinstimmen. Ich habe zig Millionen Zahlenpaare durchgejagt, einschließlich aller unangenehmen Grenzfälle, und keine einzige Abweichung gefunden. Und um sicherzugehen, dass der Check überhaupt Fehler bemerken kann, habe ich die Rundung an einer Stelle absichtlich verdorben, und er fand Zehntausende Abweichungen.

Mit dem schnellen Multiplizierer lief das Modell 1,6-mal schneller – etwa vierzehn Buchstaben pro Sekunde statt neun. Die Schätzung aus dem Profil hatte genau das vorhergesagt, aber auf einer einfachen Maschine ohne Caches ist das eher eine Bestätigung, dass das Profil richtig berechnet wurde, als eine echte Vorhersage. Selbst wenn die Multiplikation völlig kostenlos würde, ließe sich das Programm nicht um mehr als das 1,64-Fache beschleunigen, weil die übrigen Takte ja nicht verschwinden. Die Zahl der Reviewer hat sich also nicht ganz bewahrheitet, aber in der Hauptsache hatten sie recht: Der Multiplizierer war tatsächlich der Engpass.

Für die gewöhnliche Arbeit des Systems bringt der schnelle Multiplizierer allerdings überhaupt nichts. Der Compiler, der sich selbst baut, führt in vierzig Millionen Instruktionen ganze einunddreißig Gleitkommamultiplikationen aus, und der Systemstart keine einzige. Der langsame Multiplizierer war eine völlig vernünftige Wahl für eine Maschine, auf der man Text schreibt und Programme baut. Das Sprachmodell war die erste Aufgabe, für die er zum Engpass wurde.

Und was ist mit der neuen Instruktion, die multipliziert und addiert, mit der alles angefangen hat? Implementiert habe ich sie nicht; ich habe sie anhand der Zähler abgeschätzt. Auf Wirths gewöhnlichem Multiplizierer würde sie anderthalb bis sechs Prozent bringen, auf dem schnellen bis zu zehn. Der Haupthebel ist hier also nicht die neue Instruktion, sondern ein Compiler, der lernt, die Summe in einem Register zu halten, statt für sie in den Speicher zu laufen. Das habe ich aber nicht mehr gemessen.

In Hardware fiel der schnelle Multiplizierer sogar kleiner aus als der native, weil ein FPGA fertige Hardware-Multiplikationsblöcke hat (seine DSP-Slices) und die ganze Logik für das serielle Zählen einfach wegfiel. Die Ein-Takt-Variante senkt allerdings die Höchstfrequenz des Prozessors spürbar, während die Zwei-Takt-Variante fast genauso schnell ist und die Frequenz nicht berührt. Die nativen 25 MHz halten in beiden Fällen mit großer Reserve, wählen müsste man also nur, wenn jemand Wirths Maschine übertakten wollte.

Zwei Funde am Wegesrand

Der erste Fund betrifft den Vergleich von Gleitkommazahlen. Wirths Compiler vergleicht sie genauso wie Ganzzahlen, über eine Subtraktion und eine Prüfung der Prozessor-Flags, und bei einigen Vergleichen verwendet er das Overflow-Flag. Nur wird dieses Flag ausschließlich von Ganzzahloperationen verändert. Ist also irgendwo im Programm vor einem Vergleich von Gleitkommazahlen eine Ganzzahl übergelaufen, kann der Vergleich eine falsche Antwort liefern. Ich habe das mit einem sehr einfachen Programm geprüft. Zuerst sagt es ehrlich, dass eins kleiner als zwei ist; dann lässt es eine Ganzzahl überlaufen; und danach meldet es ebenso selbstbewusst, eins sei nicht kleiner als zwei. Das lässt sich sowohl auf dem Emulator als auch auf der Schaltung reproduzieren. Mein Modell hat keine Überläufe, und die Referenz prüft das. Neuheit beanspruche ich hier nicht: Bestimmt hat das schon jemand gesehen; korrigieren Sie mich, wenn Sie wissen, wo.

Der zweite Fund war lustiger. Das Modell musste eine Textdatei auf die Festplatte speichern, und dabei stellte sich heraus, dass im ganzen Projekt noch nie jemand etwas in unser QEMU geschrieben hatte, weil der Systemstart nur von der Festplatte liest. Und schreiben konnte es nicht, weil die Festplatte ohne Schreibrecht eingebunden war, und der allererste Versuch, irgendetwas zu speichern, riss QEMU komplett mit sich. Obendrein legt das Dateisystem von Oberon neue Daten hinter das Ende der Festplatte, und das Disk-Image war genau so groß wie das, was das System belegte, sodass die Datei auch noch stillschweigend nicht gespeichert wurde.

Als ich das behoben hatte und die Maschine in Kubernetes startete, funktionierte das Schreiben immer noch nicht – diesmal wegen der Dateiberechtigungen. Die Aufgabe, die die Festplatte der Maschine auf ihr Volume legt, sollte das Schreiben erlauben, tat es aber auf eine Weise, die tatsächlich gar nichts erlaubte. Die ganze Zeit über war die Festplatte im Cluster schreibgeschützt, und hätte jemand in Oberon eine Datei gespeichert, wäre die Maschine abgestürzt. Bemerkt hat es niemand, weil niemand etwas speicherte. Inzwischen werden die Berechtigungen explizit gesetzt, auch auf bereits angelegten Festplatten, und das Prüfszenario in der Sandbox fragt QEMU selbst, ob es die Festplatte zum Schreiben geöffnet hat.

Alle Details, Tabellen und Befehle zum Nachvollziehen stehen in der Beschreibung der Folge, und das Wesentliche lässt sich in ein paar Minuten mit cd impl && make lm-check && make lm-profile reproduzieren.

Deskriptoren, zwischen CHK und CHERI

Die Instruktion CHK prüft einen Index gegen eine Länge, die der Compiler in die Instruktion selbst eingebrannt hat, der Compiler muss die Array-Länge also im Voraus kennen. CHERI hält die Grenzen im Zeiger, und die Prüfung lässt sich weder vergessen noch umgehen. Zwischen diesen beiden Extremen standen historisch noch Deskriptoren, wie in eben jener Burroughs B5000 aus den frühen Sechzigern. Ein Deskriptor ist ein Zeiger, der die Array-Länge mit sich trägt, und der Prozessor prüft ihn bei jedem Zugriff, sodass der Compiler nichts mehr im Voraus wissen muss. Ich wollte diese Sprosse auf die Leiter setzen und sie auf demselben vollständig offenen System messen.

Schon die allererste Beobachtung engte die Aufgabe stark ein. In Oberon kennt der Compiler die Länge fast jedes Arrays im Voraus, weil die Sprache schlicht keine Zeiger auf Arrays und keine Arrays variabler Länge kennt. Es gibt eine Ausnahme: wenn ein Array an eine Prozedur übergeben wird, die ein Array beliebiger Länge entgegenzunehmen bereit ist. Innerhalb einer solchen Prozedur ist die Länge nicht im Voraus bekannt, und genau dort hat ein Deskriptor etwas zu tun. Überall sonst kommt CHK bereits zurecht.

Den Deskriptor habe ich in ein gewöhnliches 32-Bit-Wort gepackt. Wirths Prozessor hat eine 24-Bit-Adresse, die Maschine aber nur ein Megabyte Speicher, und für ein Megabyte reichen zwanzig Bit, also gab ich die übrigen zwölf Bit der Array-Länge – bis zu etwas über viertausend Elemente. Dazu eine neue Instruktion, die einen Deskriptor und einen Index nimmt, die Adresse des Elements berechnet und, wenn der Index über die Länge hinausläuft, zum Fehlerbehandler springt. Eine gewöhnliche Adresse, die anstelle eines Deskriptors übergeben wird, sieht aus wie ein Array der Länge null, sodass jeder Zugriff darüber sofort als Fehler behandelt wird. Das ist das nächste Analogon zur zentralen Regel von CHERI – ohne Berechtigung kein Zugriff –, das sich ohne spezielles Hardware-Tag bauen lässt.

Die neue Instruktion wurde so streng geprüft wie CHK: mit denselben absichtlichen Sabotagen, Lockstep-Vergleich gegen den Emulator und einem Check, dass das gewöhnliche System auf einem Prozessor mit der neuen Instruktion genauso bootet wie auf dem gewöhnlichen. Und wieder log der erste Versuch. Der Lauf mit absichtlichen Sabotagen meldete zunächst, er habe alle erwischt. Das Skript, das die Sabotagen einbaute, stürzte selbst ab, die Schaltung baute nicht, und die Tatsache, dass nichts gebaut wurde, zählte als erwischte Sabotage. Inzwischen gilt eine Schaltung, die nicht baut, als gescheiterter Check, nicht als bestandener.

Auf derselben Schleife wie auf der Seite mit den zwei Kernen erwies sich der Deskriptor als der schnellste von allen – schneller sogar als die Variante ganz ohne Prüfungen, acht Takte pro Zugriff gegenüber neun. Ein Wunder ist das nicht. Die neue Instruktion berechnet auch die Adresse des Array-Elements, wofür gewöhnlich zwei weitere Instruktionen nötig sind, und hätte ich eine identische Instruktion ohne Prüfung gebaut, liefe sie genauso schnell. Die Lehre ist hier eine andere, und sie gefällt mir: Wenn die Grenze mit dem Zeiger mitreist, lässt sich die Prüfung in einer Instruktion verstecken, die man ohnehin braucht. Genau so ist es in CHERI gelöst, wo die Prüfung im Speicherzugriff steckt.

Als Nächstes brachte ich dem Compiler bei, Deskriptoren dort zu verwenden, wo die Länge nicht im Voraus bekannt ist, und ließ das System sich mit dem neuen Compiler neu bauen. Es baute sich neu, und die nächste Compiler-Generation stimmte Byte für Byte mit der vorherigen überein. Das ist ein wichtiger Check, denn hätte der Compiler irgendwo vergessen, einen Deskriptor wieder in eine gewöhnliche Adresse zu verwandeln, wäre die Adresse falsch gewesen und es hätte keine Übereinstimmung gegeben.

Und dann fand das echte System zwei Grenzen, auf die ich selbst nie gekommen wäre. Die erste betrifft die Array-Länge. Im gesamten Project Oberon gibt es kein einziges Array mit mehr als viertausend Elementen, aber in den Werkzeugen, mit denen ich es gebaut habe, tauchte ein Puffer mit sechzehntausend Elementen auf, und der Compiler weigerte sich ehrlich, ihn zu bauen, statt die Länge stillschweigend abzuschneiden. Die zweite Grenze war interessanter. Als ich viele Module in einem Lauf baute, wuchs der Speicher im Emulator über ein Megabyte hinaus, mein Deskriptor kann aber nur ein Megabyte adressieren, also blieb der Build einfach hängen, und zwar stillschweigend. Daraus folgt eine sehr aufschlussreiche Schlussfolgerung. Ein Zeiger mit Grenzen lässt sich nicht in die Breite einer gewöhnlichen Adresse quetschen, denn sobald mehr Speicher da ist, bleibt kein Platz mehr für die Länge. Genau deshalb sind die Zeiger von CHERI doppelt so breit wie eine Adresse und komprimieren die Grenzen obendrein geschickt.

Was kostet diese ganze Konstruktion bei großen Lasten? Bei einem synthetischen Programm, das intensiv mit Arrays unbekannter Länge arbeitet, bringen Deskriptoren eine Beschleunigung um etwa ein Viertel, aus demselben Grund wie in der Schleife: Sie sparen bei der Adressberechnung. Beim Compiler dagegen – einem echten Programm – bringen sie eine winzige Verlangsamung, unter einem Prozent, und ich habe ziemlich lange gesucht, woher sie kommt, denn rechnerisch hätte es eine Beschleunigung sein müssen. Mit Deskriptoren hatte das nichts zu tun: Jedes Mal, wenn das Programm einer Prozedur einen String übergibt, baut der Compiler jetzt einen Deskriptor dafür zusammen, wodurch der Code etwas länger wurde, und das System verbringt etwas mehr Zeit mit dem Laden von Modulen. Hätte der Compiler die String-Deskriptoren im Voraus vorbereitet, wäre das nicht passiert, aber das habe ich nicht mehr umgesetzt.

Auf dem FPGA hält der Prozessor mit Deskriptoren weiterhin seine 25 MHz, hat etwa fünf Prozent mehr Logik, und die neue Instruktion landete zum ersten Mal auf dem kritischen Pfad der Schaltung – ihrem längsten Signalweg –, könnte also künftig die Frequenz begrenzen. CHK hat das kein einziges Mal getan.

Am Ende sieht die Leiter so aus:

Ein Deskriptor entfernt die Prüfung aus der Schleife genauso wie CHERI, hat in Oberon aber fast nichts zu schützen, was CHK nicht schon schützt. Und das Entscheidende, was ihn von CHERI unterscheidet: Ein Deskriptor bleibt eine gewöhnliche Zahl, und ein Programm, dem Low-Level-Operationen erlaubt sind, kann aus beliebiger Länge und beliebiger Adresse jeden beliebigen Deskriptor zusammenbauen. Genau hier setzt CHERI ein spezielles Tag, das sich nicht fälschen lässt. Ein vollständig mit Deskriptoren gebautes System habe ich auf der echten Schaltung noch nicht gebootet; diesen Prozessor gibt es auch noch nicht im Browser oder im Katalog; und alle Details und Befehle zum Nachvollziehen stehen in der Beschreibung der Folge.

Wie Sie das alles selbst installieren

Es gibt vier Wege, vom allereinfachsten, bei dem Sie nichts installieren müssen, bis zur eigenen Cloud.

Am einfachsten ist es, das Labor im Browser zu öffnen und zumindest die ersten vier Übungen zu machen. Sie sehen, wie eine Oberfläche funktioniert, in der jeder Text ein Befehl sein kann, schreiben Ihr erstes Modul und machen die Maschine kaputt, indem Sie Müll direkt in den Bildschirmspeicher schreiben. Wenn Sie keine Übungen wollen, finden Sie auf der Seite Just run the system das nackte System, und auf der Seite Change the processor sehen Sie die Kosten einer Prüfung mit eigenen Augen. Die mittlere Maustaste wird durch einen Klick mit Alt ersetzt, der Zwei-Tasten-Akkord durch einen Klick mit Shift. Von dem, was man selbst ausprobieren sollte, empfehle ich einen Mittelklick auf System.ShowModules, um zu sehen, wie wenige Module das System nach dem Booten braucht, und auf Hilbert.Draw, weil es einfach hübsch ist. Und dann die Laborübungen zwölf und dreizehn, die am stärksten hardwarenahen: In der einen messen Sie die drei Prozessorvarianten selbst, in der anderen fügen Sie der Sprache eine neue eingebaute Prozedur hinzu und bauen den Compiler direkt im System neu.

Wenn Sie Wirths Maschine als gewöhnliche VM möchten, bauen Sie sich Ihr eigenes QEMU mit den Befehlen aus dem QEMU-Abschnitt oder nach dem Leitfaden. Dort lohnt es sich, die Prozessorvarianten mit Hardware-Prüfung und mit Deskriptoren auszuprobieren.

Wenn Sie ein eigenes KubeVirt haben, gibt es einen Leitfaden und die Kurzfassung im Spoiler oben. Unterstützt werden die beiden neuesten KubeVirt-Versionen sowie Server mit Intel und mit Arm. Sie können mit einem Wegwerf-Testcluster beginnen; dasselbe Szenario, das der automatische Check ausführt, lässt sich von Hand starten. Und ich wiederhole die Warnung noch einmal, weil ich mich selbst daran verbrannt habe: Das Verwaltungs-Image wird für alle VMs des Clusters auf einmal geändert, prüfen Sie auf einem Arbeitscluster also zuerst, ob automatische Maschinen-Updates eingeschaltet sind.

Und wenn Sie Cozystack haben, genügt es, den Katalog mit den Befehlen aus dem Cozystack-Abschnitt einzubinden, und Ihre Benutzer bekommen Wirths Maschine, das Labor, das Handbuch und ein Bundle, das alles auf einmal installiert. Die Details stehen auf der Projektseite. Wenn Sie Studierenden oder Kollegen zeigen müssen, wie ein ganzer Computer aufgebaut ist, ist das wahrscheinlich der schnellste Weg. Was die automatischen Maschinen-Updates angeht: Die Komponente fragt inzwischen selbst danach und fasst ohne ausdrückliche Zustimmung nichts an.

Und wenn Sie uns auf die Finger schauen möchten, führt der Befehl cd impl && make deps && make check in etwa acht Minuten sämtliche Prozessortests, den Systemstart, den Lockstep-Vergleich gegen die Referenz, den Selbst-Build des Compilers und einen Neubau des gesamten Systems mit byteweisem Vergleich aus. Dafür brauchen Sie Verilator und einen C++-Compiler.

Was ich daraus mitgenommen habe

Erstens, zur Bounds-Prüfung. Sie ist billiger, als man gemeinhin denkt, aber völlig kostenlos würde ich sie nicht nennen. Auf Wirths Prozessor – sehr einfach, ohne Caches, ohne Sprungvorhersage – kostete sie den Compiler zwischen zwei und fünf Prozent der Zeit, je nachdem, aus welchem Teil des Systems man sie entfernt. Und der Großteil dieser Kosten entfällt auf Nullzeiger-Prüfungen, nicht auf Prüfungen von Array-Grenzen. Auf großen modernen Prozessoren ist sie in meiner absichtlich günstigen Schleife unsichtbar, weil die zusätzlichen Instruktionen in freie Slots fallen; auf dem Server-Arm ist sie sichtbar, wenn auch nur ein wenig. In echten Programmen sind Prüfungen vor allem deshalb teuer, weil sie den Compiler daran hindern, Arrays stapelweise zu verarbeiten, und das habe ich nicht gemessen. CHERI versteckt die Prüfung direkt im Speicherzugriff, und dann gibt es im Programm überhaupt keine Prüfung mehr.

Zweitens: Der Engpass liegt oft nicht dort, wo man ihn sucht. Für das neuronale Netz wollten alle, ich eingeschlossen, eine clevere neue Instruktion, dabei war der Engpass der alte langsame Multiplizierer. Ihn zu ersetzen, beschleunigte das Modell um das 1,6-Fache, während die neue Instruktion schätzungsweise ein paar Prozent gebracht hätte. Die Reviewer haben das am allerersten Tag gesagt, und eine Messung eine Woche später hat es bestätigt. Erst messen, dann Hardware hinzufügen.

Drittens: Ein Zeiger, der seine eigenen Grenzen kennt, muss breiter sein als eine gewöhnliche Adresse. Meine Deskriptoren, in ein gewöhnliches Wort gepackt, stießen an ein Megabyte Speicher und Arrays mit bis zu viertausend Elementen, und genau deshalb sind die Zeiger von CHERI doppelt so breit.

Viertens: Die fiesesten Bugs findet nur eine lebende Umgebung. Meine Tests waren gut, aber die interessantesten Dinge fanden echtes KubeVirt, echtes Cozystack und ein lebender Arm-Server – von einer Maschine, die keine Energieverwaltung braucht, über eine Netzwerkschicht, die stillschweigend nicht antwortet, bis zu sechzehn Sekunden, bevor der ganze Cluster migrierte. Seitdem veröffentliche ich eine neue Version nur, wenn sie vorher einen vollständigen Check in der Sandbox bestanden hat.

Und fünftens: Ein neuronales Netz schreibt Code schnell und beweist langsam, dass er funktioniert. Neun Tage für all das waren nur möglich, weil den Code Agenten geschrieben haben. Aber mehr als die Hälfte dieser Tage ging darauf, den Checks beizubringen, ehrlich zu erröten, und zu jeder hübschen Zahl gab es einen Auditor – ebenfalls ein Agent –, der sie zerlegte. Ist ein Check noch nie rot geworden, prüft er höchstwahrscheinlich gar nichts, vor allem wenn man sich sehr wünscht, dass alles klappt. Und eine eigene offene Frage ist, was man mit solchem Code in Open-Source-Projekten macht. QEMU und libvirt nehmen ihn überhaupt nicht an; die CNCF dagegen sieht das gelassen; und wie Open Source damit leben soll, ist noch nicht recht klar.

Statt eines Schlussworts

All das ist offen. Die Quellen liegen im Repository, unser Code unter der Apache-2.0-Lizenz und der Prozessor für QEMU unter der GPL, wie QEMU selbst. Die Website mit dem Labor ist tym83.github.io/paleocomputing. Jeder Fund samt Befehlen zum Nachvollziehen steht im Repository im Ordner impl/docs, und über Cozystack selbst können Sie auf cozystack.io lesen.

Als Nächstes in der Reihe: die Burroughs B5000 mit ihrem Hardware-Speicherschutz; Lilith, Wirths allererste Maschine, die nur einen neuen Pass brauchen wird; und, sofern die Geduld reicht, mein eigenes Board mit Oberon auf einem FPGA, um die Takte endlich nicht in der Simulation, sondern auf echter Hardware zu messen.

Wenn Sie Oberon in der Lehre einsetzen oder einfach einmal darin geschrieben haben, erzählen Sie es mir in den Kommentaren – ich bin sehr neugierig, wo es heute lebt. Und korrigieren Sie mich unbedingt, wenn ich mich irgendwo geirrt habe; nach diesem Artikel zu urteilen, passiert mir das regelmäßig.

Eine kurze Umfrage: Was machen Sie nach diesem Artikel?

• Das Labor öffnen und die Maschine kaputt machen, indem ich Müll in den Bildschirmspeicher schreibe
• Auf meinem eigenen Cluster die automatischen Updates der VMs prüfen. Und zwar sofort
• Alles in Oberon neu schreiben (Go ist im Grunde Oberon, nur mit Goroutinen)
• Für ein paar Prozent weiterhin die Bounds-Prüfung abschalten
• Ich habe schon in den Neunzigern darin geschrieben und habe in den Kommentaren etwas zu sagen
• Bis zur Umfrage durchgehalten, was an sich schon eine Leistung ist

P.S. Ein besonderer Dank an Niklaus Wirth. Ich bin ihm nie begegnet, aber neun Tage lang habe ich mit seiner Schaltung gesprochen, und sie hat mich fast nie belogen. Im Gegensatz zu meinen eigenen Checks.

Spoiler: Aus der vollen Autonomie wurde nichts, und ich habe mich mit dem Projekt ziemlich herumgeschlagen. Aber der Prozess hat mich völlig gepackt, und das Ergebnis hat alle meine Erwartungen übertroffen.

Aus der Community kam immer wieder die Frage, wie das eigentlich gelaufen ist. Eine berechtigte Frage — bei diesem Projekt habe ich sehr viel darüber gelernt, wie man Modelle wirksam führt, und dabei sind etliche Methoden und Muster herausgekommen, die mich seither auch in der täglichen Arbeit deutlich produktiver machen.

Was Blockstor ist

Ich habe das Projekt Blockstor genannt. Es ist ein Orchestrator für Blockgeräte. Grob gesagt: Sie fordern ein repliziertes Volume in der gewünschten Größe an, und dieses Volume wird auf mehreren Knoten in ZFS oder LVM angelegt und per DRBD für die Replikation eingerichtet — eine intelligente, netzwerkbewusste Variante von RAID 1. Das System beherrscht Snapshots, das Umverteilen von Repliken, Resize, automatisches Failover und einiges mehr.

Blockstor ist kein Speichersystem, das auf einem leeren Blatt entworfen und geschrieben wurde. Ich habe das Experiment auf LINSTOR aufgebaut — einem ausgereiften Manager für verteilten Blockspeicher, den ich selbst seit Jahren im Produktivbetrieb fahre.

LINSTOR kam für mich einem idealen Speichersystem sehr nahe, weil seine API-Typen Kubernetes-ähnlich sind. Die Backend-Logik ist allerdings recht eigenwillig organisiert. Das Hauptproblem ist aus meiner Sicht das anfragegetriebene Modell: Für die meisten API-Aufrufe geht LINSTOR in Echtzeit zu den Knoten und fragt deren aktuellen Zustand ab, um eine Antwort zusammenzubauen. Für ein verteiltes System halte ich dieses Muster für nicht akzeptabel, weil es bei Skalierung nicht trägt. Das Fehlen eines Reconciliation-Loops macht außerdem die automatische Wiederherstellung schwierig. Ich will die Entscheidungen der Entwickler nicht im Nachhinein bewerten — sie hatten sicher ihre Gründe. Aber weil ich Kubernetes-Mustern so verbunden bin, habe ich mich gefragt: Wie würde ich — als erfahrener Architekt und Entwickler — ein solches System in Kubernetes-nativer Logik schreiben?

Umschreibungen von einer Sprache in eine andere sind übrigens keine Seltenheit. So ist zum Beispiel das Projekt rusternetes entstanden: Kubernetes, neu geschrieben von Go nach Rust. Aber wie soll das überhaupt gehen? Kubernetes hat eine gewaltige Codebasis mit einer gewaltigen Zahl an Personenstunden darin. Wie überzeugt man sich davon, dass der dabei entstehende „KI-Schrott“ korrekt funktioniert? Und kann man sich überhaupt darauf verlassen, geschweige denn ihn produktiv betreiben?

TDD

Die Antwort liegt darin, wie Kubernetes selbst offen entwickelt wird. Freie, community-getriebene Projekte haben einen festen Bestand an etablierter Praxis, und die Beitragenden halten sich nach Kräften daran.

An solchen Projekten arbeiten die unterschiedlichsten Leute mit, auf jedem Erfahrungsniveau. Genau deshalb sind Tests entscheidend: Tests verhindern, dass eine einmal beigesteuerte Funktionalität später wieder kaputtgeht. Angenommen, Sie bringen ein neues Feature ein, es besteht alle Tests und landet im Projekt. Später bringt jemand anderes ein weiteres Feature ein. Fällt beim Prüfen dieses Beitrags ein Test für Ihr Feature durch, dann hat die neue Funktionalität ein Problem, das Ihres beschädigt — und das System lässt die Änderung automatisch nicht durch. Tests haben in öffentlichen Projekten mit der Zeit einen so hohen Stellenwert bekommen, dass sie heute höher bewertet werden als der Code selbst. Genau solche Tests sind es, die ein „X in Y neu schreiben“ überhaupt möglich machen.

Das Projekt rusternetes gibt an:

Actively conformance-tested against the official Kubernetes e2e test suite — currently passing 94% of conformance tests (415/441) across 160 rounds of testing.

Ob ein Projekt als Kubernetes-Ersatz durchgeht, misst sich also in erster Linie daran, ob es die Tests besteht.

Wenn ich einen Vogel sehe, der wie eine Ente läuft, wie eine Ente schwimmt und wie eine Ente schnattert, dann nenne ich diesen Vogel eine Ente.

— Der berühmte Ententest

Hooks und Setup

Aus demselben Grund war mein erster Schritt, das Modell auf testgetriebene Entwicklung (TDD) festzulegen, bei der die Tests vor der Implementierung entstehen. Über Tests lassen sich die Konformitätsanforderungen festzurren, die man braucht. Und sie geben mir die Sicherheit, dass neue Funktionalität, die während der Entwicklung dazukommt, das Bestehende nicht beschädigt.

Auf Rat eines Kollegen habe ich sofort golangci-lint eingebunden und es für das Modell verbindlich gemacht, jeden Code dort durchlaufen zu lassen. @lexfrei — der besagte Kollege — argumentiert, dass dieser Schritt eine erhebliche Menge Tokens spart.

Das Exit Gate und ein deterministisches Ergebnis

Das ist wohl die erste und wichtigste Lektion: Man kann einem Modell sagen „schreib weiter, bis die Tests grün sind“, und das ist eine gute Bedingung an das Artefakt, das dabei herauskommt. Genau nach dieser Methode habe ich dieses Projekt gebaut. Mit einem Haken: Ich hatte keine Tests, denn LINSTOR veröffentlicht keine Test-Suite für die eigene Funktionalität.

Zur Verfügung standen mir nur Jahre im Betrieb von LINSTOR, Dutzende eigener Vorträge und Artikel sowie der Apache-2.0-Code von Projekten aus dem LINSTOR-Ökosystem — golinstor, der Treiber für das Container Storage Interface (CSI), der Piraeus-Operator und deren API-Verträge. LINSTOR selbst steht unter der GPL, womit ausgeschlossen ist, seinen Code als Grundlage für ein Apache-2.0-Projekt zu verwenden. Das war die zentrale Schwierigkeit, und genau deshalb bin ich den Clean-Room-Weg gegangen.

Meine Hauptaufgabe bestand damit darin, diese Exit Gates zu definieren. Sitzen sie richtig, muss ich nicht die gesamte entstehende Codebasis kontrollieren: Erfüllt der Code die Bedingungen, die ich mir selbst gesetzt habe, ist das der Nachweis, dass die Arbeit erledigt ist.

Die API als Vertrag

Mir gefallen die Typdefinitionen, die LINSTOR in seiner API verwendet. Hinzu kommt, dass sowohl der offizielle CSI-Treiber als auch der Piraeus-Operator mit diesen Typen arbeiten, und ich hatte keine Lust, eines von beiden neu zu schreiben.

Aus Erfahrung ist der Entwurf von APIs eine der schmerzhaftesten Aufgaben in diesem Beruf. Backend-Logik können Sie jederzeit ändern. Ein einziger Breaking Change an der API, und auf der Client-Seite fällt alles auseinander. Eine API sollte sich also selten und nur in Ausnahmefällen ändern — und das Risiko, sie gleich zu Beginn falsch zu schneiden, ist hoch. Deshalb habe ich mich entschieden, exakt die Typen des Originalprojekts zu verwenden und sie auf Kubernetes-first-Typen in Form von CustomResourceDefinitions (CRDs) abzubilden.

Beim Aufbau von Cozystack und im Vertrieb von Lösungen darauf ist uns dieselbe Frage von Interessenten schon mehrfach begegnet: Wie steht es um eure API? Was passiert, wenn wir euch produktiv einsetzen, eine Lösung darum herum bauen — und sich dann eure API ändert und wir unsere Hälfte des Projekts neu schreiben müssen?

Zur Erinnerung: Der Code von LINSTOR ist unter GPLv3 veröffentlicht, und ich hatte vor, Blockstor unter Apache 2.0 zu veröffentlichen. Den Originalcode wiederzuverwenden schied damit aus. Die erste Aufgabe war also, im Kubernetes-Werkzeugumfeld kompatible Verträge zu finden: die Bibliothek golinstor, linstor-csi und den Piraeus-Operator, allesamt unter Apache 2.0, sowie die offizielle LINSTOR-Dokumentation unter CC BY-SA.

Damit hatte ich meinen ersten Vertrag: Die API muss mit der LINSTOR-Go-Bibliothek, mit linstor-csi und mit dem Piraeus-Operator kompatibel sein.

Die Testumgebung

Das Modell brauchte einen Ort zum Arbeiten und einen Ort, um das Erzeugte zu testen. Als Testumgebung habe ich einen kräftigen Bare-Metal-Knoten gewählt, dazu eine generierte Test-Suite, die in virtuellen Maschinen (VMs) einen Kubernetes-Cluster auf Talos hochzieht und Blockstor darin ausrollt. Diese Wahl war bewusst: Blockstor braucht das DRBD-Modul, und DRBD neigt bei falscher Konfiguration dazu, sich aufzuhängen — ich brauchte also einen schnellen Weg, eine kaputte Umgebung neu aufzusetzen. Da Blockstor seine Konfiguration architekturbedingt als Kubernetes-CRDs ablegt, war mit Talos zugleich die Frage des Kubernetes-Bootstraps erledigt.

Das erste Ergebnis

Als der erste Proof of Concept (PoC) fertig war, hatte mir das Modell einen funktionierenden Prototyp gebaut — allein anhand der genannten Quellen und seines eigenen Datenbestands. Für das Interaktionsmodell hatte es allerdings genau dasselbe anfragegetriebene Modell implementiert wie das Original-LINSTOR, vermutlich aus dessen Dokumentation übernommen. Und es funktionierte bereits! Ich konnte über das offizielle CLI mit der API sprechen, wenn auch mit Hunderten von Fehlern und Lücken.

Um das zu korrigieren, habe ich das Modell gebeten, die API-Verträge als Tests einzufrieren und die Logik auf controller-runtime umzuschreiben, so wie ich es brauchte. Mit einem klaren, deterministischen Ziel begann die zurückgelieferte Architektur dem zu ähneln, was ich tatsächlich wollte: vollständig asynchron, mit dem API-Übersetzer als separatem, austauschbarem Modul.

Später habe ich das Modell eine Reihe von End-to-End-Tests (e2e) implementieren lassen, die Volumes über das offizielle CSI-Plug-in und das Framework kubernetes-csi/csi-test anfordern. Anders gesagt: Das Modell arbeitete so lange weiter, bis Blockstor Volumes und Snapshots über die üblichen Kubernetes-Abstraktionen bereitstellte. Nach einer Weile hatte ich einen funktionierenden Prototyp. Von Stabilität war das System allerdings weit entfernt, was mich vor die Frage stellte: Wie erreicht man die nötige Stabilität, wenn es zu Beginn gar keine Tests gibt?

An dieser Stelle floss mein gesamtes Material ein — meine Artikel zum Debugging von LINSTOR, meine Vorträge, meine Claude-Code-Debugging-Skills, unsere in Cozystack integrierten Plunger-Skripte und auf GitHub gemeldete Fehler. Ich habe das Modell all das studieren und daraus eine Sammlung von Punkten zusammenstellen lassen, die getestet werden mussten und die unser System erfüllen sollte. Heraus kam eine riesige Markdown-Datei. Ich habe sie durchgesehen und das Modell losgeschickt, jedes darin erfasste Problem auf dem Teststand zu prüfen und zu beheben. Es gab viele solcher Iterationen, und jede kostete gewaltig viel Zeit. Meist zog das Modell die Umgebung hoch, ließ Tests laufen, behob Fehler, setzte die Umgebung neu auf — und all das dauerte.

Irgendwann habe ich angefangen zu fragen, wie sich der Prozess beschleunigen ließe.

Die Entwicklung beschleunigen

Daraus entstand die Idee, Agenten zu parallelisieren. Manche Probleme ließen sich auf Ebene der Unit-Tests abschließen. Andere waren nur an einer echten Umgebung zu verifizieren. Nachdem ich denselben Satz Fehler immer wieder durchgespielt hatte, kam ich zu dieser Methode:

1. Ich bitte einen Agenten, die Referenzen zusammenzutragen und so etwas wie einen Plan für die Fehler aufzustellen.
2. Sobald ich das riesige Dokument habe, bitte ich das Modell, einen Schwung Agenten loszuschicken, von denen jeder an einem bestimmten Fehler arbeitet.
3. Im Code bekommt jeder Agent seine eigene isolierte Umgebung und seinen eigenen Worktree, in dem er seine Korrekturen einreicht.
4. Aufgabe jedes Agenten ist es, das Problem zu untersuchen, eine Umgebung hochzuziehen, eine Korrektur samt Tests vorzubereiten und alles an den Hauptagenten zurückzugeben.
5. Der Hauptagent zieht die Arbeit aller Agenten in den Hauptbaum — und das wiederholt sich über mehrere Iterationen.
6. Am Ende liefen bis zu 60 Agenten gleichzeitig: 30 auf Ebene der Unit-Tests, 30 auf e2e in einer konkreten Umgebung.

Nach einer Weile fing das Projekt an, nach etwas auszusehen, das man tatsächlich benutzen kann. Vieles war noch nicht stabil.

Der Marathon geht weiter

Während ich diesen ganzen Zoo betreute, habe ich parallel selbst Integrationstests gefahren und die Ergebnisse von Hand geprüft. Ich ließ mir von Claude Zugang zu einer Umgebung geben, bediente das linstor-CLI manuell und versuchte, die Fehler zu reproduzieren — von denen es noch reichlich gab.

An diesem Punkt musste ich aufhören, große Blöcke zu bauen, und stattdessen sehr viel akribischer die User Journey testen. Der Großteil der Probleme verschwand, als ich die Agenten Tests über das offizielle CLI implementieren ließ und die User Journey für den Day-2-Betrieb aus der offiziellen LINSTOR-Dokumentation vorgab. An manchen Stellen drehte sich das Modell allerdings im Kreis: Über die ganze Zeit brachte es nie alle Tests zuverlässig auf Grün, und ich musste persönlich eingreifen. Gestützt auf mein eigenes Wissen ließ ich mir jedes Problem erklären und stellte dem Modell dann eine Reihe gezielter Fragen zur Architektur.

Die Feinschliff-Phase

Viele meiner Fragen liefen auf die asynchrone Natur der Controller hinaus. DRBD ist von Haus aus heikel, was den Zeitpunkt, die Art und die Reihenfolge der Konfigurationsanwendung angeht. Entscheidend war deshalb eine stabile Zustandsmaschine — eine, die den Reconciliation-Loop erst dann zu einer bestimmten Aktion durchlässt, wenn die Bedingungen erfüllt sind.

Das größte Problem war dabei die Snapshot-Logik. Um einen Snapshot anzulegen, friert LINSTOR zunächst die I/O auf DRBD-Ebene ein und schickt den Befehl dann gleichzeitig an die mehreren Knoten, die das darunterliegende Gerät in ZFS halten. Nach erfolgreicher Operation taut LINSTOR DRBD wieder auf. Das alles muss augenblicklich geschehen, und im Fehlerfall muss der Zustand automatisch zurückgerollt werden, damit der Container oder die VM bei der Arbeit mit ihren Daten nie blockiert.

Das zweite Problem war, wie sich der initiale Sync einer neuen Replik überspringen lässt. Das beobachtbare Verhalten kannte ich aus Jahren im Betrieb von LINSTOR: Die erste Replik hält ihren aktuellen Generation Identifier fest, spätere Repliken übernehmen diesen als Startwert und synchronisieren von dort aus.

Zuerst habe ich versucht, die exakte Befehlsfolge allein aus dem beobachteten Verhalten zu rekonstruieren, indem ich Operationen gegen einen laufenden Controller ausführte und die Befehle mitschnitt. Die Mechanik ist aber nicht öffentlich dokumentiert, und Beobachtung allein ergab kein stimmiges Bild. Also bin ich auf das Clean-Room-Verfahren zurückgefallen. Ein Agent — der „schmutzige Raum“ — rekonstruierte aus den Originalquellen eine funktionale Spezifikation: welche Befehle ausgeführt werden und unter welchen Bedingungen. Er hielt ausschließlich diese funktionalen Fakten fest und übernahm weder Code noch dessen Ausdrucksform. Der zweite Agent — der „saubere Raum“ — hatte von vornherein keinen Zugriff auf fremde Quellen und implementierte den Ansatz von Grund auf, streng nach der Spezifikation.

Ein weiteres Problem war die konsistente Vergabe von Node-IDs — jede DRBD-Replik braucht im Cluster eine eindeutige Nummer von 1 bis 8 — sowie die Vergabe der TCP-Ports für die Replikation, die in der aktuellen Implementierung nicht mehr an DRBD gebunden ist, sondern aus einem Pool je Knoten erfolgt. Genau hier hat sich die oben beschriebene Zustandsmaschine ausgezahlt.

Der Aufbau des CI-Systems

Inzwischen war klar, dass das Experiment in seine Endphase ging, und ich begann, über die Zukunft des Projekts nachzudenken. Um es fertigzustellen und produktionsreif zu machen, brauchten wir ein ernsthaftes System für Continuous Integration (CI), das garantiert, dass kein ungetesteter Code in der Codebasis landet. Angesichts der Testmenge durfte ein Lauf nicht über mehrere Stunden gehen, die Tests mussten also ebenso parallelisiert werden.

Und wir haben eines gebaut: Für jeden Pull Request lief ein großer Stapel Tests parallel über sechs bis sieben Runner und lieferte am Ende „ok“ oder „nicht ok“.

In diesem Modus habe ich noch etliche Runden gearbeitet, bis die CI wirklich grün und stabil war. Danach sind wir von lokalen Worktrees auf Pull Requests bei GitHub umgestiegen.

Die Endphase

Datenverlust ist nicht akzeptabel. Bevor ich das Projekt für fertig erklären konnte, musste ich also gründlich prüfen, ob Blockstor sich in dieser Hinsicht korrekt und verlässlich verhält. Den gesamten generierten Code zu lesen und zu prüfen, überstieg sowohl meine Energie als auch meine Kapazität. Andererseits ist Blockstor — wie LINSTOR — im Kern ein Orchestrator. Die Daten selbst liegen in ZFS und DRBD, und an deren Zuverlässigkeit hatte ich keine Zweifel. Wichtig war der Nachweis, dass der Controller die Ressourcen tatsächlich korrekt konfiguriert und Ausfälle übersteht.

Aber wie stellt man fest, ob man dem aktuellen Code den Produktivbetrieb anvertrauen kann? Das ist eine unscharfe und schwierige Frage. Und wie kommt man zu einer deterministischen Antwort darauf? Hier habe ich ein weiteres Muster genutzt, das ich mir im Lauf des Projekts erarbeitet habe.

Mein Kollege @lexfrei hatte früher einmal erwähnt, dass Modelle es fürchten, wenn man ihnen sagt, ihr Handeln könne zu schweren finanziellen Verlusten führen. Ich habe beschlossen, genau das als Exit Gate zu nutzen. Ich habe einen Agenten gestartet, der für die Freigabe des Codes in die Produktion zuständig war, und ihn unter Bedingungen arbeiten lassen, in denen sein Leben und sein finanzielles Wohlergehen vom Endergebnis „abhingen“. Er stellte einen Abnahmeplan mit einer langen Liste von Punkten auf, darunter ein 24-stündiger Dauerlauf auf echter Infrastruktur. Ein zweiter Agent versuchte, diese Anforderungen zu erfüllen. Das ging noch mehrere Tage und mehrere Releases so weiter, bis der für die Auslieferung zuständige Agent schließlich seinen Segen gab.

Ein System, das niemand nutzt, kann man allerdings nicht stabil nennen. Der nächste Schritt war deshalb die Integration von Blockstor mit Cozystack. Unsere Test-Suite deckt viele Funktionen gleichzeitig ab: das Anfordern von Volumes mit und ohne DRBD, RWX, Snapshots und weitere Details. Aufgabe des neuen Agenten war es, einen Draft-Pull-Request vorzubereiten, die Tests auf Grün zu bringen und die Endphase abzuschließen.

Stand 15. Juli 2026 ist dieser Pull Request noch nicht gemergt — aber die Chancen stehen gut, dass Sie bald ein neues, Kubernetes-natives Storage-Backend in Cozystack haben. Bleiben Sie dran.

Anmerkung der Redaktion (September 2026): Blockstor ist weiterhin ein eigenständiges, experimentelles Projekt — github.com/cozystack/blockstor, Apache 2.0 — und nicht Bestandteil von Cozystack. LINSTOR/DRBD über Piraeus bleibt der Speicher, den Cozystack ausliefert, und ist dort das Standard-Backend. Blockstor steht auf der Roadmap als optional zuschaltbares Backend für 2027.

Die wichtigste Erkenntnis

Blockstor hat nach wie vor experimentellen Status. Die Erfahrung hat mir aber erlaubt, die Arbeit an anderen Projekten erheblich zu beschleunigen und zu automatisieren, und ich wende sie inzwischen täglich an.

Viele halten KI immer noch für ein Autovervollständigungswerkzeug. Für mich hat das schon lange aufgehört zu stimmen. AI-first-Entwicklung heißt nicht, ein Modell gelegentlich eine Funktion schreiben zu lassen. Sie heißt, den gesamten Engineering-Prozess um Agenten, Kontext, Tests, Skills, Pläne, Review und Automatisierung herum neu zu bauen.

Auf diese Weise kann man Aufgaben angehen, die für ein kleines Team früher zu groß aussahen — zum Beispiel mit einer Kubernetes-nativen Implementierung eines Speichersystems der LINSTOR-Klasse zu experimentieren. Das funktioniert allerdings nur unter einer Bedingung: Man braucht Disziplin. Ohne Plan erzeugt KI Chaos sehr viel schneller, als ein Mensch es könnte. Mit Plan, Tests, Agenten und ordentlichem Review wird KI zum Kraftverstärker für das Engineering.

Und so, glaube ich, sieht der Bau komplexer Infrastruktur von hier an aus: nicht ein Ingenieur gegen eine gewaltige Codebasis, sondern ein Ingenieur als Architekt eines Prozesses, um den herum ein Schwarm spezialisierter Agenten arbeitet. Die Aufgabe des Ingenieurs ist es nicht, jeden Agenten zu beaufsichtigen. Sie ist es, ein System zu bauen, in dem die Agenten sich selbst beaufsichtigen und nur mit dem zum Menschen kommen, was wirklich einen Menschen braucht.

Community

• Blockstor auf GitHub
• Cozystack auf GitHub
• Telegram-Gruppe
• Slack-Gruppe (Einladung unter https://slack.kubernetes.io)
• Kalender der Community-Meetings

Dieser Beitrag ist eine deutsche Fassung des Artikels What dozens of AI agents taught me: how I wrote the Blockstor storage system as an experiment, zuerst erschienen bei Ænix auf Medium.

Dieser Artikel erzählt, wie wir das mit aeman gelöst haben — einem Werkzeug, das wir selbst gebaut und kürzlich als Open Source veröffentlicht haben. Ich muss aber weiter vorne anfangen.

Woher die Idee kommt

Vor Jahren habe ich in einem anderen Unternehmen gearbeitet, und dort gab es zwei interne Systeme mit den schönen Namen Ford und Nixon. Kollegen haben ausführlich darüber geschrieben, deshalb hier die Kurzfassung. Es sind Boards für die Verfolgung von Tagesaufgaben, auf denen ein Entwickler genau sieht, woran er heute arbeitet. Kein Backlog über drei Monate, keine hundert Kanban-Spalten — Ihr Tag, und sonst nichts. Über Jahre hat dieses System viele Remote-Teams effektiv arbeiten lassen und die Infrastruktur vieler Kunden am Laufen gehalten.

Ich will ehrlich sein: Der Prozess hinter aeman ist nicht vollständig meine Idee. Ich habe ein funktionierendes System zur Prozesssteuerung übernommen, das ich bei meinem früheren Arbeitgeber gesehen hatte, und es auf unsere eigenen Prozesse und Aufgaben übertragen. Unser Board zwingt uns heute dazu, uns auf das Wichtigste zu konzentrieren — auf die geschäftlichen Aufgaben.

Anders als Trello geht dieses Modell davon aus, dass eine Person an einem einzigen Tag an Aufgaben in mehreren Teams arbeiten kann. Und der Tagesplan darf nicht zur Aufgabenwand werden. Wenn ein Entwickler 6 bis 10 Aufgaben eingeplant hat, realistisch aber nur 3 oder 4 abschließen kann, bleibt bei ihm ein dauerhaftes Gefühl von Schuld zurück, während das Management ein falsches Bild von hoher Auslastung bekommt. Außerdem fangen Menschen an, ständig zwischen Aufgaben zu wechseln, und das Gehirn greift naturgemäß nach denen, die sich leichter abschließen lassen. Schwere Aufgaben bleiben dann lange unangetastet liegen. Der Tagesplan muss also kurz und ehrlich sein.

Warum kein fertiges Werkzeug?

Ich habe versucht, einen solchen Prozess auf vorhandenen Werkzeugen aufzubauen: Trello, Asana, Notion, GitHub Projects — mit unterschiedlichem Erfolg. Notion kam dem am nächsten, aber ich war nicht bereit, das ganze Team allein wegen der Boards in noch ein weiteres System zu ziehen und dafür zu bezahlen. Und mit der Zeit wuchs das Board unweigerlich, bis es nicht mehr auf einen Bildschirm passte.

GitHub Projects erwies sich als die tragfähigste Option. Es ist kostenlos, bietet eine bequeme API und bringt bereits alles mit, was man braucht: Sprints, Prioritäten, Status und weitere Entitäten. Es lässt sich außerdem gut erweitern. Deshalb haben wir lange damit gearbeitet.

Ziemlich schnell wurde aber klar, dass das Problem nicht in den Fähigkeiten des Werkzeugs lag, sondern in der UX. Es kostet viel zu viele zusätzliche Schritte, eine Aufgabe anzulegen, sie jemandem zuzuweisen und die nötigen Felder auszufüllen. Und einen angenehmen Tagesprozess haben wir um GitHub Projects herum nie hinbekommen. Sprints gibt es zwar, aber sie erwiesen sich als zu umständlich: Man kann den laufenden Sprint nicht in einem Schritt schließen und den nächsten mit den übernommenen offenen Aufgaben starten, und man kann eine Aufgabe nicht schnell auf „später“ schieben, damit sie aus dem Blick verschwindet und nicht länger um die Aufmerksamkeit des Entwicklers konkurriert.

Mit der Zeit zeigte sich ein weiteres Problem. Bei jedem Sync schauten wir faktisch auf eine einzige Spalte — In Progress. Dort passierte die ganze Arbeit, während die Karten in den anderen Spalten langsam zu einem Aufgabenfriedhof wurden: noch auf dem Board, aber nicht mehr Teil des Tagesprozesses und ohne Bewegung. GitHub Projects erwies sich als ausgezeichneter Ort, um Aufgaben abzulegen, und als schwacher, um den Tagesfokus eines Teams zu steuern.

Genau deshalb habe ich, als ich mit dem Bau von aeman anfing, GitHub Projects als Backend des neuen Systems gewählt und die Oberfläche und den Workflow darauf aufgesetzt.

Die Grundidee: genau die Karten, die Sie heute brauchen

Das Ziel von aeman ist, die heute relevanten Aufgaben sichtbar zu machen und den Entwickler darauf zu fokussieren. Idealerweise verlässt ein Entwickler das Morgen-Sync mit einer Liste von Aufgaben, an denen er an diesem Tag definitiv arbeiten wird. Alles andere wandert auf morgen oder auf nächste Woche — und verschwindet physisch vom Board, damit es nicht länger ins Auge fällt.

Die zweite Idee: Ungeplante Arbeit muss sichtbar sein. Jeder kennt Tage, die von einem plötzlichen Incident oder einer dringenden Anfrage aus einem Nachbarteam aufgefressen werden. Üblicherweise wird diese Arbeit nirgends festgehalten, und am Ende des Sprints kann niemand erklären, wo die Zeit geblieben ist. In aeman hat sie eine eigene Zone: Sie tragen sie im Nachhinein als eine Karte ein, und der Tag verschwindet nicht mehr spurlos (Screenshots weiter unten). Beim täglichen Sync lässt sie sich dann besprechen und in den geplanten Block verschieben.

Die dritte Idee: Arbeit in mehreren Teams ist eine Eigenschaft des Modells, kein Filter. In einem kleinen Unternehmen kann ein Entwickler an Aufgaben in mehreren Teams arbeiten — das gilt besonders für Gründer, die ohnehin alles gleichzeitig jonglieren. In aeman sind Teams eine Dimension des Boards: Ein Sprint wird je Team geführt, jedes Team hat seinen eigenen Wochenplan, und das Me-Board sammelt die Karten eines Tages aus allen Teams des Entwicklers auf einmal. Sie müssen nicht zwischen Boards springen, um Ihren Tag zu sehen. Eine Aufgabe wandert außerdem frei zwischen Personen und Teams — sie kann von einem Tag auf den anderen die Zuständigkeit wechseln, und das ist ein normaler Arbeitsmodus, dem das Werkzeug nicht im Weg stehen sollte.

Und die vierte Idee: Ein Team-Lead braucht ein Werkzeug, das den Status jeder Aufgabe innerhalb einer Minute zeigt, ohne Leute mit Rückfragen aus der Arbeit zu reißen.

Philosophisch steht aeman Todoist näher als einem klassischen Kanban-Board. Karten sind bewusst kurz: Im Normalmodus sehen Sie nur den Titel, die Beschreibung öffnet sich per Doppelklick. Die Beschreibung nimmt Links in freier Form auf — Pull Requests, GitHub-Issues, Telegram-Chats, was auch immer — und aeman erkennt sie automatisch und zeigt eine Schaltfläche, um direkt dorthin zu springen. Das hält den Hauptbildschirm sauber, und eine weitere abgeschlossene Aufgabe erzeugt jenes befriedigende Gefühl, das jeder kennt, der einen guten Task-Manager benutzt.

Wie es aussieht

Das Me-Board: Ihr Tag

Ein Entwickler öffnet aeman morgens und sieht seinen Tag: Karten, gruppiert in vier farbige Zonen. Das ist nicht die Eisenhower-Matrix, die Aufteilung ist eine andere:

• Rot — urgent, muss heute erledigt werden
• Grau — planned, gewöhnliche geplante Arbeit, die auch länger als einen Tag dauern kann
• Gelb — unplanned, was im Lauf des Tages hereinkam
• Grün — nice to have, erst dann, wenn alles andere fertig ist

Das Board zieht Karten aus allen Teams des Entwicklers, also aus dem jeweils aktuellen Sprint jedes Teams. Die Teamauswahl am oberen Rand engt die Liste auf ein einzelnes Team ein oder blendet alle Karten aus, die erledigt, blockiert oder im Review sind — es bleibt nur, woran Sie hier und jetzt arbeiten können, wenn Deep Work ansteht. Jede Karte hat einen Fortschrittsregler von 0 bis 100 % in Schritten von 10 % (den Fortschrittsbalken auf „fertig“ zu ziehen, macht erstaunlich viel Freude), eine Stufe (Review / Locked / Recurrent / Done), die den Balken umfärbt, einen Zähler für die Tage in Bearbeitung sowie Links zu einem Issue oder einem PR. Rechts liegt ein Notizbereich: ein persönliches Tagesprotokoll, in dem Sie während der Arbeit festhalten können, was anfällt. So müssen Sie beim nächsten Standup nicht im Gedächtnis kramen — Sie überfliegen die Notizen und berichten, was Sie getan haben. Notizen leben im Kontext des Tages; morgen ist das Board leer, aber Sie können jederzeit einen Tag zurückgehen und sie noch einmal lesen.

Das Team-Board: das ganze Team auf einen Blick

Die Sicht des Team-Leads: ein Raster aus Personen und Zonen für einen ausgewählten Tag. Spalten sind die Entwickler mit ihren Avataren, Zeilen dieselben farbigen Zonen. Sie sehen sofort, wer woran arbeitet, wo es brennt und wer überlastet ist. Der Team-Lead legt Karten auch von hier aus an: ein paar Klicks, und eine Aufgabe ist erstellt, zugewiesen und priorisiert.

Im Me-Modus kann der Team-Lead außerdem in die Rolle eines Entwicklers schlüpfen (Schaltfläche View as) — das Board mit dessen Augen ansehen und bei Bedarf aufräumen.

Tagessprints und Carry-over

Unsere Sprints sind kurz — ein Tag — und sie zählen vorwärts, nicht rückwärts. Im Morgen-Sync bespricht das Team zuerst, was gestern fertig geworden ist, und dann drückt der Team-Lead auf Carry over: Jede unerledigte Karte wandert in den neuen Sprint (heute), erledigte bleiben in der Historie von gestern. Wiederkehrende Aufgaben werden automatisch neu angelegt. Das ist hier die Tagesplanung, und sie dauert Minuten.

Ergibt die Planung, dass eine Aufgabe heute definitiv nicht stattfindet, gibt es die Schaltflächen +1 day und +1 week: Die Karte verschwindet bis zu ihrem Tag vom Board, und es geht nichts an Historie verloren. Ist der Tag gekommen, taucht sie wieder auf.

Der Wochenplan

Hier sind wir von der ursprünglichen Idee abgewichen und haben angefangen, unseren eigenen Workflow auf das entstandene Werkzeug zu übertragen.

Die Gründer und ich haben die Woche des Teams früher geplant, indem wir eine neue Liste von Wochenaufgaben in Google Sheets geschrieben und jedem Team eine Nachricht mit dem „Fokus der Woche“ über Slack geschickt haben. Auch dieser Prozess ist inzwischen in aeman umgezogen.

Unter dem Team-Raster liegt der Wochenplan: die geschäftlichen Aufgaben des Teams für die Woche, aufgeteilt in zwei Bahnen, „bis Mittwoch“ und „bis Freitag“. Einmal pro Woche legen die Gründer dort Aufgaben ab, und die Aufgaben warten auf ihren Einsatz. Der Team-Lead zieht eine Plankarte auf einen Entwickler; sie erscheint auf dessen Tagesboard und bleibt zugleich mit einer farbigen Markierung im Plan. Ein gemeinsamer Fortschrittsbalken zeigt, wie das Team in der Woche steht, und das wöchentliche Carry over verschiebt alles noch Offene in die nächste Woche.

Reviews, Teilaufgaben und das Aktivitätsprotokoll

Eine Aufgabe ins Review zu schicken erzeugt eine verknüpfte Karte für den Reviewer, mit einer Rückkopplung: Solange das Review offen ist, steht das Original auf der Stufe Review, und sobald der Reviewer seine eigene Karte auf 100 % bringt, wird das Original automatisch freigegeben. Große Aufgaben zerfallen in Teilaufgaben, deren Fortschritt in die übergeordnete Karte einfließt. Jede Aktion auf dem Board wird in das Aktivitätsprotokoll der Karte geschrieben, sodass sich ihre gesamte Historie im Nachhinein rekonstruieren lässt: wer sie verschoben hat, wann sich der Fortschritt geändert hat und warum sie in einem anderen Sprint gelandet ist.

Ein Tag mit aeman

So sieht der ganze Ablauf aus:

1. Morgen-Sync. Wir öffnen das Team-Board von gestern, der Team-Lead teilt seinen Bildschirm, und wir gehen die Karten durch: was fertig ist, was hängt, Person für Person, wobei der Lead die Status unterwegs korrigiert. Dann drückt er Carry over, und alles Unerledigte wandert in den heutigen Tag. Anschließend besprechen wir das Neue: Der Lead legt Karten im Gespräch an und verteilt sie auf Personen und Zonen.
2. Der Tag. Alle arbeiten von ihrem eigenen Me-Board aus. Kommt etwas Dringendes herein — eine Karte in die gelbe Zone. Ist etwas blockiert — Stufe Locked, und der Lead sieht es. Der Fortschritt wandert nebenher mit; Gedanken und Erkenntnisse landen in den Notizen des Tages.
3. Fertig — die Karte steht auf 100 %, Stufe Done. Braucht sie ein Review, dann Send to review, und sie erscheint beim Reviewer.
4. Morgen wiederholt sich das Ganze.

Jedes Board ist live: Änderungen von Kolleginnen, Kollegen und KI-Agenten erscheinen auf allen Bildschirmen in etwa einer Sekunde, ganz ohne Neuladen. Wie das funktioniert, steht weiter unten.

Unter der Haube

Jetzt der Teil, für den das Engineering-Publikum gekommen ist.

GitHub Projects v2 als einziger Speicher

aeman hat überhaupt keine eigene Datenbank. Jede Karte ist ein Item auf einem GitHub-Projects-Board, und jedes Feld — Zone, Fortschritt, Sprint, Wochenplan — ist ein gewöhnliches Projektfeld. aeman legt die benötigten Felder sogar bedarfsgesteuert an: Richten Sie es auf ein beliebiges leeres Projekt, und die erste Änderung erzeugt, was fehlt. Man könnte sagen, aeman ist eine spezialisierte Sicht auf ein GitHub-Board: Dasselbe Board öffnet sich in der nativen Oberfläche von GitHub, die Daten gehören immer Ihnen, und Sie können sich jederzeit von aeman verabschieden, ohne irgendetwas migrieren zu müssen.

Eine API im Kubernetes-Stil

Die API von aeman ist bewusst nach denselben Prinzipien gebaut wie die Kubernetes-API — einem Muster, das sich für die Synchronisation verteilten Zustands bewährt hat. Jede Entität — Card, Sprint, Ordering, Presence — ist eine eigene Ressource mit den vertrauten Feldern kind, metadata und spec.

Der Client folgt dem bekannten Schema list + watch. Er holt zunächst einen vollständigen Snapshot des Boards, öffnet dann einen WebSocket und empfängt einen Strom von ADDED-, MODIFIED- und DELETED-Ereignissen. Nach einer vollständigen Resynchronisation sendet der Server einen speziellen Sync-Frame, der signalisiert, dass der lokale Zustand vollständig aktuell ist.

Im Ergebnis arbeitet jeder geöffnete Browser-Tab wie ein Kubernetes-Informer mit eigenem lokalem Cache. Jede Änderung durch andere Nutzer oder durch einen KI-Agenten erscheint auf allen offenen Bildschirmen in etwa einer Sekunde, und die eigenen Änderungen werden Ihnen nicht zurückgespiegelt. GET /api/v1 liefert einen maschinenlesbaren Katalog aller verfügbaren Ressourcen und Endpunkte, sodass Clients und KI-Agenten die Form der API nicht vorab kennen müssen.

Die GitHub-API ist langsam. Was tun?

Das wichtigste technische Problem des Projekts: GraphQL-Mutationen bei GitHub brauchen Hunderte von Millisekunden, mitunter ganze Sekunden; Lastspitzen laufen in sekundäre Rate Limits; und — Überraschung — die Read-Replicas von GitHub hinken den Schreibvorgängen um mehrere Sekunden hinterher. Schreibt man direkt durch, wird die Oberfläche zur Diaschau: Regler bewegen, warten; Karte ziehen, warten.

Schreibvorgänge in aeman folgen deshalb einem Write-behind-Schema, und der Nutzer wartet nie auf GitHub. Jede Änderung wird sofort auf den Server-Cache angewendet, ist auf allen offenen Boards unmittelbar sichtbar und geht erst danach asynchron zu GitHub. Schreibvorgänge laufen über eine Hintergrundwarteschlange mit Rate Limiting und automatischen Wiederholungen bei transienten Fehlern, um den Rate Limits der GitHub-API aus dem Weg zu gehen.

Die Warteschlange kann aufeinanderfolgende Änderungen zusammenfassen, ganz ähnlich wie die DeltaFIFO in Kubernetes. Ändert ein Nutzer dasselbe Kartenfeld mehrfach hintereinander, geht nur der letzte Wert an GitHub. Für Karteninhalte gilt eine andere Regel: Text geht niemals verloren. Bearbeitet ein Nutzer eine Beschreibung oder ergänzt Notizen in schneller Folge, führt die Warteschlange sie zu einer finalen Fassung zusammen und schickt sie in einer einzigen Anfrage. Bis der Schreibvorgang bestätigt ist, existieren neue Notizen unter temporären Bezeichnern, die anschließend automatisch gegen die echten getauscht werden.

Scheitert ein Schreibvorgang auch nach allen Wiederholungen, benachrichtigt der Server alle verbundenen Clients und liest den Board-Zustand erneut aus GitHub. GitHub bleibt die einzige Quelle der Wahrheit. Beim Herunterfahren wartet aeman zunächst, bis die Warteschlange leergelaufen ist, damit bereits gegenüber dem Nutzer bestätigte Änderungen nicht verloren gehen.

GitHub garantiert nicht, dass eine Änderung in dem Moment lesbar ist, in dem sie geschrieben wurde. Manchmal liefert die API unmittelbar nach einem erfolgreichen Schreibvorgang noch eine Weile den alten Zustand zurück. Dadurch könnte ein Nutzer sehen, wie eine gerade verschobene Karte zurückspringt, eine gelöschte Karte wieder auftaucht oder eine neue an der falschen Stelle landet. Um das zu vermeiden, behandelt aeman die eigenen jüngsten Schreibvorgänge für ein kurzes Zeitfenster als vertrauenswürdiger als frische Daten von GitHub. Sobald GitHub den aktuellen Zustand zurückliefert, schaltet das System automatisch wieder darauf um. Im Ergebnis sieht der Nutzer nie, wie die Oberfläche zurückspringt.

Kommentare und Aktivitätsprotokoll

Auch Notizen und Änderungshistorie liegen in GitHub, ohne separate Datenbank. Bei Entwurfskarten steht das Protokoll direkt im Body des Issues, hinter einer speziellen Markierung <!-- aeman:log -->. Ist eine Karte mit einem bestehenden Issue oder Pull Request verknüpft, werden Notizen zu gewöhnlichen GitHub-Kommentaren und sind für alle in der Diskussion sichtbar.

Jede Aktion auf dem Board — eine Karte anlegen, den Fortschritt ändern, zwischen Sprints verschieben, ins Review schicken und so weiter — hält der Server als maschinenlesbare Ereigniszeile fest. Damit Abonnenten nicht unter Dutzenden Benachrichtigungen begraben werden, sammeln sich all diese Ereignisse in einem einzigen Protokollkommentar, der nach und nach ergänzt wird. Das Protokoll ist auf die letzten 200 Ereignisse begrenzt, Notizen von Nutzern werden nie gelöscht.

Das Ergebnis ist eine vollständige Änderungshistorie für jede Karte: wer sie wann verschoben hat, wie sich der Fortschritt entwickelt hat und warum sie in dem einen oder anderen Sprint gelandet ist. Dieses Protokoll ist nicht nur für die Nachvollziehbarkeit nützlich, sondern auch als Datenquelle für Statistiken und Kennzahlen.

Ein austauschbares Backend

aeman war von Anfang an für ein austauschbares Backend ausgelegt. Heute liegen die Karten in GitHub Projects, das System selbst ist aber nicht an GitHub gebunden. Die gesamte Interaktion mit dem Speicher liegt hinter einem Backend-Interface, sodass die Unterstützung eines neuen Backends darauf hinausläuft, genau dieses eine Interface zu implementieren.

In künftigen Iterationen möchte ich ein Git-Backend ergänzen, das Karten als einfache Dateien im Repository ablegt. Weder die Oberfläche noch die Geschäftslogik der Anwendung müssen sich dafür ändern.

Die Pakete unter pkg/ lassen sich außerdem als gewöhnliche Go-Bibliothek verwenden, womit Sie die Board-Engine in Ihr eigenes Werkzeug einbetten können. Mehr dazu steht in docs/embedding.md.

MCP für KI-Agenten

Dieselbe Binärdatei kann auch als MCP-Server laufen. Damit werden Claude und andere KI-Agenten zu vollwertigen Teilnehmern des Prozesses: Sie legen Karten an und verschieben sie, hinterlassen Notizen, führen den Carry-over zwischen Sprints aus und erledigen weitere Operationen.

Es gibt keine separate API für KI und keine Sonderrechte. Jede Aktion läuft durch dieselbe Domänenschicht wie eine menschliche Aktion, mit demselben Vertrag und denselben Prüfungen, und die Änderungen sind für alle sofort sichtbar.

Neben dem lokalen Modus bietet aeman einen öffentlich erreichbaren MCP-Server. Entwickler können KI-Clients anbinden, ohne lokal etwas zu installieren, und direkt aus Claude Code und anderen KI-Agenten heraus mit ihren Aufgaben arbeiten.

So probieren Sie es aus

Am einfachsten probieren Sie aeman lokal mit Ihrem eigenen GitHub-Token aus.

gh auth login # die Scopes project und repo werden benötigt
git clone https://github.com/aenix-io/aeman
cd aeman
make build
./aeman serve

Der Browser öffnet sich automatisch unter http://127.0.0.1:8765. Als Board können Sie jedes beliebige GitHub-Projekt verwenden — am besten ein neues, leeres. aeman legt bei der ersten Änderung alle benötigten Felder selbst an.

Für die Teamarbeit gibt es einen Mehrbenutzermodus. Das Repository bringt eine fertige docker-compose.yml mit, die Anmeldung über eine GitHub-OAuth-App wird unterstützt, und jeder Nutzer arbeitet mit seinem eigenen GitHub-Token. Eine ausführliche Anleitung steht in docs/deploy.md.

Wo wir gelandet sind

Das gesamte Unternehmen lebt inzwischen seit einigen Wochen auf aeman. Produktmanager und Team-Leads haben den neuen Planungsansatz schnell angenommen, wobei es — wie bei jedem neuen Werkzeug — auch Skepsis gab. Der wichtigste Effekt war aber ein anderer: Morgens weiß jeder Entwickler, woran er heute arbeiten wird, ungeplante Arbeit ist nicht länger unsichtbar, und die täglichen Syncs sind sehr viel konstruktiver und fokussierter geworden.

Das Projekt ist Open Source unter der Apache-2.0-Lizenz und auf GitHub verfügbar: github.com/aenix-io/aeman.

Wenn Sie aeman ausprobieren, freue ich mich über jede Rückmeldung, über Berichte zu Problemen, auf die Sie stoßen, und über Ihre Geschichten dazu, wie Planung bei Ihnen funktioniert.

Dieser Beitrag ist eine deutsche Fassung des Artikels Focus on today: how we built aeman, a daily planning board for engineers on top of GitHub Projects, zuerst erschienen bei Ænix auf Medium.

Cozystack v1.6.0 ist am 22. Juli 2026 erschienen. Das Release ersetzt den Ubuntu-und-kubeadm-Bootstrap der Tenant-Kubernetes-Worker durch Talos Linux über Cluster API, schließt die Migration auf etcd-operator v1alpha2 mit In-place-Adoption laufender Cluster ab, bringt OIDC-Single-Sign-on für Tenant-kube-apiserver und einzelne Grafana-Instanzen, führt die tenantseitige Firewall-API SecurityGroup ein und macht Ressourcenquotas hierarchisch. Alle Fixes aus v1.5.1 und v1.5.2 sind enthalten.

Es bringt außerdem die größte Upgrade-Oberfläche seit v1.0 mit. Die Migrations-targetVersion springt von 45 auf 54, es laufen also die Migrationen 45 bis 53 als Pre-Upgrade-Hooks — und drei davon können das Upgrade blockieren oder den Cluster festfahren, wenn ihre Voraussetzungen nicht erfüllt sind. Planen Sie ein Wartungsfenster und arbeiten Sie die Prüfungen unten ab.

Vor dem Upgrade lesen

Steigen Sie auf v1.6.4 (oder das neueste 1.6.x) um, nicht auf v1.6.0. Drei der Fixes nach v1.6.0 gehören zur Sorte, die still versagt:

• v1.6.0 lieferte eine fail-open-Fassung von hack/seaweedfs-naming-audit.sh aus — ausgerechnet des Skripts, dessen Ausgabe einen Runbook-Schritt freigibt, der PVCs löscht. Jeder kubectl-Aufruf darin war mit 2>/dev/null stummgeschaltet, ein Timeout oder eine RBAC-Ablehnung erzeugte also eine leere „alles sauber“-Tabelle, die byte-identisch zu der einer tatsächlich sauberen Flotte war. Behoben in v1.6.1. Führen Sie das Audit aus einem Checkout ab v1.6.1 aus und lesen Sie den Exit-Code, nicht die Tabelle. Ein sauberes Ergebnis aus der v1.6.0-Fassung beweist nichts.
• v1.6.2 behebt, dass Velero-CRDs auf der zuerst installierten Version einfrieren, weil Helm das Verzeichnis crds/ eines Charts beim Upgrade nie anfasst. Sobald das Velero-Image auf eine Version mit neuen Backup-Phasen wechselte, wies der Apiserver die Phasenübergänge gegen die veralteten CRDs ab — die Backups liefen nicht mehr, während die HelmRelease grün blieb.
• Ebenfalls in v1.6.2: Die Standard-Strategy-CRs und die Velero-BackupStorageLocation hingen an einem Helm-lookup, der ausgeführt wurde, während das referenzierte Objekt noch entstand. Lieferte der Lookup nichts, wurden die Objekte dauerhaft übersprungen — der helm-controller rendert eine Release mit unveränderten Charts und Values nicht erneut.

Wer von der 1.5-Linie kommt, geht zuerst über v1.5.4. v1.5.4 ist das erste 1.5.x-Release mit targetVersion: 46, und dessen Slot 45 setzt helm.sh/resource-policy: keep auf die CAPI-Objekte KubeadmConfigTemplate. 1.6 entfernt KubeadmConfigTemplate vollständig aus dem Tenant-Chart kubernetes — die Worker wechseln auf TalosConfigTemplate —, sodass Helm das Template ohne diesen Pin löscht, während das kubeadm-basierte MachineSet noch mitten im Rollover ist und seine bootstrap.configRef darauf zeigt. Vorher prüfen:

kubectl get kubeadmconfigtemplates.bootstrap.cluster.x-k8s.io -A \
  -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,KEEP:.metadata.annotations.helm\.sh/resource-policy'

Eine Zeile mit <none> bedeutet, dass der Pin nicht gesetzt wurde. Das gehört vor dem 1.6-Upgrade korrigiert.

Prüfungen vor dem Upgrade

Diese Kommandos gegen den Management-Cluster ausführen, bevor das v1.6-Plattformpaket angewendet wird.

1. Die etcd-Adoption braucht ein erreichbares Backup-Ziel. Migration 50 adoptiert jeden Legacy-Cluster etcd.aenix.io/v1alpha1 auf den neuen Operator und legt vorher zwingend einen Snapshot an. Lässt sich das Snapshot-Ziel nicht auflösen, beendet sich die Migration mit Exit 1 und stoppt das Upgrade.

kubectl get etcdclusters.etcd.aenix.io -A
kubectl get etcds.strategy.backups.cozystack.io cozy-default-etcd
kubectl get secret cozy-backups-creds -n cozy-velero
kubectl get buckets.apps.cozystack.io cozy-backups -n tenant-root

Gibt das erste Kommando nichts aus, ist Migration 50 wirkungslos.

2. SeaweedFS-Namens-Audit. v1.6.0 pinnt fullnameOverride: seaweedfs und adoptiert den laufenden Workload-Satz in place. Zwei Zustände lassen sich nicht automatisch adoptieren, und das Chart bricht das Rendering ab, statt zu raten: Klasse S (frisch auf 1.5.x installiert, Daten auf PVCs data1-seaweedfs-system-volume-*) und Klasse MIXED (beide Namensgenerationen vorhanden). Beide müssen vor dem Upgrade nach dem Runbook seaweedfs-431-rename-recovery bereinigt werden. Klasse L erfordert nichts. Ein Cluster, der von 1.4.x direkt auf 1.6 geht, hat nie umbenannt und ist nicht betroffen.

3. Tenant-Cluster noch auf Kubernetes v1.30. v1.30 fällt aus der Talos-zu-Kubernetes-Supportmatrix, und das Chart verweigert das Rendering. Migration 46 patcht lebende CRs auf v1.31, aber eine über GitOps verwaltete CR wird beim nächsten Source-Reconcile wieder überschrieben — spec.version also in Git anheben.

kubectl get kuberneteses.apps.cozystack.io -A \
  -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,VERSION:.spec.version'

4. Handgebaute StorageClasses im Tenant, die kollidieren. Remote zugreifbare LINSTOR-StorageClasses werden jetzt unter demselben Namen innerhalb jedes Tenant-Clusters angelegt. Eine manuell erstellte Tenant-StorageClass mit kollidierendem Namen — typischerweise replicated — blockiert die propagierte Klasse und legt die Tenant-CSI-Release lahm. Jede solche, nicht von Helm verwaltete Klasse vorher löschen. Infrastrukturklassen, die node-lokal bleiben müssen, brauchen explizit linstor.csi.linbit.com/allowRemoteVolumeAccess: "false"; eine fehlende Annotation gilt als remote zugreifbar.

5. Veraltete Backup-Values im etcd-Modul. Der Block backup.* am Tenant-Modul etcd entfällt in diesem Release. Vorher auf eine BackupClass mit der Etcd-Strategie umstellen.

6. Aufstieg von v1.4.x? Die Anforderung aus v1.5.0 gilt weiterhin: Kubernetes 1.33 oder neuer auf dem Management-Cluster und auf jedem Tenant-Cluster mit Flux-Addon.

Talos Linux für Tenant-Kubernetes-Worker

Tenant-Worker booten nicht länger Ubuntu und bootstrappen nicht mehr über kubeadm. Phase 1 des Kubernetes-App-Splits ersetzt diesen Pfad durch Talos Linux, gesteuert vom cluster-api-bootstrap-provider-talos (CABPT v0.6.12), der als zweiter Bootstrap-Provider neben kubeadm registriert ist, plus einem Sidecar clastix/talos-csr-signer im Kamaji-Control-Plane-Pod.

Die Talos-PKI — eine Ed25519-CA plus trustd-TLS — wird über cert-manager mit stabilen, wiederverwendeten Talos-Secrets erzeugt. Der Kamaji-Control-Plane-Provider trägt einen Upstream-gebundenen Patch, der KamajiControlPlane.spec.network.additionalServicePorts freilegt, damit trustd (50001/TCP) am Apiserver-Service veröffentlicht werden kann. Die Worker booten das Talos-OpenStack-Raw-Image über ein CDI-DataVolume aus der Image Factory, wobei die Systemplatte als virtio-blk mit blockSize.custom: logical=512, physical=4096 bereitgestellt wird — damit 4Ki-native Backends wie LINSTOR/DRBD unter den O_DIRECT-Schreibvorgängen von QEMU korrekt arbeiten und SeaBIOS trotzdem bootet.

Das separate PVC disk-kubelet entfällt. Talos legt EPHEMERAL selbst auf der einen Systemplatte an, die nodeGroups[*].diskSize jetzt dimensioniert.

Betrieblich bedeutet das:

• Bestehende Tenants rollen automatisch um. Alte Maschinen werden ohne manuellen Eingriff durch Talos-Worker ersetzt, und Migration 45 pinnt die auslaufenden KubeadmConfigTemplate-Objekte mit helm.sh/resource-policy: keep, damit Helm sie nicht mitten im Rollover entfernt. Planen Sie trotzdem einen vollständigen Worker-Pool-Austausch pro Tenant-Cluster ein: Worker-Platten werden neu bereitgestellt, Container-Images neu gezogen.
• Die MachineHealthCheck-Remediation der Worker ist jetzt standardmäßig aktiv. maxUnhealthy wechselt von fest verdrahteten 0 auf nodeHealthCheck.maxUnhealthy mit Vorgabe "50%". CAPI löscht und ersetzt jetzt also ungesunde Worker-Machines. Mit nodeHealthCheck.maxUnhealthy: "0%" behalten Sie das alte Verhalten, bis die Flotte auf Talos stabil ist. Zusätzlich gibt es Overrides pro Node-Gruppe für maxUnhealthy und nodeStartupTimeout, sodass eine Stateful-Gruppe auf 0% bleiben kann, während eine zustandslose 50% toleriert.
• Die Standard-Node-Gruppe md0 wird nicht mehr in jeden Cluster gemischt. nodeGroups ist jetzt {} als Vorgabe, und md0 greift nur noch, wenn gar keine Node-Gruppen konfiguriert sind. Migration 47 pinnt md0 explizit auf bestehende CRs, um die laufende Topologie zu erhalten; sie ist fail-closed und bricht das Upgrade ab, statt Helm ein lebendes md0-MachineDeployment prunen zu lassen.
• Neue Cluster mit nodeGroups: {} starten ohne Worker. Das Chart verwaltet MachineDeployment.spec.replicas nicht mehr — der Cluster-Autoscaler besitzt das Feld allein, initialisiert aus minReplicas: 0. Entweder eine Node-Gruppe mit roles: [ingress-nginx] und minReplicas >= 1 mitgeben, oder den Autoscaler md0 hochfahren lassen, sobald ingress-nginx-Pods Pending werden. Der Vorteil für bestehende Cluster: helm upgrade drainiert Worker nicht mehr bei jedem Plattform-Bump auf fest verdrahtete replicas: 2.
• Air-Gapped-Installationen verlieren den registries.mirrors-Durchgriff auf Tenant-Worker — das per Helm gerenderte Secret *-patch-containerd hat in der Talos-Machineconfig keinen Konsumenten mehr und wurde entfernt. Talos-OS-Image und Installer bleiben über talos.imageFactoryURL und talos.installerRepository überschreibbar, Registry-Spiegelung im Gast ist aber ein Follow-up für Phase 2.
• Worker-Platten nutzen jetzt standardmäßig die anwendungsseitige StorageClass replicated. Eine Node-Gruppe ohne gesetztes storageClass griff früher auf die Default-StorageClass des Management-Clusters zurück; jetzt fällt sie auf die Anwendungs-storageClass zurück, weil linstor-csi v1.11.2 ReadWriteMany-Volumes auf einer Nicht-DRBD-Klasse ablehnt und Worker-VMs RWX für die Live-Migration brauchen. Das gerenderte Worker-Template ändert sich dadurch, jedes Worker-MachineDeployment rollt also einmal.

Die Tenant-HelmRelease kubernetes meldet jetzt Ready, sobald Helm fertig ist (DisableWait), und wartet nicht mehr auf Worker- oder Addon-Bereitschaft; die Gesundheit des Worker-Rollouts verfolgt stattdessen der WorkloadMonitor.

etcd-operator v1alpha2 mit In-place-Adoption

Der etcd-Stack wechselt auf die gespendete API etcd-operator.cozystack.io/v1alpha2 — ein Membership-API-Lebenszyklus anstelle des StatefulSet-Modells —, ausgeliefert über ein von Cozystack gepflegtes Chart mit appVersion v0.5.2. Die CRDs liegen jetzt im eigenen Paket etcd-operator-crds und lassen sich damit vor dem Controller installieren.

Interessant ist das Upgrade. Migration 50 läuft als Pre-Upgrade-Hook, solange noch der alte Operator aktiv ist, und schreibt mit dem Werkzeug etcd-migrate aus dem Migrations-Image Ownership, Labels und CRs so um, dass der neue Operator beim ersten Reconcile die laufende Datenebene übernimmt — ohne Datenumzug, ohne Pod-Neustart. Vorher legt sie zwingend einen Snapshot jedes adoptierten Clusters im Bucket cozy-backups an, unter einem System-Key-Präfix mit für Tenants unsichtbaren Credentials, und bricht laut ab, statt ohne Snapshot zu adoptieren. Außerdem stellt sie Server- und Peer-Zertifikate mit dem nativen Member-Wildcard-SAN des neuen Operators neu aus: Im TLS-Modus secretRef erzeugt der Operator selbst keine Zertifikate, ein adoptierter Cluster ohne die native Domain im Zertifikat würde also beim ersten Memberwechsel still an TLS scheitern — und dabei weiterhin Available=True melden.

Bleibt Migration 50 auf einem Cluster stehen, der bewusst keinen Backup-Speicher hat, gibt es einen dokumentierten Notausgang:

kubectl edit package.cozystack.io cozystack.cozystack-platform

spec:
  components:
    platform:
      values:
        migrations:
          etcdAdoptSkipBackup: true

Flux rendert das Plattform-Chart neu, der Hook läuft erneut und adoptiert jedes Legacy-etcd ohne Snapshot. Eine misslungene Adoption eines etcd unter einer Tenant-Control-Plane ist ohne Snapshot nicht wiederherstellbar. Setzen Sie das Flag danach zurück auf false, sonst überspringt auch die nächste etcd-Migration ihren Snapshot.

SecurityGroup: Netzwerkrichtlinien in Tenant-Hand

Die neue, tenantseitige und namespace-gebundene Firewall-Ressource sdn.cozystack.io/v1alpha1 SecurityGroup erlaubt es Tenants, die Netzwerkrichtlinien ihrer Anwendungen zu verwalten, ohne jeden Zugriff auf die API-Gruppe cilium.io.

Eine SecurityGroup ist eine Mitgliedschaftsgruppe. Sie besitzt ein Mitgliedschafts-Label (securitygroup.sdn.cozystack.io/<name>), das ein neuer securitygroup-controller auf die Pods jeder in spec.attachments gelisteten Managed Application setzt und beim Entfernen eines Attachments wieder abzieht. Die Gruppe bildet 1:1 auf eine CiliumNetworkPolicy im selben Namespace ab, deren endpointSelector genau dieses Label ist — eine SecurityGroup kann damit mehrere Anwendungen gleichzeitig abdecken, und fromSG/toSG-Peers lösen Gruppe-zu-Gruppe-Referenzen live in der Cilium-Datenebene auf. Ein Finalizer schützt die zugrunde liegende Policy, damit Member-Labels immer vor ihrem Entfernen abgezogen werden; die REST-Storage der aggregierten API setzt sie bei jedem Schreibvorgang neu, sodass ein vollständig ersetzendes PUT sie nicht verwaisen lassen kann.

Die wichtige Einschränkung: Ingress- und Egress-Regeln erlauben ausschließlich zusätzlichen Verkehr. Eine leere Regelliste isoliert die Member-Pods nicht, denn die effektive Konnektivität bleibt die Vereinigung aller Policies, die einen Pod selektieren — einschließlich der pauschal erlaubenden Baseline der Plattform. Default-Deny ist separat als künftige Arbeit vorgemerkt. Behandeln Sie eine SecurityGroup in diesem Release also nicht als Segmentierungsgrenze.

Hierarchische Ressourcenquotas

tenant.spec.resourceQuotas wurde bisher zu einer schlichten ResourceQuota pro Namespace, die den Tenant-Baum vollständig ignorierte: Ein Super-Admin innerhalb eines quotierten Tenants konnte einen Sub-Tenant mit größerer oder ganz ohne Quota anlegen und mehr verbrauchen als zugeteilt. Die deklarierte Quota eines Tenants ist jetzt das Budget für seinen gesamten Teilbaum.

Durchgesetzt wird das in zwei zusammenwirkenden Schichten, analog zur ClusterResourceQuota-Aufteilung in OpenShift. Ein Gate zum Deklarationszeitpunkt im aggregierten Apiserver lehnt deterministisch jeden Sub-Tenant ab, dessen deklarierte Quota das verbleibende Budget des Elterntenants übersteigt. Ein Laufzeit-Enforcer im cozystack-controller pflegt pro Namespace eine ResourceQuota namens tenant-quota-allocated, die jedes Poolmitglied auf seinen Anteil begrenzt und die Nutzung über den Teilbaum aggregiert. Kubernetes setzt in einem Namespace stets die restriktivste ResourceQuota durch — das greift also, ohne mit Flux um die vom Chart gerenderte tenant-quota zu ringen.

Prüfen Sie die Sub-Tenant-Quotas vor dem Upgrade. Ein Elternbudget unterhalb der Summe seiner Kinder erzeugt ein Event QuotaOvercommitted, und --tenant-quota-buffer-percent am cozystack-controller bläst Poolbudgets während des Rollouts temporär auf, damit Workloads oberhalb einer frisch greifenden Quota weiterlaufen. Es gibt weder neue API-Typen noch Änderungen am Tenant-Chart — das Feature arbeitet mit dem bestehenden Feld.

OIDC-Single-Sign-on für Tenant-Kubernetes und Grafana

Zwei symmetrische Phase-1-Funktionen erlauben es einem Tenant, einen einzelnen Workload über einen flachen Selektor an den Keycloak-Realm cozy der Plattform anzubinden — ohne Konfiguration auf Plattformebene.

Tenant-kube-apiserver. Jede Kubernetes-CR erhält spec.oidc.mode: System | CustomConfig | None, Vorgabe None. System vertraut dem Realm cozy über einen Public Client pro Cluster mit Audience-Bindung; CustomConfig akzeptiert eine vom Tenant gelieferte strukturierte AuthenticationConfiguration. spec.oidc.users[] erzeugt pro Nutzer ein ClusterRoleBinding im Tenant-Cluster (admin auf cluster-admin, view auf view). Im Modus System wird ein Secret <release>-oidc-kubeconfig mit fertigem kubectl oidc-login-Exec-Block über das Cozystack Dashboard bereitgestellt — ein Tenant-Nutzer kommt damit ohne Zutun des Betreibers von „Cluster existiert“ zu „kubectl läuft mit meiner SSO-Identität“. Der zugrunde liegende Durchgriff auf controlPlane.apiServer.extraArgs, extraVolumes und extraVolumeMounts der KamajiControlPlane ist zusätzlich direkt zugänglich.

Grafana. Jede Monitoring-CR bekommt denselben Selektor. System verdrahtet pro Instanz einen vertraulichen Keycloak-Client mit Audience-Bindung; die Autorisierung erfolgt anwendungsseitig: spec.oidc.users: [{email, role: Admin|Editor|Viewer}] wird von einem chart-eigenen Post-Install- und Post-Upgrade-Job in Grafanas Main Org abgeglichen — Nutzer werden angelegt, der Organisation hinzugefügt, ihre Rolle gepatcht und verwaiste Mitglieder entfernt. CustomConfig akzeptiert eine vom Tenant gelieferte [auth.generic_oauth]-Konfiguration, entweder inline als Map oder als Secret mit Schlüssel auth.ini; im Secret-Fall ist spec.oidc.users nicht unterstützt, und das Chart bricht das Rendering bei dieser Kombination ab, statt sie still zu ignorieren. Das Secret mit admin_user/admin_password bleibt in allen Modi der dokumentierte Break-Glass-Zugang.

Referenz: OIDC aktivieren.

Löschen einer Anwendung gibt jetzt ihren Speicher frei

Das Löschen einer Managed Application ließ bisher Volumes und vom Operator erzeugte Secrets zurück. Ein Zug über zehn Pull Requests im gesamten Katalog schließt das mit Post-Delete-Hooks und PVC-Retention-Policies: ClickHouse-Keeper-, Daten- und Log-PVCs; das Daten-PVC von Qdrant; das Daten-PVC von OpenBAO; Speicher und TLS-Secrets von VictoriaMetrics und VictoriaLogs im Tenant-Monitoring-Modul; Volume-PVCs des Tenant-Moduls seaweedfs; die PVCs data-etcd-* des Tenant-etcd-Moduls; Harbors jobservice- und trivy-PVCs; die vom MariaDB-Operator erzeugten Passwort-Secrets; ACME-Ressourcen von Bucket und Gateway.

Damit ist Löschen unwiderruflich. Das ist der Sinn der Änderung, aber es ist ein echter Verhaltenswechsel gegenüber „Löschen leakt das Volume, und man konnte es zurückholen“. Harbors PVCs werden erzwungen gelöscht und überstimmen persistence.resourcePolicy=keep; Harbors CNPG-Datenbank-PVCs bleiben unangetastet. Die Migrationen 48 und 51 tragen das Release-Label auf bereits existierenden ClickHouse-Keeper- und Monitoring-PVCs nach; beide sind bewusst Best-Effort, im schlechtesten Fall bleibt es beim bisherigen Leak.

Vor dem Löschen sichern. Und den Tenants sagen, dass das jetzt gilt.

Ebenfalls in v1.6.0

• Wildcard-Zertifikate durchgängig. publishing.certificates.wildcardSecretName aus v1.5 galt nur für den Root-Tenant. Der Plattform-Controller repliziert das Zertifikat jetzt in jeden Tenant-Namespace, in dem TLS terminiert wird — Ingress-Controller und Gateways pro Tenant liefern es automatisch aus, ohne namespace-übergreifenden Secret-Zugriff. Neu und optional ist außerdem publishing.certificates.wildcard (Vorgabe false): Die Plattform stellt darüber ein einziges Zertifikat *.<root-host> per DNS-01 auf dem Standard-ingress-nginx-Pfad aus — der praktische Ausweg aus den Rate Limits von Let’s Encrypt bei größeren Installationen.
• Keycloak erhält vier unabhängige Opt-ins: einen KMS-verschlüsselnden Datenbank-Proxy für spaltenweise PII-Verschlüsselung im Ruhezustand, wahlweise mit statischem KEK oder Vault Transit (inklusive Vault-Auth über Kubernetes und AppRole); ein ingress.adminHost, das Admin-Konsole und Administration-REST-API über einen eigenen Hostnamen und eine eigene Route ausliefert, per publishing.ingressNameAdmin an ein privates Gateway oder eine eigene ingressClass anbindbar; Barman-basierte S3-Backups der CNPG-Datenbank; und ein wählbares Login-Theme über die branding-Values der Plattform. Alles standardmäßig aus.
• Unveränderliche Tags und RC-zu-Stable-Promotion. Ein stabiles Release ist jetzt die byte-identische Beförderung des getesteten Release Candidate: Kein Tag wird je zwangsverschoben, Stable wird nie neu gebaut, Images werden per Digest umgetaggt. Der cron-getriebene Workflow auto-release.yaml für Patch-Tags ist ersatzlos entfallen.
• Kamaji läuft standardmäßig mit zwei Repliken und weicher Pod-Anti-Affinität; Telemetrie-Handler und -Webhook sind entfernt, was die Admission-p99 des Apiservers für TenantControlPlane-Webhooks auf Multi-Tenant-Clustern um rund 70 % senkt.
• Remote zugreifbare LINSTOR-StorageClasses werden in Tenant-Cluster propagiert, unter demselben Namen; die über storageClass benannte Klasse (Vorgabe replicated) wird zur Tenant-Default-Klasse, die alte Klasse kubevirt bleibt als Alias erhalten.
• Das Cozystack Dashboard zeigt die externe LoadBalancer-IP jetzt direkt im Services-Tab der Anwendung und rendert explizite Fehler- und Unbekannt-Zustände statt eines endlosen Spinners. Die Konsolen-SPA wird jetzt aus dem Monorepo gebaut; Image und Digest bleiben unverändert.
• Nach dem Upgrade Scrape-Targets auf Port 10250 prüfen — der cert-manager-Webhook, der external-secrets-Webhook und der metrics-server-Listener sind alle von diesem Port weggezogen.

Plattformkomponenten

Die Talos-Systemerweiterungen sind auf den Stand 20260622 aktualisiert, darunter DRBD 9.3.2 und ZFS 2.4.3. Schon das allein rollt jeden Tenant-Worker-Pool einmal durch, weil das Worker-Template für das neue Image umbenannt wird. Die Patch-Versionen für Managed Kubernetes gehen auf v1.32.13, v1.33.13, v1.34.9 und v1.35.6; v1.30 fällt aus der Supportmatrix für Tenants.

Zwei API-Gruppen sind vor allem als Nicht-Ereignis erwähnenswert. Bei SecurityGroup wurde spec.targetRef noch vor dem Release durch das Mitgliedschaftsmodell spec.attachments[] ersetzt — Objekte umschreiben muss also nur, wer zwischen dem 30. Juni und dem 16. Juli 2026 main verfolgt hat. Die Gruppe network.cozystack.io (ExposureClass / ServiceExposure) wurde innerhalb desselben Zyklus eingeführt und wieder entfernt und ist nicht Teil von v1.6.0 — nativer Service mit type: LoadBalancer und loadBalancerClass deckt dasselbe ab, freigelegt als publishing.loadBalancerClass.

Die Patch-Linie 1.6

• v1.6.1 (5. August 2026): CNPG-Operator und CRDs gemeinsam auf 1.28.2 gehoben, was einen PVC-Resize-Deadlock behebt, der einen PostgreSQL-Cluster mit einer einzigen Instanz ohne jede Instanz zurücklassen konnte; der Job talos-reconcile wird jetzt auch für die implizite Gruppe md0 gerendert, sodass die erste vom Autoscaler getriebene Skalierung nicht mehr Machines ohne passendes TalosConfigTemplate dauerhaft blockiert; der Pre-Delete-Job keycloak-configure patcht die HelmRelease im richtigen Namespace und macht Deinstallation und Neuinstallation von Keycloak wieder möglich; das SeaweedFS-Namens-Audit bricht bei Fehlern hart ab; etcd-operator auf v0.5.4.
• v1.6.2 (19. August 2026): das Lookup-Gate der Backup-Strategien, das Velero-CRD-Upgrade und das Nachladen des kube-ovn-Webhook-Zertifikats. Letzteres wiegt schwer: kube-ovn-webhook lud sein Serverzertifikat nur beim Start und las es nie neu ein, sodass nach einer cert-manager-Erneuerung unter failurePolicy: Fail jede Pod-Erstellung in Tenant-Namespaces abgelehnt wurde — inklusive virt-launcher-Pods, was den VMI-Start blockierte. Außerdem: barman-cloud fordert S3-Prüfsummen nur noch, wenn nötig, sodass Backups nach Ceph RGW und manchen MinIO- und R2-Builds nicht mehr komplett scheitern; geshardete helm-controller crashloopen hinter einem HTTP-Proxy nicht mehr; kubectl apply --validate funktioniert wieder gegen die API-Gruppen core und sdn.
• Danach folgten die Patch-Releases v1.6.3 und v1.6.4. Verwenden Sie das neueste 1.6.x; siehe die Cozystack-Releases.

Upgrade

kubectl annotate namespace cozy-system helm.sh/resource-policy=keep --overwrite
kubectl annotate configmap -n cozy-system cozystack-version helm.sh/resource-policy=keep --overwrite

helm upgrade cozystack oci://ghcr.io/cozystack/cozystack/cozy-installer \
  --version 1.6.4 \
  --namespace cozy-system

Die Annotationen sind Pflicht — ohne sie kann das Entfernen oder Aktualisieren des Installer-Releases den Namespace cozy-system samt Inhalt löschen. Bestehende Values wiederverwenden, die Migrations-Hooks beobachten und mit den oben genannten Rollouts rechnen: Tenant-Worker-Pools, die Gatekeeper von Dashboard und linstor-gui, der VPA-Admission-Controller und das Admission-Deployment des linstor-schedulers. Vollständiger Ablauf: Upgrade-Leitfaden.

Wo Ænix ins Spiel kommt

Cozystack ist ein CNCF-Sandbox-Projekt unter Apache 2.0. v1.6 ist ein gutes Release und ein anspruchsvolles Upgrade — der Talos-Worker-Rollover, die etcd-Adoption und die geänderte Löschsemantik verdienen jeweils eine Generalprobe auf einem Nicht-Produktivcluster. Ænix hat Cozystack geschaffen und gehört zu seinen Maintainern; es bietet Enterprise-Support für Cozystack, einschließlich Upgrade-Planung und begleiteter Migration für Teams im Produktivbetrieb.

Release-Links

• Cozystack v1.6.0 auf GitHub
• Cozystack v1.6.2 auf GitHub
• Alle Cozystack-Releases auf GitHub
• Cozystack-v1.6-Dokumentation
• Telegram und Slack (Einladung über slack.kubernetes.io)

Cozystack v1.5.0 ist am 22. Juni 2026 erschienen. Das Release enthält sämtliche Fixes der Patch-Linie v1.4.1 bis v1.4.4 und entwickelt die Plattform in fünf Richtungen weiter: ein zweiter Ingress-Pfad über die Gateway API, Backups ohne S3-Konfiguration pro Anwendung, strengere und shardbare Flux-Reconciliation, TLS für extern veröffentlichte Managed Services und GPU-Passthrough ohne manuelles kubectl patch.

Das Release hat allerdings eine reale Upgrade-Oberfläche. Lesen Sie den nächsten Abschnitt, bevor Sie das Wartungsfenster planen.

Vor dem Upgrade lesen

Installieren Sie heute weder v1.5.0 noch v1.5.1 oder v1.5.2. Gehen Sie direkt auf v1.5.4. Der SeaweedFS-Chart-Sprung in v1.5.0 (4.05 auf 4.31) hat die SeaweedFS-Workloads von chart-basierten auf release-basierte Namen umbenannt. StatefulSet-Namen sind unveränderlich, Helm konnte also nicht in place umbenennen — stattdessen wurde ein zweiter, doppelter Satz neben dem laufenden gestartet. Auf einem Cluster mit mehr Nodes als Master-Repliken lässt sich das leere Duplikat erfolgreich schedulen, beide Generationen tragen identische Pod-Labels, und der Service seaweedfs-s3 verteilt Last auf zwei Filer, die in denselben Metadaten-Store schreiben. Das ist kein kosmetisches Duplikat, sondern ein Datenintegritätsvorfall. Ein verwandter Defekt in Migration 43 konnte zusätzlich den CNPG-Cluster seaweedfs-db — den Index für jedes Objekt im S3 eines Tenants — für jede Instanz löschen, die nicht wörtlich seaweedfs heißt.

Beides ist in v1.5.4 (19. August 2026) behoben: Das Release pinnt fullnameOverride: seaweedfs, adoptiert die laufenden Workloads in place und liefert ein Audit-Skript, das bei Fehlern hart abbricht statt „sauber“ zu melden. v1.5.4 ist das letzte Release der 1.5-Linie und das einzige, das produktiv sinnvoll ist.

Fünf weitere Punkte betreffen jedes 1.5-Upgrade:

• Kubernetes 1.33 oder neuer ist auf dem Management-Cluster Pflicht — und auf jedem Tenant-Cluster, der das Flux-Addon aktiviert. Der helm-controller v1.5 aus Flux v2.8 verlangt es. Kubernetes also zuerst anheben.
• upgrade.force: true ist entfallen. Änderungen an unveränderlichen Feldern heilen sich nicht mehr selbst. Ändert ein Chart-Upgrade etwa volumeClaimTemplates oder serviceName eines StatefulSets, schlägt das Apply fehl; das Objekt muss von Hand neu erzeugt werden (kubectl delete sts <name> --cascade=orphan), danach übernimmt Flux wieder.
• Bei GPU-VMs müssen eigene Host-Devices vorher umgezogen werden. Ist cozystack.gpu-operator aktiv, gehört KubeVirt.spec.configuration.permittedHostDevices jetzt dem Bundle und wird beim ersten Reconcile überschrieben. Handgepflegte Einträge vorher nach .gpu.permittedHostDevices verschieben und prüfen, dass jeder resourceName zu dem passt, was die Nodes tatsächlich anbieten.
• MetalLB wechselt auf das FRR-K8s-BGP-Backend und auf reine HTTPS-Metriken. Mit dem Sprung v0.15.2 auf v0.16.1 übernimmt MetalLB das Upstream-Standard-Backend FRR-K8s; der klassische FRR-Modus ist deprecated. kube-rbac-proxy weicht nativem TLS plus RBAC — jede Scrape-Konfiguration, die noch auf die alten Klartext-HTTP-Endpunkte zeigt, muss angepasst werden. Die Portsperrliste im Host-Netzwerk wurde entsprechend rotiert, inklusive des neuen Probe-Ports 17472 für /healthz und /readyz.
• Extern veröffentlichte Datenbanken und Messaging-Dienste erhalten automatisch TLS. Instanzen mit external: true schalten nach dem Upgrade auf TLS um. Der Trust Anchor ist eine selbstsignierte CA, externe Clients müssen sie also abholen und pinnen. Cluster-interne Instanzen bleiben unberührt.

Und ein Punkt für alle, die später auf 1.6 wollen: v1.5.4 ist das erste 1.5.x-Release mit Migrations-targetVersion: 46. Der Pin, den es auf die CAPI-Objekte KubeadmConfigTemplate setzt, verhindert später, dass ein 1.6-Upgrade diese Templates unter einem noch laufenden, mitten im Rollover befindlichen MachineSet weglöscht. Der schmerzhafte Weg nach 1.6 führt über jede ältere Version der 1.5-Linie.

Gateway API über Cilium

Cozystack-native Dienste lassen sich jetzt über die Gateway API mit Cilium als Datenebene veröffentlichen — optional und parallel zu den bestehenden ingress-nginx-Controllern pro Tenant. Umgesetzt wird das über eine neue CRD gateway.cozystack.io/v1alpha1 TenantGateway, die der cozystack-controller reconciled.

Aktiviert wird der Pfad plattformweit mit publishing.gateway.enabled=true. Ein Tenant bekommt danach entweder mit tenant.spec.gateway=true sein eigenes Gateway samt LoadBalancer-IP und Zertifikat, oder er erbt das Gateway des nächsten übergeordneten Tenants über dasselbe label-basierte Selektormodell, das bereits die Ingress-Vererbung steuert. Zwei Zertifikatsmodi stehen bereit: HTTP-01 als Standard (ein Zertifikat pro Anwendung, ohne Plattformkonfiguration für neue Apps) und optional DNS-01 (ein Wildcard-Zertifikat für eine Apex-Domain, mit Cloudflare, Route 53, DigitalOcean und RFC 2136).

Die Standardeinstellung bleibt ingress-nginx, bestehende Cluster ändern ihr Verhalten also nicht. Zwei Nebenwirkungen treffen jedoch alle:

• Cilium Envoy und die Gateway-API-Unterstützung sind ab sofort immer aktiv. Das bedeutet ein zusätzliches DaemonSet cilium-envoy mit rund 100 MB RAM pro Node im Leerlauf. Auf dicht belegten Nodes einplanen.
• cozystack-api ruft Admission (createValidation / deleteValidation) nun bei Create und Delete für apps.cozystack.io/* auf. Eigene ValidatingAdmissionPolicies oder Webhooks auf diesen Kinds feuern damit bei allen drei Verben.

Referenz: Gateway-API-Leitfaden.

Backups, die ohne Vorarbeit funktionieren

Frühere Releases haben die Backup-Maschinerie installiert. v1.5 schließt die Lücke zwischen „installiert“ und „funktioniert ohne S3-Konfiguration pro Anwendung“.

Neu ist eine plattformverwaltete Standard-BackupClass namens cozy-default, hinterlegt mit dem System-Bucket cozy-backups. Anwendungen aktivieren sie über useSystemBucket; die Plattform projiziert daraufhin gemeinsam genutzte Backup-Credentials mit RBAC-Isolation und Projektionsmetriken in den Tenant-Namespace und verzichtet vollständig auf Credential-Secrets pro Release. Für jede backupfähige Anwendung gibt es jetzt eine Standardstrategie — Velero für VMDisk und VMInstance, CNPG für PostgreSQL, Altinity für ClickHouse, dazu MariaDB, FoundationDB und etcd — und eine Velero-BackupStorageLocation ist auf den System-Bucket verdrahtet. Die alten S3-Felder pro Tenant bei Postgres und ClickHouse sind zugunsten dieses Wegs deprecated.

Velero ist jetzt ein Standard-Systempaket, kein optionales mehr. Das behebt einen deterministischen Fehler: Der Standard-backupstrategy-controller hängt hart von Velero ab, weshalb er auf Clustern ohne Velero in DependenciesNotReady verharrte und die Plattform-HelmRelease nie Ready wurde. Bestehende Cluster erhalten Velero beim Upgrade im Namespace cozy-velero. Wer keine VMs sichert, deaktiviert es über bundles.disabledPackages.

Zwei neue Strategien kommen hinzu. Eine etcd-Strategie (clusterweite CRD strategy.backups.cozystack.io Etcd, nur S3) mit Snapshot-BackupJob und einem destruktiven In-place-RestoreJob. Und eine generische, anwendungsunabhängige Job-Strategie: Der Betreiber liefert ein Kubernetes-Job-Template, Cozystack rendert und startet es als einmaliges Backup und rendert es für die Wiederherstellung erneut mit .Mode == "restore". Namespace-übergreifende Restores unterstützt die Job-Strategie nicht.

Referenzen: Backup und Recovery für Anwendungen, Backup-Konfiguration für Managed Apps.

Flux v2.8 und helm-controller-Sharding

Flux springt von v2.7.3 auf v2.8.0 — sowohl das eingebettete Flux des Management-Clusters als auch das optionale Flux-Addon für Tenants; die Charts flux-operator und flux-instance gehen von v0.33.0 auf v0.50.0.

Der helm-controller v1.5 bringt standardmäßig Server-Side Apply mit --force-conflicts und kstatus-basierte Health-Checks. Zwei praktische Konsequenzen: Falsch platzierte Chart-Felder, die v2.7 stillschweigend verworfen hat, sind jetzt harte Fehler (in diesem Release korrigiert für foundationdb, kafka, kubevirt-instancetypes, vm-instance und das Plattform-Chart), und übergeordnete HelmReleases warten, bis jede untergeordnete Ressource Ready ist, bevor sie selbst Ready melden. Die Korrektheit steigt, die Erstinstallation dauert länger und ist strenger — deshalb haben mehrere Pakete im selben Release explizite spec.timeout- und dependsOn-Einträge bekommen.

Parallel dazu verteilt ein neuer flux-shard-operator die HelmReleases der Tenants über mehrere helm-controller-Shards. Ein lauter Tenant — klassisch eine HelmRelease in endloser Remediation — kann die Reconciliation für alle anderen damit nicht mehr ausbremsen. Die Zuordnung erfolgt pro Tenant: Alle HelmReleases eines Tenants landen im selben Shard, zugewiesen greedy nach geringster Last, wobei ein Mutating Webhook das Shard-Label beim CREATE setzt. Voreinstellung ist shardCount: auto — die Shard-Zahl ergibt sich aus der Anzahl der Tenant-HelmReleases, kleine Cluster bleiben bei einem Shard, große Flotten sharden automatisch; ein Integer fixiert den Wert. Das handgebaute Deployment flux-tenants wird von Migration 44 geleert und stillgelegt.

TLS für Managed-Datenbanken und Messaging

Vier Managed-App-Charts erhalten TLS über einen einzigen Wert tls.enabled mit einheitlicher Drei-Zustands-Semantik. Nicht gesetzt, erbt er von external: TLS ist an, wenn der Dienst extern veröffentlicht wird, und aus, wenn er cluster-intern bleibt. Ein explizites true oder false gewinnt immer. Der Trust Anchor ist in allen Fällen eine chart- oder operatorverwaltete selbstsignierte CA, die Clients abholen und pinnen — eine öffentlich vertrauenswürdige CA gibt es auf diesem Pfad nicht.

• Kafka liefert TLS auf dem externen LoadBalancer-Listener (Port 9094) aus, die Zertifikate verwaltet der Strimzi-Operator durchgängig. Clients vertrauen über die vom Operator veröffentlichten Secrets <release>-cluster-ca-cert und <release>-clients-ca-cert. Der externe Listener hängt jetzt nur noch an external: true und ist von tls.enabled entkoppelt.
• NATS und Qdrant nutzen eine eigenständige cert-manager-Kette (selbstsignierter Issuer, CA, Leaf) im Tenant-Namespace. NATS deckt Client-Verbindungen und Cluster-Routen ab, Qdrant REST und gRPC. Clients vertrauen dem Secret <release>-ca.
• PostgreSQL liefert über CNPG ohnehin immer TLS aus. Hier trägt tls.enabled bei external: true den externen Hostnamen in die SANs des operatorverwalteten Serverzertifikats ein — genau das lässt sslmode=verify-full gegen den externen Endpunkt funktionieren. Clients lesen ca.crt aus dem Secret <release>-credentials.

Die TLS-Arbeit dieses Releases endet bei diesen vier Charts. Die übrigen Managed Services — MariaDB, Valkey, ClickHouse, OpenSearch, RabbitMQ, MongoDB — bleiben unverändert.

GPU-Passthrough ohne manuelles Patchen

Die GPU-Aktivierung ist jetzt auf allen drei Wegen verdrahtet, auf denen eine GPU einen Workload erreichen kann — jeder davon brauchte bisher manuelle Nacharbeit.

Für Tenant-Kubernetes bekommen Node-Gruppen, die gpus deklarieren, automatisch das Kubelet-Label gpu=on, sodass das Device-Plugin von HAMi schedulen und nvidia.com/gpu anbieten kann. Der GPU-Operator im Tenant lädt den Treiber mit NVreg_NvLinkDisable=1 — das behebt den Passthrough einer einzelnen SXM-GPU, der zuvor bei „Fabric State: In Progress“ hängen blieb, während CUDA „system not yet initialized“ meldete. Beide Vorgaben lassen sich über addons.gpuOperator.valuesOverride überschreiben.

Für KubeVirt-VMs befüllt ein aktivierter cozystack.gpu-operator die KubeVirt-CR selbst: Er injiziert das Feature Gate HostDevices und füllt permittedHostDevices (sowie mediatedDevicesConfiguration für vGPU) aus mitgelieferten NVIDIA-Standardtabellen. GPU-VMs lassen sich damit ohne manuelles Patchen schedulen — zum Preis des Ownership-Wechsels aus den Upgrade-Hinweisen oben.

Zusätzlich gibt es eine dritte container-Variante des GPU-Operators für Hosts, auf denen NVIDIA-Treiber und Container-Toolkit bereits vom Betriebssystem installiert sind; sie stellt GPUs ausschließlich über das Device-Plugin an gewöhnliche Container-Pods bereit.

GPU-Sharing bleibt in Cozystack die Kombination aus NVIDIA GPU Operator und HAMi. Referenz: GPU-Sharing und Operator-Varianten.

Ebenfalls in v1.5.0

• Löschschutz. Objekte mit dem Label platform.cozystack.io/no-delete=true lassen sich nicht mehr direkt löschen. Die Prüfung läuft prozessintern im kube-apiserver über eine ValidatingAdmissionPolicy — ohne Webhook, DaemonSet, TLS oder zusätzliches Image. Geschützt sind in diesem Release die Namespaces cozy-system und tenant-root, die HelmRelease tenant-root, die ConfigMap cozystack-version, die OCIRepository cozystack-packages, die cert-manager-ClusterIssuer, der LinstorCluster und die Packages-CRDs. Zum Löschen zuerst das Label entfernen: kubectl label <kind> <name> platform.cozystack.io/no-delete-. Voraussetzung ist Kubernetes 1.30+.
• Dropdowns im Dashboard mit Laufzeitdaten. Eine neue, namespace-gebundene und nur lesbare Ressource Option (core.cozystack.io/v1alpha1), berechnet beim Lesen durch eine privilegierte In-Process-Provider-Registry, plus das Schema-Schlüsselwort x-cozystack-options, das Charts deklarieren. GPU-Geräte, KubeVirt-Instancetypes und -Preferences, Multus-Netze, VM-Images, Storage-Pools, StorageClasses, BackupClasses und Backup-Pläne werden damit im Cozystack Dashboard zu echten Dropdowns statt Freitext oder veralteter statischer Enums. Tenants erhalten lesenden Zugriff auf die Optionen im eigenen Namespace.
• Tenants dürfen ihre VMs starten, stoppen und neu starten. Das fehlende update auf den KubeVirt-Subressourcen virtualmachines/start, /stop und /restart ist jetzt auf Ebene cozy:tenant:use:base erteilt; die Power-Buttons im Dashboard lieferten zuvor für jede Tenant-Rolle 403.
• Grafana-Dashboard „Tenant Overview“ für Plattform-Admins, ausgerollt nur in das Root-Grafana in cozy-monitoring und nie in die Grafanas einzelner Tenants, sowie eine neue Admin-Seite Cluster Usage mit eigener ClusterRole cozystack-dashboard-cluster-usage (clusterweite und Node-bezogene Auslastung inklusive GPUs). Ohne das Binding ist der Sidebar-Eintrag fail-closed.
• storageClass ist bei 16 Stateful-Apps als unveränderlich markiert — ein Wechsel migriert nie Daten, weil PVCs storageClassName bei der Erstellung festschreiben. Die Durchsetzung ist in v1.5.0 rein UI-seitig: Der aggregierte Apiserver wertet die CEL-Regel bei Update noch nicht aus, ein direktes kubectl patch wird also weiterhin akzeptiert.
• Erwähnenswerte Fixes: cozystack-api veröffentlicht das freie .spec jetzt als x-kubernetes-preserve-unknown-fields statt additionalProperties: true — Letzteres brachte den kube-controller-manager clusterweit mit einem Nil-Pointer-Panic im VAP-Typechecker zum Absturz. Tenant-Kubeconfigs verwenden für den Keycloak-OIDC-Issuer den Root-Host, sodass kubectl oidc-login bei Nicht-Root-Tenants nicht mehr an der TLS-Prüfung scheitert. config_path für Registry-Konfiguration funktioniert auf containerd-2.x-Tenant-Nodes. RWX-Block-Volumes laufen über den Upstream-Hotplug-Detach statt über den NFS-Cleanup-Zweig. OpenSearch wird endlich vom PaaS-Bundle referenziert.

Plattformkomponenten

kuberture ist standardmäßig aus. Es schließt eine Lücke von external-dns — external-dns kann keine EndpointSlices lesen — indem es die EndpointSlice default/kubernetes des API-Servers beobachtet und annotierte Headless Services erzeugt, die external-dns konsumiert, um den Kubernetes-API-Endpunkt im DNS zu veröffentlichen. Aktivierung über bundles.enabledPackages mit mindestens einem Eintrag unter config.outputs.

Die Patch-Linie 1.5

• v1.5.1 (24. Juni 2026) behebt eine Regression aus v1.5.0: Für die KubeVirt-Preferences windows.11, windows.2k22 und windows.2k25 war der persistente EFI/TPM-Zustand wieder aktiviert worden. KubeVirt legt dafür ein ReadWriteOnce-PVC persistent-state-for-<vm> auf der StorageClass replicated an — das bindet die VM an ihren Node und blockiert Live-Migration und Node-Drains. Auf Clustern mit evictionStrategy: LiveMigrate kann das ein Cluster-Upgrade vollständig anhalten. Secure Boot und vTPM funktionieren weiterhin; nur der Zustand überlebt keinen Reboot.
• v1.5.2 (3. Juli 2026) bringt zehn Fixes, darunter ein Kamaji-DataStore-Deadlock beim Löschen, der Tenant-Namespaces festfahren konnte, eine victoria-metrics-operator-Abhängigkeit, die bei certManager.enabled: false nie auflösbar war, und MariaDB-Instanzen mit einer Replik, die der Operator-Webhook ablehnte.
• v1.5.3 wurde getaggt, das GitHub-Release blieb aber ein Entwurf und wurde nie veröffentlicht. Kein Betreiber hat es erhalten.
• v1.5.4 (19. August 2026) ist das letzte Release der 1.5-Linie und die Version, die ausgerollt gehört.

Upgrade

kubectl annotate namespace cozy-system helm.sh/resource-policy=keep --overwrite
kubectl annotate configmap -n cozy-system cozystack-version helm.sh/resource-policy=keep --overwrite

helm upgrade cozystack oci://ghcr.io/cozystack/cozystack/cozy-installer \
  --version 1.5.4 \
  --namespace cozy-system

Die Annotationen sind Pflicht, keine Empfehlung: Ohne sie kann das Entfernen oder Aktualisieren des Installer-Releases den Namespace cozy-system samt Inhalt löschen. Bestehende Values wiederverwenden. Vollständiger Ablauf und Prüfschritte danach: Upgrade-Leitfaden.

Wo Ænix ins Spiel kommt

Cozystack ist ein CNCF-Sandbox-Projekt unter Apache 2.0, und die beschriebenen Upgrade-Pfade gelten für alle gleichermaßen. Ænix hat Cozystack geschaffen und gehört zu seinen Maintainern; es bietet Enterprise-Support für Cozystack — inklusive Upgrade-Planung für die scharfen Kanten dieses Releases — für Teams, die die Plattform nicht allein tragen wollen.

Release-Links

• Cozystack v1.5.0 auf GitHub
• Cozystack v1.5.4 auf GitHub
• Cozystack-v1.5-Dokumentation
• Telegram und Slack (Einladung über slack.kubernetes.io)

Warum die White-Label-Cloud für MSPs wichtig ist

MSPs haben Kundenbeziehungen, die Hyperscaler nicht ohne Weiteres nachbilden können. Ihnen fehlt jedoch das Cloud-Produkt, um diese Beziehungen im großen Maßstab zu monetarisieren. Die White-Label-Cloud — als Produkt des MSP gebrandet, betrieben auf geteilter oder dedizierter Infrastruktur — schließt diese Lücke.

Das Muster 2026: Der MSP erhält ein gebrandetes, mandantenfähiges Cloud-Produkt auf einer Open-Source-Plattform; die Kunden nutzen die Cloud unter der Marke des MSP; der MSP vereinnahmt die Marge zwischen Plattformkosten und Kundenpreis.

Architektur

• Mehrstufiges Tenant CRD — Root-Tenant → MSP-Tenant → Tenant des MSP-Kunden. Isolation auf jeder Ebene.
• Gebrandetes Cozystack Dashboard — der MSP kann Farben, Logo, Domain und die Optionen des Servicekatalogs anpassen
• WHMCS-Integration (proprietäres Ænix-Modul) — die Abrechnung läuft über das bestehende Kundenverwaltungssystem des MSP
• Servicekatalog — der MSP kann festlegen, welche Services er seinen Kunden anbietet (z. B. Kafka ausblenden, wenn er es nicht unterstützt)
• SLA-Management — Nachverfolgung des SLA pro Kunde über die Observability von Cozystack

Reseller-Ökonomie

Typische Ökonomie für einen MSP, der eine White-Label-Cloud betreibt:

• Plattformkosten — Ænix-Subskription (White-Labeling ab der Standard-Stufe, 3.000 $ pro 10 Nodes und Monat; siehe Preise) + Hardware + Colocation
• Kosten pro Kunde — zusätzliche Hardware, Storage und Bandbreite
• Kundenpreis — typischerweise 30–50 % über den reinen Plattformkosten
• Marge — deckt Support, Vertrieb und Betrieb des MSP

Der Break-even liegt bei 30–50 zahlenden Kunden, wenn Sie Plattform und Werkzeuge abdecken; bei 50–100, wenn zusätzlich eine eigene Rufbereitschaft finanziert wird. Danach ist die Ökonomie positiv, abhängig vom Kundenmix.

Aufbau des Engagements

• Platform Readiness Assessment (14 oder 28 Tage, Festpreis) inklusive Produktreife
• Plattform live in wenigen Wochen über den produktisierten Installer, sobald die Hardware bereitsteht; Produkt- und Vertriebsarbeit läuft parallel in den folgenden Monaten
• Optionale Managed Services

Die Telco-Cloud-Diskussion des Jahres 2026 steht an einem ungewöhnlichen Schnittpunkt von Belastungen, denen keine andere Branche gleichzeitig ausgesetzt ist. NFV-Deployments aus den Jahren 2015–2020 kommen in die Jahre. NIS2-Pflichten gelten für die gesamte Infrastruktur des Betreibers. Als souverän vermarktete Cloud-Produkte sind kommerziell attraktiv (eine regionale Souveränitätspositionierung können Hyperscaler nur schwer nachbilden). Die Nachfrage nach Edge Compute für 5G/6G-Workloads wächst. AI für den Netzbetrieb (Verkehrsprognose, Anomalieerkennung, kundennahe Assistenten) entsteht gerade.

Die architektonische Antwort lautet selten „eine Plattform für alles“ — Telcos haben mehrere Betriebsdomänen, jede mit eigenen Randbedingungen. Die Muster, die über alle Domänen hinweg funktionieren, sind jedoch zu Kubernetes-nativen Multi-Site-Plattformen mit starker Mandantentrennung, souveränem Betrieb und Edge-bewusstem Scheduling zusammengewachsen.

Was die Modernisierung tatsächlich ersetzt

Die meisten europäischen Tier-1-Telcos betreiben 2026 drei oder vier parallele Infrastrukturumgebungen:

1. Legacy-NFV-Umgebung (Baujahr 2015–2020)

Typischerweise aufgebaut auf VMware Cloud Foundation, auf OpenStack-basierten Herstellerdistributionen (Red Hat OSP, Mirantis Cloud Platform, Wind River usw.) oder auf herstellerspezifischer NFVI (Ericsson CEE, Nokia CloudBand). Sie hostet VNFs von Netzwerkausrüstern mit herstellerspezifischen Zertifizierungsanforderungen.

Treiber der Modernisierung: Lebenszyklen der Herstellerdistributionen (EOL von Red Hat OSP, Umbruch bei Mirantis), die VMware-Preise unter Broadcom und eine betriebliche Komplexität, die mit jeder Fluktuation im Team zunimmt. Die meisten Tier-1-Betreiber haben parallele Modernisierungsprogramme laufen.

2. IT-Cloud (getrennt von NFV)

Für Business-Workloads, Kundenportale, Billing, OSS/BSS. Typischerweise eine separate VMware-Landschaft oder ein Deployment in einer Hyperscaler-Region. Bei VMware derselbe Broadcom-Druck, beim Hyperscaler-Deployment der Souveränitätsdruck.

3. Edge Compute (5G/6G-Ära)

Verteilte Edge-Standorte in Umspannwerken, Vermittlungsstellen und MEC-Knoten. Deployments mit kleinerem Footprint und zeitweise unterbrochener Anbindung an den Core. Häufig auf einem anderen Stack als die Core-Plattform aufgebaut (ältere Orchestrierung für kleine Footprints).

4. AI / Data Lake / Netzanalytik

Eine neuere Umgebung für Verkehrsprognose, Anomalieerkennung und kundennahe AI. Heute oft beim Hyperscaler; bei sensiblen Workload-Mustern wächst der Souveränitätsdruck, sie on-prem zu holen.

Die Vision einer einzigen Plattform (und wo sie funktioniert)

Der architektonische Reiz einer Modernisierung auf Basis von Cozystack ist eine einheitliche Plattform über alle vier Umgebungen hinweg: ein Betriebsmodell, ein Upgrade-Lebenszyklus, ein Observability-Stack, föderierte Identitäten, GitOps-gesteuerte Änderungen.

Wo das funktioniert:

• IT-Cloud-Workloads — ein unkompliziertes Deployment auf Basis von Cozystack. Die meisten IT-Cloud-Modernisierungen bei Tier-1-Telcos folgen diesem Muster.
• AI / Data Lake / Analytics — Workload-Muster der Cozystack AI Platform; standardmäßig souverän; mandantenfähig für den Zugriff über Geschäftsbereiche hinweg.
• Edge Compute — Cozystack unterstützt Edge-Deployments mit kleinem Footprint und Föderation zum Core. Standardisiert über alle Standorte.

Wo eine differenzierte Betrachtung nötig ist:

• Speziell die NFV-Umgebung — die VNF-Zertifizierung mit Herstellerausrüstung wird weiterhin von den Herstellern gesteuert. Die darunterliegende Cozystack-Plattform kann KubeVirt-basierte VNFs hosten, der Zertifizierungs-Stack bleibt aber an die Hersteller gebunden. Manche VNFs sind auf bestimmten OpenStack-Distributionen zertifiziert und brauchen einen parallelen Modernisierungsstrang.
• Kritisches Netz-OAM im SCADA-Stil — vom Netz getrennte (air-gapped) Netzmanagementsysteme mit eigenem Betriebsmodell. Cozystack kann sie hosten, die OT-artige Betriebsdisziplin unterscheidet sich jedoch von der IT-Cloud.

Das praktische Muster: Cozystack als IT-Cloud-Plattform, AI-Plattform und Edge-Plattform; NFV erhält einen eigenen Modernisierungsstrang mit einer Cozystack-äquivalenten Architektur, soweit die Herstellerzertifizierung es zulässt.

Mandantenfähigkeit im Telco-Umfeld

Telcos haben mehrschichtige Anforderungen an die Mandantenfähigkeit:

• Trennung der operativen Geschäftsbereiche — Festnetz-Breitband, Mobilfunk, Geschäftskunden, Privatkunden; jeder Geschäftsbereich hat eine andere operative Verantwortung.
• Kundenseitige Services — der Telco bietet seinen Geschäftskunden Cloud-Kapazität an (Produktlinie souveräne Cloud); jeder Kunde ist ein eigener Tenant.
• Interne versus externe Workloads — rein interne Workloads (OAM, Observability-Backends) gegenüber kundenseitigen Workloads (Cloud-Produkt, Kundenportal).
• Sektorale bzw. regulierte Tenants — Telcos hosten zunehmend regulierte Workloads (Nähe zum Finanzsektor, Aufträge der öffentlichen Hand) mit sektoraler Tenant-Isolation.

Das Tenant-CRD-Modell von Cozystack mit verschachtelten Tenants unterstützt alle vier Ebenen nativ. Ein Tier-1-Telco betreibt typischerweise 5–50 Top-Level-Tenants mit Hunderten bis Tausenden verschachtelter Tenants.

Positionierung über Souveränität

Für Telcos ist Souveränität nicht nur eine Compliance-Frage, sondern ein kommerzielles Unterscheidungsmerkmal. Europäische Kunden sehen Abhängigkeiten von Hyperscalern mit Hauptsitz in den USA zunehmend als strukturelles Risiko. Telcos können in ihrer Region souveräne Cloud-Produkte anbieten, mit denen von Hyperscalern betriebene Angebote bei den inhaltlichen Souveränitätskriterien nicht mithalten können.

Eine Architektur auf Basis von Cozystack unterstützt das kommerziell:

• Verschlüsselung mit Passphrase beim Kunden — optionale Volume-Verschlüsselung im Ruhezustand (LINSTOR und LUKS); die Passphrase verwaltet der Kunde des Telcos, der Telco leistet den Betriebssupport
• Air-Gap-Option — für Anwendungsfälle mit Verschlusssachen
• Open-Source-Fundament — Exit-Fähigkeit ist eingebaut; der Telco bindet seine Kunden nicht an eine Herstellerbeziehung
• EU-Rechtsraum — die EU-Präsenz des Telcos plus die EU-Vertragsgesellschaft von Ænix (AENIX s.r.o.)

Für kommerzielle Produktlinien einer souveränen Cloud ist die Ænix Public Cloud Platform die typische Ergänzung — mehrere Regionen, mehrere Rechenzentren, ein tiefer Servicekatalog und ein Kundenportal im eigenen Markenauftritt.

Die Realität von Edge Compute

5G/6G hat Anforderungen an verteiltes Computing mit sich gebracht, die die Architektur der NFV-Ära nicht vorhergesehen hat. Modernes Edge Compute für den Telco-Betrieb umfasst:

• MEC-Knoten (Multi-access Edge Computing) an Basisstationen oder Vermittlungsstellen für latenzarme Kunden-Workloads
• Verteilte RAN-Intelligenz — vRAN-/O-RAN-Workloads mit Echtzeitanforderungen
• Customer-Edge-Compute — vom Telco verwaltete Edge-Instanzen beim Kunden vor Ort (Fabriken, Smart-Grid-Standorte, Verkehrsknotenpunkte)
• Sektorale Edge — vom Telco betriebene Edge für Branchenkunden (Bankfilialen, Gesundheitseinrichtungen, Einzelhandel)

Cozystack unterstützt Edge-Deployments mit reduziertem Footprint (typisch sind Cluster mit rund 3 Nodes an Edge-Standorten) und Föderation zu regionalen und zentralen Plattformen. Dasselbe Betriebsmodell, dieselbe Observability, ein je Ebene differenzierter Servicekatalog.

AI für den Telco-Betrieb

Die AI-Workload-Muster bei Tier-1-Telcos:

• Verkehrsprognose und Kapazitätsplanung — Inferenz rund um die Uhr auf Netztelemetrie
• Anomalieerkennung — Sicherheits- und Betriebsanomalien in Echtzeit
• Kundennahe AI — Chatbot, Unterstützung bei Rechnungsfragen, Routing im Kundenservice
• Netzoptimierung — Routing, Traffic Engineering, Energieeffizienz
• Betrugserkennung — Erkennung von Transaktionsanomalien, Identitätsprüfung
• Sektorale AI-Services — vom Telco gehostete AI-Kapazität für Branchenkunden (AI für Banken, Gesundheitswesen und öffentlichen Sektor)

Es dominieren Workload-Profile mit dauerhaft hoher Auslastung — genau der Fall, in dem dedizierte GPUs wirtschaftlich besser abschneiden als der Hyperscaler. Die Ænix AI Platform passt dazu.

Phasen einer Tier-1-Telco-Modernisierung

Die Cloud-Plattform folgt dem Muster im Betreibermaßstab: 3–6 Monate Pilot, danach 9–18 Monate bis zum vollen Multi-Region-Betrieb. Edge-Ausbau und NFV-Modernisierung laufen als längere parallele Stränge, getaktet durch den Standort-Rollout und die Lebenszyklen der Hersteller. Eine typische Aufteilung in Phasen:

Phase 0 — Strategisches Engagement (Beginn des Pilots)

Architektur-Review über alle vier Umgebungen. Kommerzielle Abstimmung zur Produktlinie souveräne Cloud, zur sektoralen Positionierung und zur Reihenfolge der Modernisierung. Benennung von Sponsoren und Leitungen der Arbeitsstränge.

Phase 1 — Modernisierung der IT-Cloud

Die Ænix Private Cloud Platform bzw. Public Cloud Platform wird bereitgestellt. Interne Workloads werden migriert. Das Kundenportal für das souveräne Cloud-Produkt geht live.

Phase 2 — AI / Data Lake (parallel)

Die Ænix AI Platform wird bereitgestellt. Workloads der Netzanalytik wandern on-prem. Kundennahe AI-Services gehen live.

Phase 3 — Ausbau der Edge (fortlaufend, getaktet durch den Standort-Rollout)

Edge-Standorte werden an MEC-, Vermittlungsstellen- und Customer-Edge-Standorten aufgebaut. Identitäten und Observability sind übergreifend föderiert.

Phase 4 — NFV-Modernisierung (parallel, getaktet durch die Lebenszyklen der Hersteller)

Replatforming herstellerzertifizierter VNFs, wo zulässig. Greenfield-Deployments neuer VNFs auf einer Architektur auf Basis von Cozystack. Die Legacy-NFV-Umgebung wird parallel weiterbetrieben, bis der Lebenszyklus des Herstellers ein Upgrade erzwingt.

Ab Phase 5 hängt alles vom Wachstum des kundenseitigen Produkts ab: regionale Expansion, sektorale SKUs, neue Service-Familien.

Wann das zu einem Telco passt

Gute Passung:

• Europäischer Tier-1- oder Tier-2-Telekommunikationsbetreiber
• Ein laufendes Programm zur Modernisierung von Legacy-NFV
• Die strategische Absicht, eine Produktlinie souveräne Cloud anzubieten
• Ein Budgetrahmen in Millionenhöhe über ein mehrjähriges Programm
• Rückendeckung auf oberster Führungsebene (CIO / CTO / Leitung des Cloud-Geschäftsbereichs)

Bedingte Passung:

• Kleinere Betreiber (regional, MVNO-artig), die Cloud verkaufen — die Ænix Public Cloud Platform im Providermaßstab zu den veröffentlichten Preisen statt eines vollständigen Betreiberprogramms
• Betreiber mit umfangreicher, noch funktionierender OpenStack-basierter NFV-Investition — die Modernisierung kann warten, bis der Lebenszyklus des Herstellers sie erzwingt

Weiterführende Inhalte

• Branchenseite Telco — die kommerzielle Landingpage
• Produktseite Public Cloud Platform — das Produkt für Telcos, die Cloud-Services verkaufen
• Sovereign-Cloud-Builder-Leistungen — für den Aufbau einer Produktlinie souveräne Cloud
• Sovereign-AI-Leistungen — für AI-Workload-Muster
• Phasen des Aufbaus einer Public Cloud Platform — mehrjährige Aufbauphasen
• Entscheidungen für eine Sovereign-AI-Architektur — sieben Entscheidungen für Sovereign AI

SRE — Site Reliability Engineering — gehört zu den am weitesten verbreiteten und zugleich am häufigsten missverstandenen Engineering-Disziplinen des letzten Jahrzehnts. Die meisten mittleren und großen Engineering-Organisationen behaupten, „SRE zu machen“. Deutlich weniger betreiben die Disziplin tatsächlich so, wie sie das ursprüngliche SRE-Buch von Google beschreibt: als Softwareentwicklung, angewandt auf den Betrieb, mit expliziten Error Budgets, SLOs, die die Priorisierung beeinflussen, und einer harten Obergrenze für operativen Toil.

Was SRE genau bedeutet

Die ursprüngliche Google-Formulierung ruht auf drei tragenden Eigenschaften:

1. SRE ist Softwareentwicklung, angewandt auf den Betrieb

SREs sind Softwareentwickler — sie schreiben Code, liefern Systeme aus und automatisieren den Betrieb. Sie sind kein umbenanntes Ops-Team mit derselben Aufgabe und einem schickeren Titel. Die Frage „Schreibt Ihr SRE eigentlich Code?“ ist ein echter Test; Teams, die ihn nicht bestehen, haben eine Betriebsfunktion, keine SRE-Funktion.

2. Error Budgets beeinflussen die Priorisierung

Das SLO definiert die Messlatte. Das Error Budget ist die Differenz zwischen 100 % und dem SLO-Zielwert. Ist das Error Budget aufgebraucht, verschiebt sich die Priorisierung des Produktteams — die Feature-Arbeit pausiert, Zuverlässigkeitsarbeit hat Vorrang. Ist das Error Budget gesund, kann die Feature-Arbeit weiterlaufen.

Entscheidend ist: Das ist ein Vertrag, keine Empfehlung. Eine SLO-Verletzung hat echte Folgen für die Produkt-Roadmap. Organisationen, die SLOs haben, sie aber die Roadmap nicht beeinflussen lassen, haben Observability, keine SRE-Praxis.

3. Operativer Toil ist begrenzt (oft auf 50 %)

Die Google-Formulierung lautet: SREs dürfen höchstens 50 % ihrer Zeit mit operativem Toil verbringen (wiederkehrender, manueller, automatisierbarer Arbeit). Der Rest muss in Softwareentwicklung fließen, die Toil reduziert. Dadurch verbessert sich die Funktion mit der Zeit selbst — der Toil sinkt, die Engineering-Kapazität steigt.

Teams, die die Toil-Grenze strukturell überschreiten, haben eine Betriebsfunktion, die sich als SRE ausgibt. Die Disziplin erodiert über Monate, bis die Funktion nicht mehr vom klassischen Betrieb zu unterscheiden ist.

Drei Engagement-Modelle

Im Jahr 2026 sind drei strukturell unterschiedliche SRE-Modelle im produktiven Einsatz:

Modell 1: eingebettetes SRE

SREs sitzen in den Produktteams. Ein Produktteam umfasst 2–5 Engineers, von denen einer die SRE-Funktion übernimmt. Dasselbe Team verantwortet Features und Zuverlässigkeit; der SRE prägt Architektur und Bereitschaftsdienst von innen heraus.

Stärken: Ausrichtung zwischen SRE- und Produktprioritäten, schnelles Feedback, keine Reibung zwischen Teams.

Schwächen: Die SRE-Qualität schwankt von Team zu Team, abhängig von der eingebetteten Person. Zentrale SRE-Expertise wächst nicht kumulativ. Über viele Produktteams hinweg lässt sich das Modell kaum skalieren, ohne an Konsistenz zu verlieren.

Passt für: Organisationen mit 100–300 Engineers, in denen jedes Produktteam klare Verantwortung trägt und pro Team etwa ein Engineer mit SRE-Kompetenz verfügbar ist.

Modell 2: zentrale SRE-Funktion

SREs sitzen in einer eigenen Funktion mit eigener Berichtslinie. Sie beraten die Produktteams, setzen Zuverlässigkeitsstandards, betreiben gemeinsam genutzte Infrastrukturkomponenten und die Services auf dem kritischen Pfad.

Stärken: SRE-Expertise wächst kumulativ. Standards sind über Teams hinweg konsistent. Services auf dem kritischen Pfad haben dedizierte Verantwortliche für ihre Zuverlässigkeit.

Schwächen: Reibung zwischen Teams, wenn SRE-Empfehlungen mit den Prioritäten der Produktteams kollidieren. Es besteht das Risiko, dass SRE als Bremse statt als Ermöglicher wirkt.

Passt für: Organisationen ab 300 Engineers mit mehreren Services auf dem kritischen Pfad und einer klaren Platform-Engineering-Funktion. Häufig mit Platform Engineering als Schwesterfunktion kombiniert.

Modell 3: hybrid (eingebettet plus zentral)

Eingebettete SREs in den Produktteams kümmern sich um die teamspezifische Zuverlässigkeit. Eine zentrale SRE-Funktion betreibt die gemeinsame Infrastruktur, setzt Standards und übernimmt die Eskalation bei teamübergreifenden Incidents.

Stärken: verbindet die Vorteile beider Ansätze. Das häufigste Muster in großen Organisationen (Google, Netflix, große Fintechs).

Schwächen: erfordert eine erhebliche Größe, um die doppelte Investition zu rechtfertigen. Unterhalb von 500 Engineers lässt sich der Overhead kaum amortisieren.

Passt für: Organisationen ab 500 Engineers mit mehreren Geschäftsbereichen und einem umfangreichen Portfolio zuverlässigkeitskritischer Workloads.

Wo SRE zum Theater wird

Muster, die wir in Assessments beobachten:

Theater 1: SLOs existieren, beeinflussen die Roadmap aber nicht

SLOs sind dokumentiert. Dashboards zeigen die SLO-Einhaltung. Quartalsreviews erwähnen SLO-Trends. Die Priorisierung der Produktteams läuft jedoch unabhängig vom Zustand des Error Budgets. Kommt es zu einer SLO-Verletzung, folgt eine incidentbezogene Feuerwehraktion, aber keine Neupriorisierung der Roadmap.

Das ist Observability mit SLO-Etiketten, keine SRE-Praxis. Für Kaufentscheidungen ist die Unterscheidung wichtig: Organisationen in diesem Zustand brauchen nicht mehr Dashboards, sondern ein anderes Governance-Modell.

Theater 2: SRE-Titel für klassischen Betrieb

Betriebsingenieure werden in „SRE“ umbenannt, ohne dass sich ihre Arbeitsinhalte ändern. Sie verbringen weiterhin 90 % ihrer Zeit mit der Ticket-Queue. Über Shell-Skripte hinaus schreiben sie keinen Code. Über das Error Budget haben sie keinerlei Entscheidungsbefugnis.

Das ist ein Etikettenwechsel, kein Wandel der Disziplin. Typisch für Übergänge von DevOps zu SRE, in die kein Executive Sponsor investiert hat.

Theater 3: Error Budgets definiert, aber nie angewendet

Error Budgets werden berechnet. Einige Dashboards zeigen sie an. Es gibt aber keinen Prozess dafür, was passiert, wenn sie aufgebraucht sind. Faktisch ist das dasselbe wie gar kein Error Budget.

Abhilfe: Schreiben Sie das explizite Protokoll für den Feature-Stopp auf, das beim Aufbrauchen des Error Budgets greift. Lassen Sie es von der Produktführung absegnen. Testen Sie es einmal mit einem künstlichen Budgetverbrauch, bevor Sie davon ausgehen, dass es in Produktion funktioniert.

Theater 4: Post-Mortems ohne Maßnahmen

Nach Incidents finden Post-Mortems statt. Sie werden geschrieben. Sie landen in einem Ordner. Keine einzige Maßnahme wird bis zum Abschluss verfolgt. Dieselbe Klasse von Incidents tritt innerhalb von sechs Monaten erneut auf.

Abhilfe: Maßnahmen aus Post-Mortems kommen in dasselbe Backlog wie die Feature-Arbeit — mit benannten Verantwortlichen, Fälligkeitsterminen und expliziter Priorisierung. Ein Post-Mortem hat nicht funktioniert, wenn seine Maßnahmen nicht umgesetzt werden.

Was ein SRE-Engagement von Ænix liefert

Typischerweise arbeiten wir mit Organisationen, deren SRE-Praxis sich in einem von drei Zuständen befindet:

• Vor SRE — keine formale SRE-Funktion; Zuverlässigkeit ist incidentgetriebene Feuerwehrarbeit. Das Engagement umfasst die Definition der Funktion, einen Einstellungsplan und erste SLOs für kritische Services.
• SRE im Theater-Zustand — SRE-Titel und Dashboards gibt es, die Disziplin ist aber nicht angekommen. Das Engagement diagnostiziert, welche Theater-Muster wirken, entwirft Korrekturen und umfasst häufig funktionsübergreifende Governance-Arbeit.
• Reifes SRE, das wachsen muss — die Disziplin funktioniert in einem Geschäftsbereich und muss nun auf die ganze Organisation skalieren oder neue Service-Familien aufnehmen (AI/GPU-Workloads, Edge Compute, souveräne Cloud). Das Engagement konzentriert sich auf Konsistenz und Wissenstransfer.

Arbeitsstrang 1 — SLO-Definition

Für jeden kritischen Service definieren wir:

• SLI (Service Level Indicator) — was wir messen
• SLO (Service Level Objective) — den Zielwert
• Error Budget — die Differenz zwischen 100 % und dem SLO
• Burn-down-Policy — was geschieht, während das Budget verbraucht wird
• Erholungsschwelle — was die Priorität der Feature-Arbeit wiederherstellt

Ænix definiert Ihre SLOs nicht isoliert für Sie — wir moderieren den Workshop, in dem Engineering- und Produktführung sie gemeinsam erarbeiten. SLOs ohne gemeinsame Verantwortung setzen sich nicht durch.

Arbeitsstrang 2 — Incident-Response-Prozess

Rollen (Incident Commander, Protokollführung, Kommunikation). Schweregrad-Klassifizierung. Aufbau der Runbooks. Eskalationswege. Vorlage für Blameless Post-Mortems. Nachverfolgung der Maßnahmen.

Häufig ist das der Arbeitsstrang mit der größten Hebelwirkung — das Framework vervielfacht die Wirksamkeit bei jedem künftigen Incident.

Arbeitsstrang 3 — Toil messen und reduzieren

Wir inventarisieren die aktuelle Arbeit des SRE- bzw. Ops-Teams und kategorisieren sie: Toil (wiederkehrend, manuell, automatisierbar) gegenüber Engineering (dauerhaft, automatisierungserzeugend). Dann messen wir den Toil-Anteil.

Wir empfehlen die 3–5 Automatisierungen, die den meisten Toil abbauen, staffeln sie nach ROI und übergeben sie dem Engineering-Team zur Umsetzung; bei Bedarf unterstützen wir.

Arbeitsstrang 4 — Observability-Stack

Die Standardempfehlung von Ænix für Observability: VictoriaMetrics für Metriken, VictoriaLogs für Logs, OpenTelemetry für Tracing, wo sinnvoll. Selbst gehostet (souveränitätsfreundlich, im großen Maßstab mit weniger Overhead als Prometheus + Loki, kein Datenabfluss an einen SaaS-Anbieter).

Bei Organisationen, die bereits einen anderen Stack nutzen, arbeiten wir mit dem Vorhandenen, statt einen Austausch zu forcieren. Der Observability-Stack ist wichtig; die SRE-Disziplin ist wichtiger.

Arbeitsstrang 5 — Design der Funktion

Empfehlung für das eingebettete, zentrale oder hybride Modell passend zum Profil der Engineering-Organisation. Personalplanung. Einstellungsprioritäten. Berichtslinie. Schnittstelle zu Platform Engineering (sofern eigene Funktion) und zu den Produktteams.

Die Zuverlässigkeits-Defaults von Cozystack

Organisationen, die ein Ænix-Plattformprodukt betreiben, haben bei der SRE-Praxis einen Vorsprung, weil die Plattform mit SRE-tauglichen Voreinstellungen ausgeliefert wird:

• Integrierte Observability — VictoriaMetrics + VictoriaLogs sind vorinstalliert, mit Alert-Regeln für die Plattformkomponenten
• Deklarative Änderungshistorie — Tenants und Services sind Kubernetes-Ressourcen, verwaltet über GitOps; jede Änderung hat einen Commit, einen Autor und ein Review
• Backup- und Restore-Muster — Velero plus PITR pro Anwendung; RPO / RTO werden im Engagement pro Service dokumentiert

SLO-Definitionen und Werkzeuge für Fehlerinjektion (Chaos Engineering) sind keine Plattformfunktionen; sie werden im Engagement mit Ihnen entworfen.

So kann sich das SRE-Engagement auf die organisationsspezifische Arbeit konzentrieren (Design der Funktion, an Geschäftsprioritäten ausgerichtete SLOs, Governance), statt das technische Fundament neu aufzubauen.

Wann dieses Engagement passt

Gute Passung:

• Engineering-Organisation mit über 200 Engineers, in der Zuverlässigkeit zum Thema auf Vorstandsebene wird
• Ein Muster jüngster Incidents hat Zuverlässigkeitslücken offengelegt
• Regulatorisch getriebene RTO/RPO-Pflichten (DORA Artikel 11–12, NIS2 Artikel 21 Absatz 2 Buchstabe c)
• Bestehende Investitionen in Observability, aber keine klare SRE-Disziplin
• Eine Platform-Engineering-Funktion existiert oder wird aufgebaut (SRE ergänzt Platform Engineering ganz natürlich)

Bedingte Passung:

• Kleinere Organisationen (unter 100 Engineers) — meist eingebettetes SRE statt einer eigenen Funktion; das Ænix-Engagement kann schlanker ausfallen (Workshop plus Beratung statt eines mehrmonatigen Engagements)
• Organisationen mit reifem SRE in einem Geschäftsbereich, das ausgeweitet werden soll — der Umfang kann enger gefasst werden

Schlechte Passung:

• Reine Feuerwehr-Kultur ohne Rückendeckung der Engineering-Führung für den Wandel der Disziplin — ein SRE-Engagement ohne Unterstützung des Managements verkommt zu einem Incident-Response-Training; das ist hilfreich, aber nicht das, was wir anbieten

Weiterführende Inhalte

• SRE-Consulting-Leistungen — die kommerzielle Landingpage
• DevOps-Best-Practices für 2026 — die acht DevOps-Praktiken einschließlich SRE
• Platform Engineering vs DevOps vs SRE — Begriffe und Design der Funktion
• Cloud-Engineering-Disziplinen — die sieben Disziplinen, die sich gegenseitig verstärken

Anmerkung der Redaktion (September 2026): Diese Release-Ankündigung ist so erhalten, wie sie am 28. Mai 2026 veröffentlicht wurde. Cozystack ist seither weitergegangen — die aktuelle Release-Linie ist 1.6. Das neueste Patch-Release finden Sie in die Cozystack-Releases und die aktuelle Dokumentation. Die Dokumentationslinks unten verweisen bewusst auf die v1.4-Dokumentation, die das Release im Auslieferungszustand beschreibt.

Cozystack v1.4.0 ist verfügbar. Das Release wurde am 19. Mai 2026 veröffentlicht und bündelt alle Fixes aus der Patch-Reihe v1.3.1 bis v1.3.3.

Dieser Zyklus konzentriert sich auf den Betrieb von Cozystack als Produktivplattform: eine schnellere Dashboard-Architektur, langlebigere Worker für Tenant-Kubernetes, klarere Ressourcen-Dimensionierung, Backup-Abläufe für Managed Applications, bessere GPU-Auslastung, sichereres Veröffentlichen über Ingress und weniger Race Conditions bei Erstinstallation und Upgrade.

Die wichtigsten Neuerungen

Neues, schemagetriebenes Dashboard

Cozystack 1.4 liefert ein neu geschriebenes Dashboard aus dem Projekt cozystack/cozystack-ui aus. Der bisherige Stack aus openapi-ui plus BFF ist durch ein Frontend auf Basis von React 19 und TypeScript ersetzt, das direkt mit der Kubernetes-API spricht.

Die neue Architektur entfernt einen zusätzlichen Prozess und eine Proxy-Schicht, während das Dashboard schemagetrieben bleibt. Außerdem verbessert sie mehrere alltägliche Abläufe:

• Der VNC-Zugriff auf virtuelle Maschinen verwendet jetzt dynamische WebSocket-URLs statt deployment-spezifischer Annahmen über localhost.
• Das Dashboard kann ApplicationDefinition-Ressourcen für Anwendungskatalog und Marketplace auslesen.
• Betreiber können Branding zur Laufzeit über eine ConfigMap einspielen — Logos, Namen und Markenfarben —, ohne das Image neu zu bauen.
• Bestehende Lesezeichen auf /openapi-ui/* werden auf die neue Konsole umgeleitet.
• Das Paket heißt durchgängig cozy-dashboard.

Das neue Dashboard zeigt den IaaS-Marketplace, der von ApplicationDefinition-Ressourcen gespeist wird.

Der PaaS-Katalog umfasst Managed Databases, Messaging, Objektspeicher, Secrets, Suche und Inference-Dienste.

Das Ausrollen eines Managed-Kubernetes-Clusters läuft über dasselbe schemagetriebene Formular, wobei Cluster-Addons deklarativ zur Verfügung stehen.

Ein Managed-HTTP-Cache-Deployment, bei dem PVC-Größe, Storage-Klasse, Endpunkte und Ressourcenparameter vollständig aus dem Anwendungsschema erzeugt werden.

Dokumentation:

• Anwendungen über das neue Dashboard ausrollen
• ApplicationDefinition-Referenz
• White-Labeling und Branding zur Laufzeit

Persistenter Worker-Speicher für Tenant-Kubernetes

Die Worker-VMs von Tenant-Kubernetes nutzen jetzt PVC-gestützte persistente Disks über die KubeVirt-dataVolumeTemplates. Bisher lief der Worker auf flüchtigem emptyDisk-Speicher, wodurch Kubelet-Zertifikate, kubeconfig und der containerd-Zustand nach einem VM-Neustart verloren gingen. Ein neu gestarteter Worker konnte damit seine Identität verlieren und musste von Hand wiederhergestellt werden.

In v1.4 übersteht der Worker-Zustand VM-Neustarts. Das NodeGroup-Feld ephemeralStorage heißt jetzt diskSize, und eine neue Option storageClass je NodeGroup lässt Betreiber steuern, wo die Worker-Disks bereitgestellt werden. Migration 39 schreibt Altwerte beim Upgrade automatisch um.

Bestehende Tenant-Cluster rollen ihre Worker-Nodes einmalig neu aus, weil sich das KubeVirt-Machine-Template ändert. Betreiber sollten Kapazität für diesen Rollout einplanen und die Storage-Klasse bewusst wählen. Für viele Worker-Disk-Szenarien empfiehlt sich die StorageClass local, weil Worker-Disks Neustarts nun überstehen und keine DRBD-Replikationssemantik brauchen.

Dokumentation: Konfiguration von Tenant-Kubernetes.

Ressourcen-Presets als Instance Types

Ressourcen-Presets folgen jetzt einer Cloud-üblichen Systematik <series>.<size>. Das neue Modell deckt fünf Serien mit unterschiedlichem CPU-zu-Speicher-Verhältnis ab:

• t1 für sehr kleine und speicherarme Workloads.
• c1 für rechenlastig ausgewogene Workloads.
• s1 für Standarddienste wie Proxies und Caches.
• u1 für universelle Workloads wie Datenbanken und Messaging.
• m1 für speicherhungrige Workloads wie Suche und Analytik.

Jede Serie umfasst acht Größen von nano bis 4xlarge, womit Betreibern und Tenants insgesamt 40 Presets zur Verfügung stehen.

Die bisherigen flachen Namen wie small, medium und large werden weiterhin als veraltete Aliase akzeptiert. Bestehende Deployments behalten dieselben CPU- und Speicherwerte, während Migration 39 die gespeicherten Werte auf die neuen Namen umschreibt. Die Cozystack-API gibt jetzt Deprecation-Warnungen aus, wenn App-CRs noch die alten Preset-Namen verwenden.

Dokumentation: Ressourcen-Presets.

Deklarative Backup-Strategien für Managed Applications

Der Backup-Strategy-Controller unterstützt jetzt PostgreSQL, MariaDB, ClickHouse und FoundationDB. Tenants definieren eine Strategie zusammen mit den Ressourcen BackupClass, Plan, BackupJob und RestoreJob, während der Controller die backend-spezifischen Objekte für den jeweiligen Managed Service zusammensetzt.

Die neuen Strategien unterstützen geplante Backups, Ad-hoc-Snapshots, In-place-Restores und Restore-to-copy-Abläufe gegen S3-kompatiblen Objektspeicher. Zugangsdaten werden über Kubernetes-Secrets referenziert statt inline hinterlegt, und die RBAC des Controllers ist so eingeschränkt, dass er ausschließlich auf explizit referenzierte Secrets zugreifen kann.

Das erweitert die bestehenden Backup-Abläufe für VMInstance und VMDisk und bringt Cozystack der vollständigen Backup-Abdeckung über den gesamten Katalog der Managed Applications näher.

Dokumentation:

• Backup-Konfiguration für Managed Apps
• Backup und Wiederherstellung von Anwendungen

Anteiliges GPU-Sharing mit HAMi

Cozystack 1.4 ergänzt hami als optionales Systempaket. HAMi v2.8.1, ein CNCF-Sandbox-Projekt, ermöglicht anteiliges GPU-Sharing für Tenant-Kubernetes-Cluster.

Mit aktiviertem HAMi können Tenant-Workloads Ressourcen wie nvidia.com/gpu, nvidia.com/gpumem und nvidia.com/gpucores anfordern. Damit teilen sich mehrere Pods eine physische NVIDIA-GPU bei expliziter Aufteilung von Speicher und Rechenleistung. Die Integration umfasst Device-Plugin, Scheduler-Extender, Mutating Webhook und RuntimeClass. Sie wird über den Schalter hami.enabled zugeschaltet und setzt den NVIDIA GPU Operator voraus.

Ein Kompatibilitätshinweis ist dabei wichtig: Die Compute-Isolation von HAMi setzt Container-Images mit einer glibc älter als 2.34 voraus. Die Speicherbegrenzung funktioniert breit, Alpine- und musl-basierte Images werden für die HAMi-core-Compute-Isolation jedoch nicht unterstützt.

Dokumentation: GPU-Sharing mit HAMi.

Ein Schalter für PROXY-Protokoll und Hairpin-NAT

Die neue Option publishing.proxyProtocol: true aktiviert das PROXY-Protokoll am Host-ingress-nginx und rollt Ouroboros aus, um das damit verbundene Hairpin-NAT-Problem zu lösen.

Ist das PROXY-Protokoll aktiv, kann clusterinterner Verkehr an die eigenen öffentlichen Hostnamen des Clusters andernfalls ohne den erforderlichen PROXY-Header bei ingress-nginx ankommen. Ouroboros korrigiert diesen Pfad über CoreDNS-Rewrite-Snippets. Cozystack stellt es sowohl als Systempaket auf Host-Ebene als auch als Addon je Tenant über addons.ouroboros.enabled bereit.

Das Standardverhalten bleibt unverändert. Cluster, die das PROXY-Protokoll nicht aktivieren, erhalten keine neuen Ressourcen.

Dokumentation: PROXY-Protokoll und Hairpin-NAT.

Besseres HelmRelease-Verhalten und zuverlässigerer Tenant-Bootstrap

Der Cozystack-Operator stellt die Stellschrauben für die HelmRelease-Erzeugung jetzt als Operator-Flags und Chart-Werte bereit, darunter Interval, Retry-Interval, Install-Timeout, Upgrade-Timeout und Max History.

Die Retry-Strategie nutzt jetzt RetryOnFailure und vermeidet damit Deinstallations- und Neuinstallationsschleifen, wenn eine Erstinstallation langsam läuft. Anwendungen können zudem je Application ein eigenes Install- und Upgrade-Timeout über die Annotation release.cozystack.io/helm-install-timeout setzen. Tenant-Kubernetes nutzt das, um Kamaji beim Kaltstart genug Zeit zu geben, und behebt damit den wiederkehrenden Fehlerfall wait hr/tenant-kubernetes timeout.

Dokumentation:

• Betrieb von Tenant-Kubernetes
• Fehlersuche in Flux CD

Kubelet-Reservierungen für Worker-Nodes

Worker-Nodes in Tenant-Kubernetes erhalten jetzt automatisch berechnete Kubelet-Reservierungen für CPU und Arbeitsspeicher. Das schützt das Kubelet selbst davor, unter Speicherdruck abgeräumt zu werden, und macht die Entscheidungen von Scheduler und Autoscaler genauer.

Die Annotationen des Cluster-Autoscalers melden jetzt die zuteilbaren (allocatable) CPU- und Speicherwerte statt der Rohwerte, sodass Autoscaling-Entscheidungen dem entsprechen, was Kubernetes tatsächlich schedulen kann.

Dokumentation: Betrieb von Tenant-Kubernetes.

Außerdem in v1.4.0

• PostgreSQL-Parameter sind jetzt typisiert und durch eine Denylist gegen gefährliche Werte wie archive_command, restore_command, ssl_passphrase_command, dynamic_library_path und *_preload_libraries abgesichert.
• Keycloak erhält Unterstützung für extraEnv und die Anpassung des Nutzerprofils.
• Die etcd-Anwendung stellt über den aktualisierten etcd-operator S3-Backup-Zeitpläne bereit.
• Die upgradeCRDs-Policy ist jetzt je Paket konfigurierbar.
• cozyreport sammelt jetzt Flux, cert-manager, Host-Kontext, Anwendungsressourcen und eine übergeordnete summary.txt.
• Der SeaweedFS-Tenant-Ingress begrenzt einzelne PUT-Requests auf 5 GB.
• Für Grafana und VictoriaMetrics kamen GPU-Observability-Dashboards und Recording Rules hinzu.
• Die Portfilterung für VMInstance ist im neuen cozy-proxy-v0.3.0-Modus korrigiert.
• LINSTOR CSI ist aktualisiert, mit Fixes für Dual-Attach- und transiente Demotion-Fehler.

Dokumentation:

• PostgreSQL-Konfiguration
• Keycloak und OIDC
• Konfiguration des etcd-Dienstes
• Konfiguration des SeaweedFS-Dienstes
• Monitoring-Dashboards
• Fehlersuche und Diagnose

Plattformkomponenten

Cozystack 1.4 aktualisiert die Plattformbasis und mehrere Kernpakete:

• Talos: v1.12.7 auf v1.13.0
• cert-manager: v1.19.3 auf v1.20.2
• Cilium: v1.19.1 auf v1.19.3
• NVIDIA GPU Operator: v25.3.0 auf v26.3.1
• etcd-operator: v0.4.2 auf v0.4.3
• KubeVirt: v1.6.3 auf v1.8.2
• cozy-proxy: v0.2.0 auf v0.3.0
• linstor-csi: v1.10.6
• HAMi: v2.8.1
• Ouroboros: v0.7.2

Dokumentation:

• Überblick über den Plattform-Stack
• Upgrade-Leitfaden

Hinweise zum Upgrade

Die meisten Betreiber können ohne manuelle Konfigurationsänderungen auf v1.4.0 aktualisieren. Cozystack behält für bestehende Workloads dieselbe API-Oberfläche, und die plattforminternen Migrationen erledigen die wesentlichen Wertumschreibungen.

Einige betriebliche Details sollten Sie einplanen:

• Die Worker von Tenant-Kubernetes rollen einmalig durch. Die Migration von ephemeralStorage auf diskSize läuft automatisch, bestehende Worker-VMs werden aber nacheinander ersetzt, weil sich das KubeVirt-Machine-Template ändert.
• KubeVirt-VMs, die schon vor dem Plattform-Upgrade liefen, brauchen danach einen Kaltstart. Der KubeVirt-Sprung von v1.6.3 auf v1.8.2 überquert eine Upstream-Änderung an QEMU, und die Live-Migration von VMs aus der Zeit vor dem Upgrade kann fehlschlagen. Nach dem Upgrade angelegte VMs sind nicht betroffen.
• Die alten Preset-Namen funktionieren weiterhin als veraltete Aliase, neue Deployments sollten jedoch die Namen im Schema <series>.<size> verwenden.
• PostgreSQL-Deployments, die Parameter der Denylist verwenden, lassen sich nicht mehr rendern, solange diese Parameter nicht entfernt sind.
• cert-manager v1.20 ändert die Standard-UID/GID im Container auf 65532. Betreiber mit eigener PodSecurityPolicy, mit imagePullSecrets oder mit Zertifikaten, die über das Dateisystem eingebunden und auf die bisherige UID festgelegt sind, sollten ihre Konfiguration prüfen.

Dokumentation:

• Upgrade-Leitfaden
• Betrieb von Tenant-Kubernetes
• Betrieb der Virtualisierung
• Ressourcenverwaltung
• PostgreSQL-Konfiguration

Dokumentation, die Sie kennen sollten

• Neues Dashboard und Anwendungskatalog
• ApplicationDefinition-Referenz
• White-Labeling und Branding zur Laufzeit
• Konfiguration von Tenant-Kubernetes
• Ressourcen-Presets
• Backup-Konfiguration für Managed Apps
• Backup und Wiederherstellung von Anwendungen
• GPU-Sharing mit HAMi
• PROXY-Protokoll und Hairpin-NAT
• Upgrade-Leitfaden
• Cozystack-v1.4-Dokumentation

Dank an alle Mitwirkenden

Dieses Release ist geprägt von der Arbeit von @androndo, @Arsolitt, @dislogical, @dvc, @IvanHunters, @kvaps, @lexfrei, @matthieu-robin, @mattia-eleuteri, @myasnikovdaniil, @sircthulhu und @tym83.

Ein besonderes Willkommen an die erstmaligen Mitwirkenden @dvc und @dislogical. Vielen Dank an alle.

Release-Links

• Cozystack v1.4.0 auf GitHub
• Vollständiges Changelog v1.3.0 bis v1.4.0
• Cozystack UI
• HAMi
• Ouroboros

Community

• GitHub: cozystack/cozystack
• Telegram: @cozystack
• Slack: #cozystack im Kubernetes-Workspace (Einladung)
• Kalender der Community-Meetings abonnieren
• Meetings dem eigenen Kalender hinzufügen

Dieser Beitrag ist eine deutsche Fassung des Artikels Cozystack 1.4: New Dashboard UI, Persistent Tenant Workers, Backup Strategies, and Fractional GPU Sharing, zuerst erschienen bei Ænix auf Medium.

Die sieben Entscheidungen

1. Auslöserprofil

Was treibt Sie in Richtung Souveränität? (Regulierte Datenklasse / Wirtschaftlichkeit der Inference / Prüfbarkeit / Air-Gap-Anforderung)

2. Regulatorischer Rahmen

Welche Aufsicht bindet Sie? (DORA, NIS2, sektorale Vorgaben, Vorgabe einer souveränen Cloud, grenzüberschreitende Übermittlung nach DSGVO)

3. Modellauswahl

Open-Weight oder proprietär. Gängige Open-Weight-Modelle 2026: Llama, Mistral, Qwen, DeepSeek, Phi, Gemma. Die Wahl hängt ab von:

• Sprachanforderung (mehrsprachig oder Englisch)
• Workload-Typ (Chat / RAG / Code / Vision / Embedding)
• Lizenz (kommerzielle Nutzung, Namensnennung, Weitergabe)
• Angestrebter Leistungsfähigkeit

4. Hardware-Dimensionierung

• NVIDIA H100/H200 — das Arbeitspferd für Fine-Tuning und Inference mit hohem Durchsatz
• NVIDIA Blackwell — neuer, höchste Speicherbandbreite
• NVIDIA L40S — 48 GB, mandantenfähige Inference-Flotte
• NVIDIA A100 — kosteneffizient, Gebrauchtmarkt
• AMD MI300/MI325 — Alternative, wenn das Ökosystem passt

5. Mandantenmodell

• Single-Tenant: Labor / einzelnes Team / PoC
• Mandantenfähig über das Tenant CRD: Unternehmensplattform / kundenseitiges Angebot
• Ein Cluster je Tenant: höchste Isolation, im Betrieb teuer

6. Souveränitätskontrollen

• Kundenkontrollierte Verschlüsselungsschlüssel (HSM)
• Transparenz der Lieferkette bis zur zweiten Stufe
• Vollständige Audit-Trails in Formaten, die die Aufsicht auswerten kann
• Air-Gap-Option für die sensibelsten Workloads

7. Betriebsmodell

• Betrieb durch den Kunden (Sie betreiben die Plattform)
• Betrieb durch den Anbieter (Ænix oder ein vergleichbarer Anbieter betreibt sie)
• Hybrid (Sie betreiben; der Anbieter übernimmt den Second-Level-Support)

Wie die Entscheidungen ineinandergreifen

Die sieben Entscheidungen sind nicht unabhängig voneinander. Das Auslöserprofil prägt den regulatorischen Rahmen; der regulatorische Rahmen prägt die Souveränitätskontrollen; die Souveränitätskontrollen prägen das Betriebsmodell; das Betriebsmodell beeinflusst, welche Modellauswahl überhaupt machbar ist.

Häufige Kombinationen

Muster 1: Regulierte Finanzbranche + dauerhafte Inference + mandantenfähig DORA + Kontrollen nach Artikel 28 + mandantenfähiges Tenant CRD + Volume-Verschlüsselung mit einer Passphrase, die Sie verwalten + von Ænix verwalteter Betrieb + Open-Weight-Modell (Klasse Llama 70B) auf einer H100/L40S-Flotte.

Muster 2: Öffentlicher Sektor + Air-Gap + eingestufte Daten Vorgabe einer souveränen Cloud + Air-Gap + Betrieb durch den Kunden + Open-Weight-Modell (Llama / Phi) auf Hardware des Kunden.

Muster 3: AI-Startup + dauerhafte Inference rund um die Uhr + kundenseitiges Angebot Keine spezifische Aufsicht + Kostenwirtschaftlichkeit als Auslöser + mandantenfähig + Betrieb durch den Kunden + Open-Weight-Modell + GPU-Mix passend zum Workload.

So nutzen Sie den Entscheidungsleitfaden

Beantworten Sie die Fragen oben der Reihe nach und notieren Sie Ihre Antworten; die Architekturoptionen grenzen sich dabei von selbst ein. Der Sovereign-AI-Architektur-Leitfaden geht dieselben Entscheidungen ausführlicher durch.

Zur konkreten Zusammenarbeit siehe Sovereign AI.

Die Diskussion um souveräne Clouds im öffentlichen Sektor ist 2026 zersplitterter als bei Finanzdienstleistern. Es gibt keine einzelne Verordnung wie DORA, die für eine gemeinsame Richtung sorgt. Stattdessen hat jede Jurisdiktion ihr eigenes Regelwerk, oft aufgesetzt auf DSGVO, NIS2 und sektorale Zusatzanforderungen. Ein multinationales Projekt im öffentlichen Sektor — oder schon ein nationales, das mehrere Regionen umfasst — muss in der Regel drei oder mehr Regelwerke gleichzeitig abdecken.

Die Landschaft der Regelwerke

EU-Ebene

• EUCS (EU Cybersecurity Certification Scheme for Cloud Services) — vorgeschlagenes EU-weites Schema (Annahme ausstehend). Drei Vertrauensniveaus (Basic, Substantial, High). Das Niveau High verlangt inhaltliche Souveränitätskontrollen.
• NIS2 — die öffentliche Verwaltung ist ein Sektor nach Anhang I; Einrichtungen der Zentralregierung sind wesentliche Einrichtungen (Artikel 3). Pflichten aus Artikel 21 und Artikel 23.
• DSGVO — Grundlage für personenbezogene Daten, Regeln für grenzüberschreitende Übermittlungen in den Artikeln 44-50.

Ebene der Mitgliedstaaten

• Frankreich: SecNumCloud — strenges französisches nationales Regelwerk. Das anspruchsvollste Souveränitätsschema eines EU-Mitgliedstaats. Referenzstandard für mehrere andere nationale Initiativen.
• Deutschland: BSI C5 — der deutsche Kriterienkatalog für Cloud-Sicherheit. Inzwischen auch über Deutschland hinaus für den Betrieb in der DACH-Region breit referenziert.
• Italien: ACN — Regelwerke der Nationalen Agentur für Cybersicherheit; Infrastrukturregeln des Polo Strategico Nazionale.
• Spanien: ENS High — höchste Stufe des Esquema Nacional de Seguridad.

Andere Mitgliedstaaten haben eigene Varianten.

Zentralasien und APAC

• Kasachstan — per Vergaberecht vorgeschriebene Souveränität für Workloads des öffentlichen Sektors über goszakup.gov.kz / mitwork.kz / zakup.sk.kz.
• Singapur: IM8 — IT-Sicherheitsstandards der Regierung.
• Indien: MeitY — Ministry of Electronics IT, einschließlich des STQC-Rahmens für gelistete Cloud-Anbieter (Empanelled CSP).
• Australien: IRAP — Information Security Registered Assessors Program; Stufen Protected / Secret für Workloads der Regierung.

Sektorale Zusatzanforderungen

• Eingestufte Workloads (in den meisten Jurisdiktionen): zusätzliche nationale Geheimschutzeinstufung
• Gesundheitswesen: nationale Regeln zur Souveränität von Gesundheitsdaten
• Kritische Infrastruktur: sektorale Cybersicherheitsanforderungen

Was „inhaltlich souverän“ bedeutet

Ein „souveränes“ Cloud-Produkt, das nicht alle folgenden Punkte inhaltlich erfüllt, fällt in einem Audit auf dem höchsten Vertrauensniveau der meisten Regelwerke durch:

1. Datenresidenz auf jeder Schicht

Nicht nur beim produktiven Storage. Backups, Observability, CI/CD-Artefakte, Telemetrie der Managed Services, grenzüberschreitende Replikation, Verarbeitung durch Unterauftragnehmer — jede Schicht muss die Residenzanforderung einhalten.

2. Kundenkontrollierte Verschlüsselungsschlüssel

HSM-gestützt für sensible Datenklassen. Dokumentierte Rotation. Verfahren für den Notfallzugriff. Personal des Anbieters kann Schlüssel unter keinen Umständen auslesen oder kopieren. An genau dieser Stelle scheitern „souveräne“ Angebote von Hyperscalern am häufigsten: Der Anbieter behält operativen Zugriff auf die Schlüssel und verfehlt damit die inhaltliche Bedingung.

3. Open-Source-Fundament der Plattform

Für Transparenz, Ausstiegsfähigkeit und Prüfbarkeit. Closed-Source-Plattformen, die an die Roadmap eines einzelnen Herstellers gebunden sind, verfehlen die inhaltlichen Anforderungen mehrerer Regelwerke (selbst wenn sie die formalen Prüfungen der Vergaberichtlinien bestehen).

4. Transparenz der Lieferkette

Die Lieferketten-Bestimmungen der Regelwerke (DORA Art. 28, NIS2 Art. 21 Abs. 2 lit. d, nationale Schemata) erwarten eine Dokumentation der Lieferkette mindestens bis zur zweiten Stufe. Die meisten souveränen Cloud-Konstrukte auf Hyperscaler-Basis enden bei der ersten Stufe (dem Hyperscaler selbst).

5. Option für Air-Gap-Deployments

Für die sensibelsten Workloads — eingestufte Daten, Gesundheitswesen mit strikter Residenz. Updates gelangen über kontrollierte Kanäle in die Umgebung (Artefakt-Registry auf Kundenseite, manuelle Freigabe). Die meisten Souveränitätsregelwerke verlangen auf dem höchsten Niveau Air-Gap-Unterstützung als architektonische Option, auch wenn sie nicht jeder Workload nutzt.

6. Vollständige Audit-Trails in Standardformaten

Logs in Standardformaten (Syslog, CEF, OpenTelemetry), die das Audit-Team des Kunden unabhängig vom Plattformhersteller auswerten kann. Manipulationssicher. Aufbewahrung gemäß der längsten anwendbaren regulatorischen Anforderung.

7. Keine Telemetrie, die nach Hause telefoniert

Telemetrie, die den Perimeter des Kunden verlässt, muss Opt-in sein und ausdrücklich dokumentiert werden. Viele von Hyperscalern verwaltete Cloud-Produkte haben nicht abschaltbare Telemetriekanäle und verfehlen dieses Kriterium.

8. Betriebliche Unabhängigkeit unter souveräner Jurisdiktion

Zugriffe von Personal des Anbieters werden protokolliert und sind zeitlich begrenzt. Die Supportgesellschaft unterliegt souveräner Jurisdiktion (Ænix hat die AENIX s.r.o. in Tschechien für Verträge in der EU und die AENIX INC in Delaware für Verträge in den USA). Kein jurisdiktionsübergreifendes Support-Routing für souveränitätskritische Workloads.

Was eine Cozystack-basierte Architektur über alle Regelwerke hinweg liefert

Das Architekturmuster, das alle wichtigen Regelwerke gleichzeitig erfüllt:

• Open-Source-Plattform — Cozystack unter Apache 2.0, CNCF-Projekt, herstellerneutrales Fundament. Der Kunde kann die Plattform prüfen, verändern oder den Plattformanbieter austauschen.
• Schlüssel beim Kunden — die Volume-Verschlüsselung ist pro Storage-Klasse wählbar (Opt-in), die Schlüsselverwaltung entwerfen wir mit Ihnen; Ænix hält niemals Schlüssel.
• Air-Gap-Unterstützung — dokumentierter Installationsablauf ohne Internetverbindung für Anwendungsfälle mit eingestuften Daten.
• Selbst betriebene Observability — VictoriaMetrics und VictoriaLogs innerhalb der Jurisdiktion; kein Residenzleck durch SaaS-Observability.
• Kundenkontrollierte Identity — Integration mit Keycloak / Active Directory / nationalem IdP; Ænix hält niemals produktive Zugangsdaten.
• Mandantenfähiges Tenant CRD — starke Isolation je Datenklasse, Geschäftsbereich oder sektoraler Zusatzanforderung.
• Audit-isolierte Umgebungen — getrennte Cluster für Produktion, Audit und forensische Kopie.
• Supportgesellschaft unter EU-Jurisdiktion — AENIX s.r.o. (Tschechien).

Das Architekturmuster ist dasselbe; die Zertifizierungsarbeit ist je Regelwerk spezifisch. Bei Projekten auf SecNumCloud-Niveau beauftragt der Kunde in der Regel einen zertifizierten Auditor; Ænix liefert Architektur und Dokumentation, der Kunde führt den Auditzyklus durch.

Realitäten der Vergabe

Projekte im öffentlichen Sektor werden von Vergaberahmen bestimmt, wie es in der Privatwirtschaft nicht der Fall ist. Einige praktische Realitäten:

Angebot auf eine Ausschreibung

Ausschreibungen im öffentlichen Sektor legen in der Regel fest, welche Regelwerke erfüllt sein müssen (SecNumCloud High, BSI C5, EUCS Substantial usw.). Das Angebot muss die inhaltliche Erfüllung belegen, nicht nur die Absicht. Das Modell der Zusammenarbeit mit Ænix umfasst Unterstützung bei der Angebotserstellung; Referenzen können unter NDA geteilt werden, soweit der Kunde zustimmt.

Mehrjährige Rahmenverträge

Viele Projekte im öffentlichen Sektor laufen über Rahmenverträge mit spezifischen Compliance- und Ausstiegsklauseln. Vertragspartner ist die jeweilige Gesellschaft von Ænix (AENIX s.r.o. in Tschechien für die EU; AENIX INC in Delaware für die USA); die Struktur der Zusammenarbeit passt sich den Anforderungen des Rahmenvertrags an.

Ænix ist kein Hyperscaler — genau darum geht es

Mehrere Vorgaben im öffentlichen Sektor verlangen ausdrücklich eine souveräne Bereitstellung ohne Hyperscaler. Das Open-Core-Modell von Ænix — Hardware des Kunden, Schlüssel beim Kunden, wo Verschlüsselung aktiviert ist, betriebliche Kontrolle beim Kunden, optionaler Support durch Ænix — erfüllt diese Vorgaben strukturell statt über vertragliche Hilfskonstruktionen.

Projektphasen im öffentlichen Sektor

Phase 0 — Klärung der Regelwerke

Die anwendbaren Regelwerke bestätigen. Das mit der höchsten Messlatte identifizieren (meist SecNumCloud High in Frankreich, BSI C5 in Deutschland, EUCS High, wo EU-weite Anforderungen gelten, nationale Vergaberegeln andernorts). Die Architektur gegen die höchste Messlatte entwerfen und auf die übrigen abbilden.

Phase 1 — Architektur und Angebotserstellung

Die Unterlagen für das Vergabeverfahren erstellen: technisches Angebot, Abbildung auf die Compliance-Anforderungen der Regelwerke, Referenzarchitektur, beispielhafter Nachweiskatalog. Typische Dauer: 2-4 Monate.

Phase 2 — Aufbau der Plattform in Phase 1 (nach den Modellen Public Cloud Platform / Private Cloud Platform)

Deployment über mehrere Rechenzentren, Air-Gap-Option bei Bedarf aktiviert, Integration einer souveränen Identity, audit-isolierte Umgebungen. Ein nationales Programm mit mehreren Regionen läuft mit 3–6 Monaten Pilot und danach 9–18 Monaten bis zum vollen Multi-Region-Betrieb; eine Private Cloud für eine einzelne Behörde ist ein Aufbau von 3–12 Monaten nach einem Assessment von 14 oder 28 Tagen.

Phase 3 — Zertifizierungszyklus

Der Kunde beauftragt einen akkreditierten Auditor; Ænix liefert Architekturdokumentation, Control Mapping und Nachweiskatalog. Engineers von Ænix nehmen, soweit zulässig, an den technischen Gesprächen mit dem Auditor teil. Typischer Zertifizierungszyklus: 6-12 Monate parallel zu Phase 2.

Phase 4 — Produktionsbetrieb

Das Team des Kunden betreibt die Plattform mit Beratung durch Ænix und einer Plus- oder Enterprise-Support-Stufe (siehe Preise). Jährlicher Rezertifizierungszyklus (bei den meisten Regelwerken).

Die zertifizierte Produktion kommt wegen des Zertifizierungszyklus später als in der Privatwirtschaft — doch der Wert der Zertifizierung wächst mit: Ist die Plattform einmal zertifiziert, behält sie die Zertifizierung durch die jährliche Rezertifizierung, statt sie für jedes Projekt neu zu erwerben.

Die bestehende Position von Ænix im öffentlichen Sektor

Ænix schließt Verträge über die AENIX s.r.o. (EU) und die AENIX INC (USA) und arbeitet innerhalb der Vergaberahmen des öffentlichen Sektors. Konkrete Projekte sind vertraulich; Referenzen nennen wir unter NDA im Discovery Call.

Wann dieses Modell der Zusammenarbeit passt

Gute Passung:

• Nationale Initiativen für souveräne Clouds (öffentlich, als öffentlich-private Partnerschaft, Betreiber einer souveränen Cloud)
• Regionale oder sektorale Cloud-Programme von EU-Mitgliedstaaten
• Hosting eingestufter Daten mit Air-Gap-Anforderung
• Souveräne Cloud im Gesundheitswesen auf nationaler oder regionaler Ebene
• Bildungs- und Forschungskonsortien mit einem Planungshorizont über mehrere Jahrzehnte

Bedingte Passung:

• Vergaben einzelner Ministerien oder Behörden mit kleinerem Umfang — hier passt womöglich eher die Private Cloud Platform als die Public Cloud Platform

Schlechte Passung:

• Workloads, bei denen eine von Hyperscalern verwaltete Cloud die Regelwerke bereits erfüllt (bei einigen spezifischen Vergaberahmen)
• Organisationen ohne Souveränitätsdruck (nutzen Sie das Produkt für die Privatwirtschaft, das zum Workload-Profil passt)

Wo Sie tiefer einsteigen können

• Branchenseite Öffentlicher Sektor — die kommerzielle Landingpage
• Data Sovereignty — Landingpage zum Kaufanlass Souveränität
• NIS2-Compliance — für die NIS2-Anforderungen (die öffentliche Verwaltung fällt unter Anhang I)
• Sovereign Cloud Builder — die passende Form der Zusammenarbeit
• Souveräne Cloud aufbauen — Playbook für die EU und Zentralasien — Playbook für souveräne Clouds in der EU und in Zentralasien
• Datenresidenz-Anforderungen 2026 — Datenresidenz Schicht für Schicht

Die meisten Hosting-Anbieter betreiben die Ænix Public Cloud Platform im Providermaßstab: Der produktisierte Installer bringt die Plattform wenige Wochen nach Bereitstellung der Hardware live, die Preise folgen den veröffentlichten Support-Stufen. In diesem Beitrag geht es um das andere Ende — das Programm im Betreibermaßstab. Dort lautet die Frage nicht „Sollen wir Cozystack einsetzen?“ — das ist bereits entschieden. Sie lautet: „Wir bringen ein Cloud-Produkt im nationalen Maßstab oder für Tier-1-Kunden auf den Markt; wie sieht die Partnerschaft mit Ænix über 3–6 Monate Pilot und die 9–18 Monate bis zum vollen Multi-Region-Betrieb aus?“

Wer die Public Cloud Platform im Betreibermaßstab einsetzt

Fünf Käuferprofile prägen die Projekte im Betreibermaßstab:

1. Tier-1-Telcos / nationale Betreiber — etablierte Telekommunikationsanbieter, die eine Public Cloud als Teil ihres Produktportfolios starten oder ausbauen. Häufig verbunden mit einer Souveränitätspositionierung („unsere souveräne Cloud“, „nationale Cloud“).
2. Große Banken mit eigener Cloud — die Bank nutzt ihr eigenes Cloud-Produkt für interne Workloads und verkauft mitunter auch Kapazität an ihren Kundenstamm.
3. Initiativen für souveräne Clouds — staatlich beauftragte Cloud-Produkte, teils als öffentlich-private Partnerschaft aufgesetzt, mit ausdrücklichen Souveränitätsanforderungen und Abstimmung mit der Aufsicht.
4. Hosting-Anbieter im großen Maßstab — Anbieter mit mehr als rund 5.000 Kunden, bei denen das Betriebsmodell der Public Cloud Platform auf mehrere Regionen mit Active/Active über mehrere Rechenzentren skaliert werden muss.
5. Nationale AI/GPU-Betreiber — dauerhafte Inference- und Trainingskapazität für Kunden aus bestimmten Sektoren (Banken, Gesundheitswesen, öffentlicher Sektor), in denen AI-Souveränität eine Anforderung auf nationaler Ebene ist.

Alle fünf teilen dieselbe betriebliche Realität: Active/Active über mehrere Regionen oder Rechenzentren; Infrastrukturinvestitionen im Millionen-Euro-Bereich; kundenseitige SLAs, die sich an den Erwartungen der nationalen Aufsicht orientieren; und eine Partnerschaft mit Ænix, die Jahre dauert, nicht Monate.

Was ein Aufbau im Betreibermaßstab zusätzlich umfasst

Active/Active über mehrere Regionen und Rechenzentren

Deployments in einem einzigen Rechenzentrum bedient die Public Cloud Platform im Providermaßstab (oder die Private Cloud Platform für den internen Einsatz). Ein Aufbau im Betreibermaßstab geht vom ersten Tag an davon aus, dass der Kunde Active/Active über Regionen oder Rechenzentren hinweg braucht, mit einer rechenzentrumsübergreifenden Replikation, die auf die RTO/RPO-Ziele abgestimmt ist. Control Plane, Observability, Identity und Storage-Schicht der Plattform sind von Grund auf für mehrere Regionen ausgelegt, statt nachträglich umgerüstet zu werden.

Tiefe des Servicekatalogs

Ein Aufbau im Providermaßstab stellt rund 20 Managed Services bereit. Ein Aufbau im Betreibermaßstab zielt typischerweise auf 30-50+ Services aus Compute, Storage, Networking, Managed Databases, Observability, AI/GPU, Message Queues, Suche, Content Delivery und Security-Tooling. Die Paketarchitektur von Cozystack (die Ressourcen Package, PackageSource und ApplicationDefinition, Stand v1.x) trägt diesen Ausbau des Katalogs.

Betriebsteam im großen Maßstab

10-30+ Engineers betreiben die Plattform, je nach Kundenzahl und SLA. Zur Zusammenarbeit im Betreibermaßstab gehören Rekrutierung und Schulung des Betriebsteams als eigener, umfangreicher Arbeitsstrang — nicht nach dem Muster „Sie finden die Leute, wir schulen sie“, sondern: „Wir entwerfen die Organisationsstruktur gemeinsam mit Ihnen, sitzen in den Interviews mit, schulen praktisch und leisten in den ersten 12-18 Monaten Eskalations-Support (Plus- oder Enterprise-Stufe), während Ihr Team Sicherheit gewinnt.“

Abstimmung mit Aufsicht und Souveränitätsvorgaben

Welches Souveränitätsregelwerk im Markt des Kunden auch gilt — SecNumCloud, BSI C5, EUCS, sektorale Zusatzanforderungen, nationale Vergabevorgaben —, die Architektur wird so entworfen, dass sie es inhaltlich erfüllt und nicht nur vertraglich. Ein Katalog der Compliance-Nachweise ist Teil der Lieferung.

Brand Engineering für die Kundenseite

Über die Anpassung des Cozystack Dashboards hinaus umfasst eine Zusammenarbeit im Betreibermaßstab echte Markenarbeit: ein Kundenportal, das wie ein erstklassiges Cloud-Produkt wirkt und nicht wie eine angepasste Cozystack-Instanz. UX-Abläufe, die darauf abgestimmt sind, wie die Kunden des Kunden über Bestellen, Konfigurieren und Bezahlen denken. Von Designern geführt, nicht vom Engineering.

Wie eine Zusammenarbeit im Betreibermaßstab in Phasen verläuft

Die Phasen 0 und 1 bilden den Pilot und dauern zusammen 3–6 Monate. Die Phasen 2–4 dauern 9–18 Monate bis zum vollen Multi-Region-Betrieb und überlappen, soweit die Teams es erlauben.

Phase 0 — Discovery und Aufbau der Partnerschaft (Beginn des Pilots)

Vor dem Engineering steht die Einigung über:

• Strategische Ziele (welches Cloud-Produkt, welcher Kundenstamm, welche Wettbewerbspositionierung)
• Regulatorischen Rahmen (welche Regelwerke die Plattform binden)
• Organisationsstruktur (wer verantwortet was; wie die Teams von Ænix und Kunde zusammenarbeiten)
• Kommerzielle Struktur (Modell der Zusammenarbeit, IP, Supportmodell nach dem Go-live)
• Roadmap (Reihenfolge der Services, geografische Expansion, SLA-Stufen)

Ergebnis: ein unterzeichneter Plan für die Zusammenarbeit mit benannten Verantwortlichen für jeden Arbeitsstrang auf beiden Seiten.

Phase 1 — Fundament (restlicher Pilot)

Beschaffung und Einbau der Hardware. Deployment der Talos/Cozystack-Plattform im ersten Rechenzentrum. Storage-Schicht (LINSTOR/DRBD im großen Maßstab). Netzwerkfundament. Integration mit der bestehenden Mitarbeiter-Identity des Kunden (Keycloak / Okta / Active Directory / souveräner IdP). Erster Observability-Stack.

Endzustand: funktionierende Plattform, eine Region, nur interner Zugriff. Noch nicht bereit für Kunden.

Phase 2 — Fundament für mehrere Regionen

Das zweite Rechenzentrum wird aufgebaut. Die rechenzentrumsübergreifende Replikation wird validiert. Föderierte Identity. Storage-Replikation über Regionen hinweg (LINSTOR asynchron oder Ceph regionsübergreifend). Disaster-Recovery-Muster werden getestet. Das Fundament der Compliance-Dokumentation entsteht.

Endzustand: Plattform über mehrere Rechenzentren, interner Zugriff, RTO/RPO gegen die Zielwerte validiert.

Phase 3 — Ausbau des Servicekatalogs

Rollout Service für Service. Zuerst die grundlegenden Services (Compute, Storage, Basis-Networking, Managed PostgreSQL). Danach kommen die Familien der Managed Services hinzu (Datenbanken, Queues, Caches, Suche, Observability). Schließlich produktspezifische Services (GPU, AI-Inference, sektorspezifisches Compliance-Tooling).

Jeder Service durchläuft: Deployment → interne Tests → Pilot mit befreundeten Kunden → Produktions-GA. Rollout in Kohorten, kein Big Bang.

Phase 4 — Kunden-Onboarding und eingeschränkte GA

Das Kundenportal geht live (mit Brand Engineering). Die Billing-Integration ist durchgängig validiert. Support-Runbooks sind dokumentiert. Die ersten 10-50 befreundeten Kunden sind an Bord. Das SLA-Monitoring läuft im Regelbetrieb.

Endzustand: Das Cloud-Produkt ist mit der ersten Kundenkohorte live, Billing- und Support-Abläufe haben sich bewährt.

Phase 5 — General Availability und Skalierung (fortlaufend)

Start am offenen Markt. Marketing und Vertrieb legen los. Das Betriebsteam wächst mit den Kunden. Der Eskalations-Support von Ænix (Plus- oder Enterprise-Stufe) läuft weiter, bis das Team des Kunden ihn selbst übernehmen kann (typischerweise 12-24 Monate nach GA).

Alle weiteren Phasen folgen der Roadmap: neue Services, neue Regionen, neue sektorspezifische SKUs.

Woran Cloud-Projekte im Millionen-Euro-Bereich scheitern

Drei Fehlermuster, die wir in der Branche beobachtet haben:

1. Zu wenig Investition in Brand Engineering

Eine vom Engineering getriebene Plattform mit einer UX auf Engineering-Niveau. Kunden klicken sich durch, finden sie funktional, aber wenig ansprechend, und melden sich stattdessen beim Hyperscaler an. Eine Zusammenarbeit im Betreibermaßstab enthält ausdrücklich eine Designpartnerschaft, um genau das zu vermeiden.

2. Betriebsteam für den Go-live dimensioniert, nicht für das Volumen in 18 Monaten

Cloud-Produkte wachsen im ersten Jahr nach GA exponentiell, wenn die Positionierung stimmt. Betriebsteams, die auf die Kundenzahl zum Go-live ausgelegt sind, werden in Monat 6-12 überrollt. Planen Sie die Betriebskapazität für das Volumen in 18 Monaten und stellen Sie vorausschauend ein.

3. Dialog mit der Aufsicht aufgeschoben

Eine Souveränitätspositionierung hängt von der Zustimmung der Aufsicht ab (ausdrücklich oder stillschweigend). Projekte, die das Gespräch mit der Aufsicht bis in eine späte Phase verschieben, bauen schließlich ihre Architektur um, um Erwartungen zu erfüllen, die sie von Anfang an hätten einplanen können. Binden Sie die Aufsicht in Phase 0-1 ein, nicht in Phase 4.

Wann ein Programm im Betreibermaßstab die richtige Antwort ist

Gute Passung:

• Tier-1-Telco / nationaler Betreiber / große Bank / Initiative für eine souveräne Cloud
• Betriebliche Realität mit mehreren Regionen oder Rechenzentren
• 5.000+ angestrebte Kunden oder ein strategischer Kundenstamm
• Budgetrahmen im Millionen-Euro-Bereich über ein mehrjähriges Programm
• Souveränität und Positionierung gegenüber der Aufsicht sind Kern des Nutzenversprechens
• Sponsoring auf oberster Führungsebene (mindestens CIO oder CTO)

Bedingte Passung:

• Große Hosting-Anbieter unterhalb des Maßstabs eines Tier-1-Telcos — je nach Wachstumsprofil passt die Public Cloud Platform im Providermaßstab, Region für Region erweitert, oft besser als ein vollständiges Betreiberprogramm
• Auf AI/GPU fokussierte Betreiber, bei denen der AI-Workload dominiert — hier passt die Ænix AI Platform womöglich besser, ergänzt um ausgewählte Komponenten der Public Cloud Platform

Schlechte Passung:

• Kleinere Hosting-Anbieter — die Public Cloud Platform im Providermaßstab (zu den veröffentlichten Preisen) passt bei Wirtschaftlichkeit und Betriebsmodell deutlich besser
• Regulierte Unternehmen, die Cloud konsumieren statt sie anzubieten — hier ist die Private Cloud Platform die richtige Antwort

Struktur der Zusammenarbeit

• Discovery Call (Führungsebene, 60-90 Min.) — Einschätzung der strategischen Passung
• Platform Readiness Assessment (Festpreis, 28 Tage vollständig) — Grundlage für den Aufbau der Partnerschaft; Ergebnis ist ein unterzeichneter Plan
• Pilot (Phasen 0–1, 3–6 Monate), danach Phasen 2–4 (9–18 Monate bis zum vollen Multi-Region-Betrieb)
• Support-Subskription (fortlaufend) — Plus- oder Enterprise-Stufe (siehe Preise), bis das Team des Kunden die Eskalation übernehmen kann

Umfang der Zusammenarbeit: mehrjähriges Programm, kalkuliert je Ausschreibung.

Wo Sie tiefer einsteigen können

• Public Cloud Platform — Funktionsübersicht, produktspezifische FAQ
• Public Cloud Builder — Details zur Zusammenarbeit
• Sovereign Cloud Builder — für die Variante mit Schwerpunkt Souveränität
• Souveräne Cloud aufbauen — Playbook für die EU und Zentralasien — Architekturmuster für souveräne Clouds

Proxmox VE ist eine der erfolgreichsten Open-Source-Virtualisierungsplattformen des letzten Jahrzehnts: ausgereift, einfach zu installieren, mit starker Community, unter AGPLv3 und mit kommerzieller Subscription. Wir sprechen mit vielen Betreibern, die mit Proxmox angefangen haben, gewachsen sind und nun prüfen, was als Nächstes kommt.

Entscheidend ist: Für viele von ihnen ist Proxmox die richtige Antwort. Dieser Artikel zeigt, wann eine Migration gerechtfertigt ist und wann sie verfrüht wäre.

Wo Proxmox weiterhin gewinnt

Proxmox VE bleibt die richtige Antwort für:

• IT-Abteilungen im Mittelstand — kleine und mittlere Unternehmen mit 10–50 virtualisierten Workloads im eigenen Haus, ohne Bedarf an kundenseitiger Mandantenfähigkeit
• Single-Tenant-Labs und Entwicklungsumgebungen — die betriebliche Einfachheit von Proxmox schlägt jede schwergewichtigere Alternative
• Etablierte Betreiber mit stabilem Kundenstamm unter rund 200 Kunden — die kommerzielle Rechnung von Proxmox geht weiterhin auf; die Migrationskosten würden den Nutzen übersteigen
• Überwiegend VM-basierte Workloads — der Funktionsumfang von Proxmox mit KVM und LXC passt sauber
• Bestehende Betreiber mit tiefer Proxmox-Expertise und stabilem Team — zu den Wechselkosten gehört auch die Umschulung des Teams

Wenn Ihre Situation darauf zutrifft: Migrieren Sie nicht. Die Ænix Public Cloud Platform ist für den Single-Tenant-Betrieb im Mittelstand überdimensioniert. Das sagen wir bereits im Discovery Call, statt das Engagement zu forcieren.

Woran man erkennt, dass Proxmox zu klein wird

Eine Migration verdient eine ernsthafte Prüfung, wenn mindestens drei der folgenden Punkte zutreffen:

1. Die Kundenzahl wächst über rund 300

Das Mandantenmodell von Proxmox (Pools, Realms und Berechtigungen, keine harte Isolation) wirkt ab etwa 300 kundenseitigen Tenants zu dünn. Audit-Trails pro Kunde, Isolationsgarantien und die Durchsetzung von Quotas werden zur betrieblichen Belastung.

2. Kunden fragen nach Diensten jenseits von VMs

Managed PostgreSQL, MariaDB, MongoDB, Redis, Valkey, Kafka, S3-kompatibler Object Storage, Tenant-Kubernetes-Cluster, GPU-Dienste. Proxmox deckt VMs und LXC ab; alles andere wird über manuelle Integration oder externe Systeme angeflanscht.

3. WHMCS oder eine vergleichbare Kundenverwaltung

Proxmox hat eine WHMCS-Integration, doch der Servicekatalog jenseits von VMs bedeutet manuelle Integrationsarbeit. Die Ænix Public Cloud Platform ergänzt eine WHMCS-Integration (ein proprietäres Ænix-Modul, nicht Teil des Open-Source-Projekts Cozystack), die den gesamten Servicekatalog abdeckt.

4. Active/Active über mehrere Rechenzentren

Proxmox-Clustering ist auf ein Rechenzentrum beschränkt. Geografische Verteilung erfordert manuelle Replikationsmuster zwischen Clustern. Cozystack behandelt Active/Active über mehrere Rechenzentren als vollwertigen Deployment-Modus.

5. Nachfrage nach containernativen Diensten

Kunden wollen Tenant-Kubernetes-Cluster oder containernative Servicekataloge. Proxmox kann Container über LXC betreiben, ist aber nicht das richtige Betriebsmodell für kundenseitiges Kubernetes-as-a-Service.

6. Wiederkehrender Lizenz- und Subscription-Druck bei kommerziellem Proxmox

Die kommerzielle Subscription von Proxmox ist wettbewerbsfähig, aber ein realer Kostenfaktor. Betreiber mit wachsendem Infrastruktur-Footprint stellen mitunter fest, dass sich die gesamten Subscription-Kosten dem nähern, was Ænix für den Support der Public Cloud Platform berechnet — und an diesem Punkt geben Servicekatalog und betriebliche Vorteile von Cozystack den Ausschlag.

Architekturabbildung: Proxmox → Cozystack

Zwei Bereiche erfordern ein Redesign statt einer 1:1-Abbildung:

• LXC vs. Kubernetes-Container — Proxmox-LXC ist ein System-Container (vollständiges OS-Image), ein Kubernetes-Container ist ein Anwendungscontainer (ein einzelner Prozess oder wenige). Workloads, die LXC im Sinne von System-Containern nutzen, wandern entweder in KubeVirt-VMs oder werden umgebaut.
• Mandantenmodell — das Tenant-Modell von Proxmox (Pools, Realms und Berechtigungen) gegenüber dem Tenant CRD von Cozystack (Kubernetes-nativ). Die kundenseitige Isolation ist in Cozystack stärker; die betriebliche Abstraktion ist eine andere.

Migrationsphasen

Phase 0 — Assessment (14 oder 28 Tage)

Bestandsaufnahme: Kundenzahl, genutzte kundenseitige Dienste, Anzahl der VMs, Betriebssystem-Mix, LXC-Nutzung, Storage-Klassen, Netzwerktopologie, Backup-Muster, Integration von WHMCS bzw. der Kundenverwaltung.

Ehrlicher TCO-Vergleich: das heutige Proxmox mit kommerzieller Subscription und Betriebsteam gegenüber der Ænix Public Cloud Platform mit Hardwareerneuerung und Ænix-Support-Stufe. Bei Betreibern unter rund 300 Kunden bleibt Proxmox dabei oft wettbewerbsfähig; oberhalb von etwa 500 gewinnt Cozystack in der Regel durch Servicekatalog und betriebliche Tiefe.

Ergebnis: eine Go/No-Go-Entscheidung mit quantifizierter Begründung.

Phase 1 — Cozystack-Fundament (wenige Wochen)

Mit dem produktisierten Installer ist die Plattform wenige Wochen nach Bereitstellung der Hardware live; Katalog- und Markenarbeit füllen den Rest der Phase. Die Cozystack-Plattform wird auf neuer Hardware oder auf umgewidmeter Proxmox-Hardware bereitgestellt (handelsübliche x86-Server lassen sich leicht umziehen). Das Cilium-Networking wird konfiguriert, LINSTOR-Storage in den Betrieb überführt, die Identitätsintegration eingerichtet (typischerweise Keycloak plus IdP des Kunden). Das Cozystack Dashboard wird an die bestehende Marke des Betreibers angepasst.

Die WHMCS-Integration wird Ende-zu-Ende validiert. Der Servicekatalog wird mit den vom Betreiber gewählten Diensten befüllt (zuerst VMs, danach Managed Databases, dann S3, und von dort aus weiter).

Phase 2 — Migration der Pilotkunden

5–20 wohlgesonnene Kunden werden als erste Kohorte zu Cozystack migriert. Ablauf pro Kunde:

1. Kunden-VMs werden vom Proxmox-Format qcow2 in ein KubeVirt-kompatibles Format konvertiert
2. Die Netzwerkkonfiguration wird übertragen (Proxmox-Bridges → Cilium ClusterPool + NetworkPolicies)
3. Der Storage wird migriert (ZFS- / Ceph-Volumes → LINSTOR in Cozystack)
4. Validierungsfenster auf Kundenseite (7–14 Tage)
5. Umschaltung von DNS und Load Balancer

Während des Piloten baut das Support-Team betriebliche Vertrautheit mit Cozystack auf. Die Dokumentationsmuster spielen sich ein.

Phase 3 — Produktive Migrationskohorten

Kohorten von jeweils 30–100 Kunden. Pro Kunde derselbe Ablauf wie im Piloten, mit wachsender betrieblicher Effizienz, je mehr das Team den Workflow verinnerlicht.

Kunden mit LXC werden gesondert behandelt: entweder als KubeVirt-VM im System-Stil (1:1-Ersatz) oder durch Umbau zu einem Kubernetes-nativen Anwendungscontainer (je nach Präferenz und Unterstützung des Kunden).

Phase 4 — Abschaltung von Proxmox (parallel zu Phase 3)

Mit dem Abschluss der Migrationskohorten wandert die Proxmox-Hardware in den Cozystack-Cluster. Die Proxmox-Subscription läuft gemäß Verlängerungszyklus aus. Die Daten des Proxmox Backup Server werden gemäß den Kundenvereinbarungen archiviert.

Realistische Zeitpläne

Für einen typischen mittelgroßen Hosting-Anbieter (300–1.000 Kunden):

• Phase 0: 14 oder 28 Tage
• Phase 1: wenige Wochen nach Bereitstellung der Hardware
• Phasen 2–3: zusammen typischerweise 3–9 Monate
• Phase 4: parallel zu den letzten Kohorten

Die Plattform läuft wenige Wochen nach Bereitstellung der Hardware; der Umzug von Workloads und Kunden dauert typischerweise 3–9 Monate.

Bei größeren Betreibern (1.000–5.000 Kunden) dauert der Umzug länger, um ein tragfähiges Kohortentempo zu halten.

Woran Migrationen von Proxmox zu Cozystack scheitern

1. LXC-Workloads

Wenn ein erheblicher Teil der Kunden-Workloads LXC als System-Container nutzt (z. B. ein LAMP-Stack pro Kunde in einem einzigen LXC), erfordert die Migration zu Kubernetes-nativen Containern einen Umbau. Die Alternative ist der Betrieb als KubeVirt-VMs (1:1-Abbildung, aber höherer Ressourcenbedarf). Planen Sie dafür in Phase 0 Zeit ein.

2. Abweichende kundenseitige APIs

Manche Kunden haben eigene Werkzeuge gegen die Proxmox API gebaut. Cozystack stellt die Kubernetes API und die Cozystack Dashboard API bereit; die Schnittstellenverträge unterscheiden sich. Migrationsunterstützung auf Kundenseite (Dokumentation, mitunter ein API-Kompatibilitäts-Shim) ist Teil der Engagement-Arbeit.

3. Schulung des Betriebsteams

Proxmox-Betreiber sind mit der Proxmox-Web-UI und den imperativen CLI-Werkzeugen qm / pct / pvesh vertraut. Cozystack setzt für produktive Änderungen GitOps voraus. Das Betriebsteam braucht 4–8 Wochen gezielte Schulung und anschließend 3–6 Monate Praxis. Das Ænix-Engagement umfasst Schulungen; zugleich muss auch der Kunde in den Übergang investieren.

4. ZFS-spezifische Workloads

Manche Kunden haben sich gerade wegen der ZFS-Funktionen auf dem Host für Proxmox entschieden (erweiterte Snapshots, über ZFS replizierte Backups). Cozystack liefert LINSTOR (DRBD) aus; ZFS-spezifische Betriebsmuster lassen sich nicht übertragen. Das Gespräch mit dem Kunden über funktionale Äquivalenz ist Teil von Phase 0.

Im Vergleich zu anderen Alternativen

Im Vergleich zum Eigenbau auf reinem KVM + libvirt + Kubernetes: Dieselben Zielkonflikte wie bei jeder Open-Source-Eigenbauoption. Mit Cozystack ist eine mandantenfähige Plattform in wenigen Wochen bis wenigen Monaten produktiv; ein Eigenbau braucht 12–24 Monate, bis er dasselbe Niveau erreicht. Für Betreiber mit starker Platform-Engineering-Kapazität ist der Eigenbau eine glaubwürdige Alternative.

Im Vergleich zu VMware (nach Broadcom): Eine Migration von Proxmox zu VMware ist 2026 selten — der Weg zurück ist nach Broadcom wirtschaftlich meist nicht sinnvoll.

Im Vergleich zu Nutanix: Nutanix AHV ist ein proprietäres KVM mit geschlossenem Quellcode. Für Betreiber, denen ein Open-Source-Fundament wichtig ist, gewinnt Cozystack allein durch diese Eigenschaft. Für Betreiber, die integrierten kommerziellen Support ohne den Mehraufwand von Open Source schätzen, gewinnt Nutanix.

Im Vergleich zu OpenShift Virtualization: Beide basieren auf KubeVirt. OpenShift passt zu bestehenden Red-Hat- und OpenShift-Kunden; Cozystack passt zu Betreibern, die eine Open-Source-orientierte Beschaffung und einen schlankeren betrieblichen Footprint bevorzugen.

Wann dieses Engagement-Modell passt

Gut geeignet:

• Hosting-Anbieter oder MSP mit mehr als 300 Kunden
• Wachstumskurs in Richtung 1.000+ Kunden
• Kundennachfrage nach Diensten jenseits von VMs
• Betrieb über mehrere Rechenzentren
• Budget für ein Migrationsprogramm mit typischerweise 3–9 Monaten Kundenumzug

Grenzfall:

• Anbieter mit 200–300 Kunden — Grenzbereich; hängt vom Wachstumskurs und vom Anspruch an den Servicekatalog ab

Schlecht geeignet:

• Mittelstands-IT (< 100 interne VMs) — Proxmox ist weiterhin besser
• Lab- und Entwicklungsumgebungen — die Einfachheit von Proxmox gewinnt
• Hosting-Anbieter mit weniger als 200 Kunden — schlecht geeignet für ein vollständiges Migrationsprogramm; stattdessen eine neue Produktlinie auf der Ænix Public Cloud Platform im Providermaßstab erwägen

Aufbau des Engagements

• Discovery Call (30 Min., kostenlos)
• Platform Readiness Assessment (Festpreis, 14 Tage fokussiert oder 28 Tage vollständig) — Go/No-Go mit TCO-Vergleich
• Pilot-Deployment — Cozystack wird aufgebaut, 5–20 wohlgesonnene Kunden werden migriert
• Kohortenmigration — Kundenmigration in Kohorten; Pilot und Kohorten zusammen typischerweise 3–9 Monate
• Abschaltung von Proxmox (parallel) — sobald Kohorten abgeschlossen sind
• Support-Subskription (laufend) — Plus- oder Enterprise-Stufe für Abdeckung rund um die Uhr (siehe Preise)

Tiefer einsteigen

• Proxmox-Migrations-Hub — kommerzielle Landingpage
• Vergleich Proxmox vs. VMware vs. Cozystack — Entscheidungsmatrix
• Proxmox-Alternative — kommerzielle Landingpage mit Fokus auf Alternativen
• Branchenseite Hosting-Anbieter — branchenspezifische Positionierung
• Wirtschaftlichkeit der Public Cloud Platform für Hosting-Anbieter — Unit Economics Schritt für Schritt
• Plattformmodernisierung für Hosting-Anbieter — Modernisierungsmuster

Innerhalb von rund drei Jahren ist die Private Cloud von der „Architektur von gestern“ zum „Standard von morgen für regulierte und kostensensible Workloads“ geworden. Laut dem Broadcom Private Cloud Outlook 2025 priorisieren inzwischen 53 % der Organisationen die Private Cloud für neue Workloads. Die LSEG Global Cloud Survey berichtet, dass 84 % der Finanzdienstleister ihre Cloud-Strategie wegen regulatorischen Drucks angepasst haben. Der Wandel ist real.

Die Architekturentscheidungen sehen 2026 allerdings anders aus als bei den OpenStack-zentrierten Private Clouds aus der Zeit um 2018. Der Standard-Stack hat sich zu Kubernetes-nativer Virtualisierung (KubeVirt) plus Open-Source-Storage und -Networking verschoben. Das Betriebsmodell ist ausgereift, die Zielkonflikte liegen klarer auf dem Tisch.

Was „Private Cloud“ 2026 bedeutet

Eine Private Cloud ist eine dedizierte Cloud-Infrastruktur, die für eine einzelne Organisation oder einen einzelnen Tenant betrieben wird. Sie bietet dieselben Self-Service-Nutzungsmuster wie die Public Cloud (Bereitstellung auf Abruf, Mandantenfähigkeit, Observability, Automatisierung) — allerdings auf Infrastruktur, die die Organisation selbst kontrolliert.

2026 tritt die Private Cloud in einer dieser Formen auf:

• Im Eigentum und Betrieb des Kunden — die Organisation besitzt die Hardware und betreibt die Plattform.
• Im Eigentum des Kunden, Betrieb durch einen Anbieter — die Organisation besitzt die Hardware, ein Anbieter betreibt die Plattform vertraglich.
• Dediziert im Eigentum des Anbieters — der Anbieter stellt dedizierte Infrastruktur (Single-Tenant) bereit, die Organisation nutzt sie.
• Souveräne Hyperscaler-Region — vom Hyperscaler betriebene Infrastruktur mit Souveränitätskontrollen (manche zählen sie dazu, manche nicht).

Dieser Artikel konzentriert sich auf die Varianten 1 und 2 im Eigentum des Kunden — die Architektur ist ähnlich, der Betrieb unterscheidet sich.

Architekturschichten

Eine moderne Private Cloud besteht aus sechs funktionalen Schichten:

Schicht 1: Hardware

• Compute — x86- oder ARM-Server; aktuelle Generationen unterstützen alle relevanten Workloads. KI und GPU bilden eine eigene Hardware-Ebene (NVIDIA H100/H200/L40S/Blackwell, AMD MI-Serie).
• Storage — replizierter Block-Storage (LINSTOR, Ceph oder Hersteller-SAN). Object Storage für Backups und Anwendungen.
• Netzwerk — Rechenzentrums-Fabric (BGP-geroutetes Leaf-Spine wird zunehmend zum Standard); 25–100 Gbit/s Ethernet genügen für die meisten Workloads außerhalb von HPC.
• Rechenzentrum — eigener Standort, Colocation oder ROBO/Edge. Strom, Kühlung, physische Sicherheit.

Schicht 2: OS- und Plattformfundament

• Betriebssystem — Linux, für Kubernetes-Hosts zunehmend minimal (Talos, Bottlerocket, Flatcar). RHEL oder Ubuntu LTS für VM-Hypervisoren außerhalb von Kubernetes.
• Kubernetes — Vanilla, OpenShift, Cozystack oder herstellergeführt. Die Wahl der Distribution ist eine strukturelle Entscheidung.
• Virtualisierung — KubeVirt für VM-Workloads innerhalb von Kubernetes (der modernste Ansatz); KVM/libvirt direkt (OpenStack); VMware (Legacy).

Schicht 3: Storage und Networking

• Block-Storage — LINSTOR (DRBD-basiert, Standard in Cozystack), Ceph (über Rook verwaltet), Hersteller-SAN.
• Object Storage — Ceph RGW, MinIO, SeaweedFS.
• Netzwerkvirtualisierung — Cilium (eBPF, 2026 der Standard), Calico, OVN.
• Load Balancing — MetalLB für Layer 2/3, Cilium L7, Ingress-Controller (NGINX / Traefik / Contour).

Schicht 4: Control Plane

• Mandantenfähigkeit — Tenant CRD (Cozystack), Namespace-basiert (Vanilla-Kubernetes), im Stil des vCloud Director (Legacy).
• Identität — Keycloak, Okta-Integration, AD-Integration. SPIFFE/SPIRE für Service-Identitäten.
• GitOps — Argo CD oder Flux. Cozystack setzt auf Flux.
• Observability — VictoriaMetrics + VictoriaLogs (Cozystack-Standard), Prometheus + Loki, SaaS-Angebote von Herstellern.
• Backup/DR — Velero + S3, anwendungsspezifische Muster (PostgreSQL PITR).

Schicht 5: Anwendungs- und Plattformdienste

• Managed Databases — PostgreSQL (CloudNativePG), MariaDB, MongoDB, Redis, Valkey, Kafka, ClickHouse, RabbitMQ, NATS, OpenSearch.
• Object Storage as a Service — S3-kompatibel.
• KI/ML-Plattform — KubeVirt für VM-basierte GPU-Nutzung, Kubernetes-nativ für containerbasierte GPU-Nutzung, vLLM/Triton für Inferenz.
• Self-Service-Portal — Backstage, Cozystack Dashboard, Eigenentwicklung.

Schicht 6: Betrieb

• Runbooks — dokumentierte Betriebsabläufe.
• Rufbereitschaft — Modell für die Incident Response.
• Kapazitätsplanung — quartalsweise Hardwareerneuerung, Wachstumsprognosen.
• Compliance-Status — Audit-Logging, Zertifizierungen (wo zutreffend), Dialog mit der Aufsicht.

Drei Architekturmuster, die funktionieren

Muster 1: Kubernetes-native Cloud auf Basis von Cozystack

Was: Ein einzelner Kubernetes-Cluster (oder eine Flotte) mit Cozystack als Plattformschicht. KubeVirt für VMs, Kubernetes für Container, LINSTOR für Storage, Cilium für Networking, Tenant CRD für Mandantenfähigkeit, Cozystack Dashboard für Self-Service.

Am besten geeignet für: Service-Provider, Betreiber souveräner Clouds, regulierte Multi-Tenant-Umgebungen. Greenfield-Projekte.

Vorteile: Open Source, ein einziger Stack, Mandantenfähigkeit nativ, Virtualisierung und Container auf einer Plattform.

Nachteile: Jünger als OpenStack; kleinere Community als reine Kubernetes-Deployments.

Muster 2: Klassische Private Cloud auf Basis von OpenStack

Was: OpenStack als Compute-Orchestrator, Ceph für Storage, OVN für Networking, Heat/Terraform für die Bereitstellung. Optional Kubernetes auf OpenStack für Container-Workloads.

Am besten geeignet für: Organisationen mit tiefer OpenStack-Erfahrung; große Telco- oder Souveränitätsprojekte, bei denen OpenStack der Beschaffungsstandard ist.

Vorteile: Ausgereift, breite Community, viele Anbieteroptionen.

Nachteile: Betrieblich komplex; OpenStack-Engineers sind 2026 schwerer zu finden; weniger Kubernetes-nativ.

Muster 3: VMware Cloud Foundation (VCF) — Legacy

Was: vSphere + vSAN + NSX + vCD + Aria (früher vRealize). Proprietär, im Subscription-Modell lizenziert.

Am besten geeignet für: Bestehende VMware-Umgebungen, die durch die Broadcom-Ökonomie noch nicht zum Ausstieg gezwungen wurden.

Vorteile: Ausgereift, gut bekannt, umfangreiche Integrationen.

Nachteile: Nach Broadcom nur noch als Subscription erhältlich, beobachtete Preissteigerungen um den Faktor 2 bis 5, Bindung an die Roadmap eines einzigen Herstellers.

(Hinweise zum VMware-Ausstieg finden Sie unter VMware-Alternative.)

Die Architekturentscheidungen mit dem größten Gewicht

Fünf Entscheidungen haben die stärkste langfristige Wirkung:

Entscheidung 1: Virtualisierungsschicht

KubeVirt oder klassischer Hypervisor? KubeVirt ist 2026 der Standard für Greenfield-Projekte; ein klassischer Hypervisor (KVM/libvirt direkt) ist bei sehr großen OpenStack-Deployments angemessen, bei denen der Overhead von KubeVirt ins Gewicht fällt.

Entscheidung 2: Storage-Architektur

LINSTOR/DRBD für replizierten Block-Storage? LINSTOR ist betrieblich einfacher und der Cozystack-Standard. Ceph ist flexibler, aber aufwendiger im Betrieb. Ein Hersteller-SAN ist eine Option, doch die Verträge schränken Ihr Skalierungsmuster ein.

Entscheidung 3: Networking

Cilium ist zum Standard-CNI für neue Deployments geworden. NSX-äquivalente Funktionen (Cilium L7, Service Mesh) ersetzen die Funktionalität von VMware NSX. Die Entscheidung hängt eher davon ab, wie vertraut Ihr Team mit eBPF ist, als von der technischen Eignung.

Entscheidung 4: Mandantenmodell

Für das Service-Provider-Modell ist das Tenant CRD (Cozystack) der Standard. Für interne Mandantenfähigkeit über mehrere Geschäftsbereiche genügen Namespaces plus RBAC. Für absolute Isolation: ein Cluster pro Tenant (betrieblich teuer).

Entscheidung 5: Betriebsmodell

Betrieb durch den Kunden (Sie betreiben die Plattform), Betrieb durch einen Anbieter (Ænix oder ein vergleichbarer Partner betreibt sie für Sie) oder hybrid (Sie betreiben, der Anbieter liefert den 2nd-Level-Support). Die Entscheidung hängt von der Kapazität des internen Teams und der Risikobereitschaft ab.

Kapazitätsplanung

Eine praxistaugliche Faustregel für eine Last von 100 VM-Äquivalenten:

• Compute: 6–10 Dual-Socket-Server mit je 256–512 GB RAM. 30 % Reserve für Ausfälle und Wachstum einplanen.
• Storage: rund 100 TB repliziert (3 Replikate) für den Regelbetrieb plus Kapazität für Snapshots und Backups. Dafür werden etwa 300 TB Rohkapazität benötigt.
• Netzwerk: 25-Gbit/s-NIC pro Server, Leaf-Spine-Fabric, 100-Gbit/s-Backbone.
• Rechenzentrum: etwa 6–10 kW pro Rack bei moderner Packungsdichte.
• DR-Standort: vergleichbarer zweiter Footprint.

Über 1000 VMs hinaus wächst die Hardware ungefähr linear; das Plattformteam wächst bei guter Automatisierung unterproportional.

Betriebspraktiken, auf die es ankommt

• Quartalsweise Kapazitäts-Reviews — Hardware dem Wachstum voraus beschaffen.
• Zwei Kubernetes-Upgrades pro Jahr — bei CVEs und Funktionsumfang auf dem aktuellen Stand bleiben.
• Dokumentierte Incident Response — Incident Commander, Protokollführung, Post-Mortems ohne Schuldzuweisung.
• Compliance-Status — Audit-Logs, Zertifizierungen, Dialog mit der Aufsicht, wo zutreffend.
• Realistisch bemessenes Plattformteam — 1–3 Engineers für eine kleine Private Cloud mit einem einzelnen Cluster; 5–15 für einen Service-Provider mit mehreren Clustern.

Häufige Architekturfehler

Fehler 1: Public-Cloud-Architektur kopieren

Die Private Cloud wird so entworfen, dass sie intern wie AWS aussieht. Die Skalenökonomie ist eine andere; Public-Cloud-Architekturmuster (massiv verteilte Systeme mit Eventual Consistency) sind für die meisten Private Clouds überdimensioniert.

Fehler 2: Herstellergeführte Private Cloud

Wer eine „Private-Cloud-Appliance“ kauft, baut den Lock-in mit einem neuen Hersteller wieder auf. Die Roadmap des Herstellers wird zu Ihrer eigenen.

Fehler 3: Zu wenig in den Betrieb investiert

Compute und Storage sind gelöst, aber in Observability, Identität, Backup/DR und Runbooks wurde zu wenig investiert. Es entstehen betriebliche Altlasten.

Fehler 4: Mandantenfähigkeit im Design ausgelassen

Ein Single-Tenant-Cluster wird später auf Mandantenfähigkeit hochskaliert. Nachträglich angeflanschte Mandantenfähigkeit scheitert im großen Maßstab oder bei einer Prüfung durch die Aufsicht.

Fehler 5: Hardwareerneuerung nicht budgetiert

Die Hardwareerneuerung im vierten Jahr fehlt in der ursprünglichen Wirtschaftlichkeitsrechnung. Die Kostenklippe der Erneuerung kommt dann unerwartet.

Tiefer einsteigen

• Private-Cloud-Consulting — Details zum Engagement
• Datensouveränität — Souveränität als Auslöser
• Cloud-Repatriierung — beim Wechsel aus der Public Cloud
• VMware-Alternative — beim Wechsel weg von VMware
• Cozystack — Open-Source-Plattformfundament

OpenStack ist in Telco- und Behördeninfrastrukturen nach wie vor weit verbreitet. Gleichzeitig steht es unter strukturellem Druck: Der Pool an OpenStack-Engineers schrumpft, die betriebliche Komplexität wächst mit dem Alter eines Deployments, und es gibt Kubernetes-native Alternativen, die es zum Zeitpunkt des OpenStack-Designs noch nicht gab.

Wo OpenStack weiterhin überzeugt

• Deployments im Telco-Maßstab — Tausende Nodes mit telco-spezifischen Funktionen (NFV, DPDK-Integration, SR-IOV, Hochdurchsatz-Networking). Die Expertise ist etabliert, die Herstellerdistributionen sind ausgereift.
• Behörden- und souveräne Clouds — große OpenStack-Deployments im öffentlichen Sektor, in denen OpenStack die per Ausschreibung vorgegebene Plattform ist.
• Bestehende Investitionen — Organisationen, die seit mehr als fünf Jahren mit OpenStack arbeiten und tiefe Expertise aufgebaut haben. Die Kosten einer Migration können die Kosten des Weiterbetriebs übersteigen.
• Bestimmte Funktionen — einige OpenStack-Fähigkeiten (tiefgehende Netzwerkprogrammierbarkeit, spezielle Telco-Features) haben noch keine direkten Kubernetes-Entsprechungen.

Woher der Druck kommt

• Fachkräftemangel — der Pool an OpenStack-Expertise schrumpft. Neue Engineers werden auf Kubernetes ausgebildet, nicht auf OpenStack.
• Wildwuchs an Komponenten — über 30 Services in einem typischen OpenStack-Deployment, jeder mit eigenem Lifecycle, eigenem Upgrade-Rhythmus und eigenen Integrationstests.
• Aufwendige Upgrades — Major-Upgrades von OpenStack sind betrieblich nach wie vor schwergewichtig.
• Zersplitterte Herstellerdistributionen — Red Hat OSP, Mirantis, Canonical und andere, jede mit eigenen Vorstellungen und eigenem Supportmodell.

Modernisierungspfade

Für OpenStack-Betreiber, die über eine Modernisierung nachdenken:

Pfad 1: bleiben und optimieren

OpenStack weiterbetreiben und in die Betriebspraxis investieren (Helm-basierte Deployments, GitOps, Automatisierung). Richtig, wenn die OpenStack-Expertise tief ist und die Kosten einer Migration ihren Nutzen übersteigen.

Pfad 2: Kubernetes auf OpenStack

Kubernetes-Plattformen (Cozystack oder andere) als Tenant auf OpenStack betreiben. Das fügt eine weitere Plattformschicht hinzu; manche Teams halten diesen Weg für einen schrittweisen Übergang trotzdem für praktikabel.

Pfad 3: paralleles Deployment

Cozystack neben OpenStack auf neuer Hardware aufbauen. Workloads Kohorte für Kohorte migrieren. OpenStack stilllegen, sobald die Kohorten abgeschlossen sind. Der häufigste Weg zur vollständigen Modernisierung.

Pfad 4: vollständiges Lift-and-Shift auf Kubernetes

Der aggressive Weg — die OpenStack Control Plane durch ein Kubernetes-basiertes Gegenstück (Cozystack) ersetzen. Höheres Risiko, schnelleres Ergebnis.

Cozystack-Architektur für Teams mit OpenStack-Hintergrund

Einige hilfreiche Entsprechungen:

Die meisten OpenStack-Engineers empfinden das Betriebsmodell von Cozystack als einfacher — weniger bewegliche Teile, stärker deklarativ, integrierte Observability.

Praktisches Vorgehen bei der Migration

Für eine OpenStack-zu-Cozystack-Migration mittlerer Größe (50–500 Hosts):

1. Assessment (14 oder 28 Tage) — bestehendes OpenStack-Deployment, Klassifizierung der Workloads, Zielarchitektur für Cozystack.
2. Cozystack-Fundament — paralleles Deployment auf neuer oder umgewidmeter Hardware.
3. Migrationskohorten — die Workloads ziehen Kohorte für Kohorte um. Images werden über KVM→KubeVirt migriert.
4. Stilllegung von OpenStack — gestaffelt, sobald die Kohorten abgeschlossen sind.

Gesamtdauer: 4–12 Monate für ein mittelgroßes Deployment; 12–18 Monate bei komplexen Provider-Netzwerken oder OpenStack-APIs, die Mandanten direkt nutzen.

OpenStack ist in Telekommunikations- und Großunternehmens-Infrastrukturen nach wie vor weit verbreitet. Für die Modernisierung gibt es kein Patentrezept: Ein ausgereiftes OpenStack im Telco-Maßstab mit tiefem Support durch eine Hersteller-Distribution ist eine ganz andere Migration als ein mittelgroßes Unternehmen, das Upstream-OpenStack mit einem kleinen Betriebsteam fährt. Beide können auf Cozystack umsteigen; Phasenplanung und Risikoprofil unterscheiden sich jedoch erheblich.

Wo OpenStack weiterhin funktioniert (und das sagen wir auch)

Bevor wir über Migration sprechen, zunächst ehrlich der Gegenfall. OpenStack bleibt die richtige Antwort für:

• NFV-Umgebungen von Tier-1-Telcos, in denen die Hersteller-Distribution (Red Hat OSP, Mirantis, Canonical, Wind River) noch Support-Laufzeit hat und die VNF-Zertifizierung OpenStack-spezifisch ist
• Sehr große Bestände (>1.000 Nodes) mit tiefem OpenStack-Know-how, bei denen sich die betriebliche Komplexität bereits amortisiert hat
• Government Clouds, in denen OpenStack die vergaberechtlich vorgeschriebene Plattform ist (einige Ausschreibungen des öffentlichen Sektors in EU-Mitgliedstaaten und im APAC-Raum)
• Bestehende Investitionen im Jahr 2–3 eines fünfjährigen Rollouts, bei denen die Migrationskosten die Kosten des Weiterbetriebs übersteigen würden

Für alle anderen lohnt sich in der Regel eine ernsthafte Bewertung der Modernisierung.

Was OpenStack-Betreiber zur Migration drängt

Drei Treiber bestimmen die Diskussion 2026:

1. Lebenszyklus der Hersteller-Distributionen

Red Hat lenkt Kunden von OSP (OpenStack Platform) zu OpenShift-basierten Angeboten. Andere Distributionen (Mirantis, Canonical) sind weiter am Markt, doch die Anbieterlandschaft für OpenStack-Distributionen konsolidiert sich. Prüfen Sie die Supportdaten in Ihrem eigenen Vertrag: Bei vielen Deployments aus der Mitte der 2020er-Jahre fallen sie in die nächsten Jahre.

2. Fachkräftemangel

OpenStack-Know-how wird knapper. Neue Engineers lernen Kubernetes, nicht das Komponentenmodell aus Nova/Neutron/Cinder/Keystone. Betreiber mit tiefer OpenStack-Erfahrung gehen in den Ruhestand oder wechseln in andere Rollen. Einstellen wird schwieriger, Halten ebenso.

3. Grenze des Servicekatalogs

Der Kernumfang von OpenStack ist IaaS (Compute, Netzwerk, Storage). Verwaltete Datenbanken (Trove), Container-Orchestrierung (Magnum) und moderne Servicefamilien (Managed Kafka, S3-Äquivalent im großen Maßstab, GPU-as-a-Service, AI Inference) lassen sich entweder nur umständlich anflanschen oder liegen ganz außerhalb der Plattform. Für Betreiber, deren Kunden oder interne Teams zunehmend Services in Plattformqualität erwarten, fällt OpenStack ohne erheblichen zusätzlichen Engineering-Aufwand zurück.

Komponenten-Mapping

Für OpenStack-Betreiber, die Cozystack bewerten, gilt folgende kanonische Übersetzung:

Die meisten OpenStack-Engineers empfinden das Betriebsmodell von Cozystack als einfacher, sobald sie die Kubernetes-Lernkurve genommen haben — weniger bewegliche Teile, deklarativer, integrierte Observability. Die Lernkurve selbst ist allerdings real: 4–8 Wochen gezieltes Training pro Engineer, länger für fachliche Tiefe.

Migrationsphasen in Kohorten

Phase 0 — Assessment (14 oder 28 Tage)

Bestandsaufnahme des OpenStack-Deployments:

• Nutzung Service für Service — welche OpenStack-Services Sie tatsächlich verwenden (Nova / Neutron / Cinder fast immer, alles andere variiert)
• Workload-Inventar — Anzahl der Instanzen, Betriebssystem-Mix, vCPU-/RAM-/Disk-Profile, Kritikalitätsstufe
• Netzwerk-Inventar — Subnetze, Security Groups, Floating IPs, Konfigurationen externer Netze, Octavia-Load-Balancer
• Storage-Inventar — Cinder-Volume-Typen, Aufbewahrung von Snapshots, Nutzung von Swift-Buckets
• Mandantenfähigkeit — Hierarchie aus Projects und Domains, benutzerdefinierte Rollen, RBAC-Richtlinien
• Integrationen — VNF-Zertifizierungen der Hersteller, Observability-Anbindungen, CI/CD-Pipelines, ITSM-Werkzeuge

Ergebnis: ein Migrationsplan mit Workload-Kategorien (jetzt migrieren / später migrieren / bleiben / neu architekturieren), Risikomarkierungen und Optionen für die Phasenplanung.

Phase 1 — Cozystack-Fundament

Hardwarebeschaffung (oder in späteren Phasen Wiederverwendung der Kapazität, die OpenStack freigibt). Die Cozystack-Plattform wird auf neuer Hardware parallel zum bestehenden OpenStack aufgebaut. Das Cilium-Networking wird gegen jene OpenStack-Netzwerkkonfigurationen validiert, die übertragen werden sollen. LINSTOR-Storage wird im großen Maßstab in Betrieb genommen. Föderierte Identität (Keycloak + IdP des Kunden).

Das Tenant-CRD-Modell wird so entworfen, dass es sich sauber aus der Project-/Domain-Hierarchie von OpenStack ableiten lässt. Jedes OpenStack-Project der obersten Ebene wird typischerweise zu einem Cozystack-Tenant, verschachtelte Projects werden zu verschachtelten Tenants.

Endzustand: Die Cozystack-Plattform läuft, ist intern validiert und bereit für das Onboarding der Workloads.

Phase 2 — Betriebswerkzeuge

Observability-Stack (VictoriaMetrics + VictoriaLogs), integriert in das SIEM des Kunden. Backup/DR mit Velero plus anwendungsspezifischen Mustern. Runbook-Bibliothek. Rufbereitschaft. Incident-Response-Prozess. GitOps-Deployment-Workflow (standardmäßig Flux, Argo CD auf Wunsch des Kunden).

Endzustand: Werkzeuge in Produktionsbetriebsqualität sind vorhanden, die Schulung des Teams läuft.

Phase 3 — Workload-Migration in Kohorten

Es migrieren jeweils Kohorten von 50–200 Instanzen. Pro Kohorte:

1. Image-Konvertierung — OpenStack-Glance-Images werden in ein KubeVirt-kompatibles Format konvertiert. Die meisten KVM-basierten OpenStack-Images lassen sich mit qemu-img convert und kleinen Metadatenanpassungen umwandeln. In Windows-Instanzen werden virtio-Treiber injiziert.
2. Netzwerk-Mapping — OpenStack-Subnetze auf Cilium ClusterPool + NetworkPolicies, Security Groups auf NetworkPolicies, Octavia-Load-Balancer auf MetalLB + Ingress Controller.
3. Storage-Migration — Die Daten der Cinder-Volumes werden nach LINSTOR migriert. Die Snapshot-Historie wird je nach Aufbewahrungsrichtlinie übernommen oder bereinigt. Für Daten in Swift erlaubt die S3-API-Kompatibilität eine direkte Migration nach SeaweedFS.
4. Validierungsfenster — Der Workload läuft typischerweise 7–14 Tage parallel auf Cozystack. Vor dem endgültigen Cutover ist die Freigabe des Application Owners erforderlich.
5. Endgültiger Cutover — DNS bzw. Load Balancer werden auf den Cozystack-Endpunkt umgeschaltet. Die OpenStack-Instanz bleibt für ein Rollback-Fenster von 7–30 Tagen verfügbar.

Phase 4 — Betriebsübergabe (parallel zu Phase 3)

Die Ænix-Engineers reduzieren ihre direkte Beteiligung. Das Betriebsteam des Kunden übernimmt Incidents im First- und Second-Level. Der Ænix-Support (Plus- oder Enterprise-Stufe für 24×7) läuft für die Eskalation weiter. Übergabe der Dokumentation. Sitzungen zum Wissenstransfer.

Phase 5 — Stilllegung von OpenStack

Sobald Migrationskohorten abgeschlossen sind, wird OpenStack-Kapazität in den Cozystack-Cluster überführt. Die Hardware ist dieselbe Standard-x86-Hardware; der OpenStack-Software-Stack wird stillgelegt. Verträge für Hersteller-Distributionen laufen gemäß ihrem Lebenszyklus aus.

Woran Migrationen von OpenStack zu Cozystack scheitern

1. Neuentwurf des Netzwerkmodells

Das Netzwerkmodell von OpenStack Neutron war traditionell hochgradig konfigurierbar — Provider-Netze, Tenant-Netze, Security Groups, Floating IPs, FWaaS, VPNaaS, komplexe Routing-Topologien. Das eBPF-Modell von Cilium ist grundlegend anders: L4/L7-NetworkPolicies, eBPF-basiertes Routing, Hubble für Observability.

Ausgefeilte Neutron-Konfigurationen auf Cilium zu übertragen, erfordert sorgfältige Architekturarbeit in Phase 0–1. Wer diese überspringt, erlebt in Phase 3 Produktionsvorfälle, weil Kunden-Workloads ein bestimmtes Netzwerkverhalten erwarten, das sich nicht direkt übertragen lässt.

2. Übersetzung der Mandanten-Richtlinien

Das rollenbasierte Zugriffsmodell von OpenStack (Keystone-Rollen, Project-Policies) lässt sich nicht 1:1 auf Kubernetes RBAC + Tenant CRD abbilden. Benutzerdefinierte Rollen für bestimmte OpenStack-APIs haben möglicherweise keine direkte Entsprechung in Kubernetes. Planen Sie Zeit für einen Neuentwurf der Richtlinien ein statt für eine mechanische Übersetzung.

3. VNF-Zertifizierung

Tier-1-Telcos mit zertifizierten VNFs stehen vor einer anderen Herausforderung: Der VNF-Hersteller zertifiziert auf bestimmten OpenStack-Distributionen, nicht auf Cozystack. Drei Ansätze:

• VNFs auf KubeVirt unter Cozystack betreiben — die VNF läuft als VM; ob die Herstellerzertifizierung diese Konfiguration abdeckt, ist offen. Ein Gespräch mit dem Hersteller ist notwendig.
• Zertifizierte VNFs auf OpenStack belassen — parallele Plattformen für den Lebenszyklus der zertifizierten VNF; ein Modernisierungs-Track für neue VNFs auf Cozystack.
• Ein Cloud-native Äquivalent verhandeln — viele VNF-Hersteller wechseln zu Cloud-Native Network Functions (CNFs) auf Kubernetes; die Migration lässt sich womöglich mit der CNF-Modernisierung des Herstellers verzahnen.

In der Praxis kommen alle drei Muster vor, oft beim selben Betreiber — je nachdem, um welchen VNF-Hersteller und welche Generation es geht.

4. Wandel der Betriebskultur

OpenStack-Betreiber sind imperative APIs gewohnt (CLI-Befehle, REST-Aufrufe, Aktionen in der Konsole). Cozystack erwartet GitOps für produktive Änderungen. Das ist ein Kulturwandel, nicht nur ein Werkzeugwechsel. Engineers, deren OpenStack-Expertise auf imperativen Workflows aufbaut, brauchen 4–8 Wochen gezieltes Training plus 3–6 Monate Praxis, um die GitOps-Disziplin zu verinnerlichen.

Ein Ænix-Engagement umfasst Training als eigenen Workstream; zugleich muss der Kunde selbst in den kulturellen Wandel investieren.

Realistische Zeitpläne

Mittelgroßes Unternehmen (200–500 Nodes, einfache Mandantenstruktur, überwiegend Standard-Networking):

• Phase 0: 14 oder 28 Tage
• Phasen 1–5: Fundament, Betriebswerkzeuge, Kohortenmigration, Übergabe und Stilllegung, teilweise parallel

Gesamt: 4–12 Monate für ein mittelgroßes Deployment; 12–18 Monate bei komplexen Provider-Netzwerken oder OpenStack-APIs, die Mandanten direkt nutzen

Tier-1-Telco (1.000–5.000 Nodes, komplexe Mandantenstruktur, zertifizierte VNF-Umgebungen, NFV-spezifisches Networking):

• Phase 0: 2–3 Monate
• Phase 1: 4–6 Monate
• Phase 2: 2–3 Monate
• Phase 3: 12–24 Monate (mehrere parallele Kohorten)
• Phase 4–5: 6–12 Monate
• Track zur VNF-Modernisierung: parallel 18–36 Monate

Gesamt: 24–48 Monate für die vollständige Modernisierung; erste produktive Workloads auf Cozystack innerhalb von 12–18 Monaten

Wann die Migration von OpenStack zu Cozystack die richtige Antwort ist

Gute Passung:

• Der Lebenszyklus der Hersteller-Distribution erzwingt innerhalb von 24 Monaten eine Entscheidung
• Der Fachkräftemangel beginnt, die Betriebsqualität zu beeinträchtigen
• Die Kundennachfrage nach verwalteten Datenbanken / S3 / Containern / GPU-Services übersteigt, was OpenStack nativ abdeckt
• Ein Modernisierungsbudget steht über 2–4 Jahre zur Verfügung

Bedingte Passung:

• Stabiles, ausgereiftes OpenStack-Deployment mit tiefer Teamexpertise und ohne Druck auf den Servicekatalog — die Modernisierung kann bis zum Ende des Herstellerlebenszyklus warten
• Sehr große Bestände (>5.000 Nodes), bei denen die Modernisierungskosten im mehrstelligen Millionenbereich liegen — ein gestaffeltes, mehrjähriges Programm ist erforderlich

Schlechte Passung:

• Kürzlich ausgerolltes OpenStack im ersten Jahr eines Fünfjahresprogramms — bringen Sie zu Ende, was Sie begonnen haben, und modernisieren Sie am Ende des Lebenszyklus
• OpenStack auf Basis einer Vergabevorgabe der öffentlichen Hand ohne Spielraum für einen Plattformwechsel

Aufbau des Engagements

• Discovery Call (30 Min., kostenlos)
• Platform Readiness Assessment (Festpreis, 14 Tage fokussiert oder 28 Tage vollständig) — Workload-Kategorien, Optionen für die Phasenplanung, Risikomarkierungen
• Pilot-Deployment — Cozystack wird aufgebaut, 50–100 Workloads werden migriert, Abrechnungs- und Betriebsabläufe validiert
• Migration in Kohorten — Workload-Migration in Kohorten; insgesamt 4–12 Monate für ein mittelgroßes Deployment, 12–18 Monate bei komplexen Provider-Netzwerken
• Stilllegung von OpenStack (parallel zur Kohortenmigration) — schrittweise, sobald Kohorten abgeschlossen sind
• Support-Subskription (laufend) — Plus- oder Enterprise-Stufe für Eskalation rund um die Uhr (siehe Preise)

Weiterführende Inhalte

• OpenStack-Migrations-Hub — kommerzielle Landingpage
• OpenStack vs Cozystack: Modernisierung — Analyse des Modernisierungspfads
• OpenStack-Alternative — kommerzielle Landingpage mit Fokus auf Alternativen
• Produktseite Public Cloud Platform — häufiges Zielprodukt für OpenStack-Migrationen von Hosting-Anbietern

OpenShift Virtualization (Red Hat) und Cozystack (Ænix / CNCF-Projekt) sind 2026 die beiden ausgereiftesten Plattformen auf Basis von KubeVirt. Sie teilen architektonische Grundlagen, unterscheiden sich aber im kommerziellen Modell, im betrieblichen Footprint und in der Beziehung zum Hersteller.

Gemeinsame Grundlagen

Beide Plattformen betreiben KubeVirt für VM-Workloads neben Kubernetes-Containern. Beide übernehmen die Betriebsmuster von Kubernetes (deklarative Konfiguration, GitOps, RBAC, Observability). Beide unterstützen produktive VM-Workloads mit Live-Migration, Snapshots und Mandantentrennung.

Wo sie sich unterscheiden

Kommerzielles Modell

OpenShift Virtualization: kommerzielle Red-Hat-Subscription. Preise pro Core oder pro Sockel. Enthalten sind Red-Hat-Support, Zertifizierung und Zugang zum Ökosystem.

Cozystack: Open Source unter Apache 2.0. Ænix bietet kommerzielle Support-Stufen an; Sie können die Plattform aber auch ohne kommerzielle Beziehung selbst betreiben.

Für Organisationen, deren Beschaffung auf Red Hat standardisiert ist, ist OpenShift administrativ einfacher. Für Organisationen, die Open Source an erste Stelle setzen oder die Wirtschaftlichkeit eines Service-Providers anstreben, passt Cozystack besser.

Betrieblicher Footprint

OpenShift: ein breiter Funktionsumfang — OpenShift Container Platform plus Virtualization plus Service Mesh plus Pipelines plus weitere Add-ons. Funktional reichhaltig; das Team braucht OpenShift-spezifisches Know-how.

Cozystack: ein fokussierter Stack — KubeVirt + Cilium + Kube-OVN + LINSTOR + Cozystack Dashboard + Observability. Ein schlankerer betrieblicher Footprint; allgemeines Kubernetes-Betriebswissen lässt sich direkt übertragen.

Mandantenfähigkeit

OpenShift: namespacebasiert mit dem Project CRD; RBAC und Quotas greifen auf Namespace-Ebene. Funktioniert für Unternehmen mit mehreren Geschäftsbereichen.

Cozystack: Tenant CRD mit verschachtelten Tenants, abgegrenztem Audit und abrechnungsfreundlichem Modell. Funktioniert für Service-Provider mit vielen Kunden ebenso wie für Unternehmen mit mehreren Geschäftsbereichen.

Beziehung zum Hersteller

OpenShift: Beziehung zu Red Hat / IBM. Die Roadmap wird von den kommerziellen Entscheidungen von Red Hat bestimmt.

Cozystack: Open Source unter Community-Governance (CNCF-Projekt). Ænix hat Cozystack entwickelt und gehört zu den Maintainern, neben Maintainern aus anderen Unternehmen; das Projekt gehört Ænix nicht. Die Roadmap wird von der Community und den kommerziellen Anwendern geprägt.

Integration ins Ökosystem

OpenShift: integriert sich in das breitere Red-Hat-Ökosystem (Ansible, Satellite, Identity Management usw.).

Cozystack: integriert sich in das breitere CNCF-Ökosystem (Alternativen zum Prometheus-Stack, Argo, Crossplane usw.).

Wann OpenShift vorne liegt

• Bestehende Verpflichtungen gegenüber Red Hat / OpenShift
• Unternehmensbeschaffung, die auf Red Hat standardisiert ist
• Bedarf an einem integrierten Red-Hat-Ökosystem (Ansible Automation Platform usw.)
• Beschaffung, die ausdrücklich einen Red-Hat-Vertrag verlangt

Wann Cozystack vorne liegt

• Beschaffung nach dem Prinzip Open Source first
• Service-Provider-Modell (Cloud für viele Kunden)
• Souveränitäts- oder Regulierungsanforderungen, bei denen Open Source zählt
• Kostensensibilität im großen Maßstab (keine Subscription pro Core)
• Greenfield ohne bestehende Beziehung zu Red Hat
• Bedarf an einem schlankeren betrieblichen Footprint als beim vollständigen OpenShift
• SLA-gestützter Support direkt von den Maintainern: veröffentlichte Reaktionszeiten, rund um die Uhr in den Stufen Plus und Enterprise (Preise); die AENIX s.r.o. ist nach ISO/IEC 27001 zertifiziert

Migration zwischen beiden

Beide basieren auf KubeVirt, daher ist die Migration auf VM-Ebene unkompliziert (Kompatibilität auf Image-Ebene). Die architektonischen Unterschiede liegen in:

• Mandantenmodell (Project CRD vs Tenant CRD)
• Networking (OVN-Kubernetes, das das abgekündigte OpenShift SDN abgelöst hat, vs Cilium)
• Storage (OpenShift Data Foundation / Ceph vs LINSTOR / DRBD)
• Betriebswerkzeugen (OpenShift CLI/Console vs Cozystack Dashboard/Standard-kubectl)

Realistischer Zeitrahmen für die Migration: 3–9 Monate für ein mittelgroßes Deployment.

Wie Sie sich entscheiden

Wenn Ihre Situation zu den Stärken von OpenShift passt (Red-Hat-Ökosystem, Unternehmensbeschaffung, breiter Funktionsumfang), wählen Sie OpenShift Virtualization. Wenn Ihre Situation zu den Stärken von Cozystack passt (Open Source, Service-Provider, schlankerer Footprint), wählen Sie Cozystack.

Für eine konkrete Bewertung hilft die Assessment-Phase des jeweiligen Engagements bei der Klärung. Siehe Platform Readiness Assessment.

2026 umfasst die realistische Shortlist für produktive Virtualisierungsplattformen (neben anderen) Nutanix AHV, VMware Cloud Foundation und Cozystack. Jede dieser Plattformen steht für eine andere Architekturphilosophie.

Architekturphilosophien

Nutanix: herstellergeführte, integrierte HCI-Appliance. Betriebliche Einfachheit und integrierter Support bilden das Kernversprechen.

VMware: ausgereifter Legacy-Stack mit tiefer Ökosystem-Integration. Vom Hersteller gesteuerte Roadmap; Subscription-getriebene Ökonomie.

Cozystack: Kubernetes-native Open-Source-Plattform. Vom Kunden kontrollierte Architektur; von der Community gesteuerte Roadmap.

Detaillierter Vergleich

Wann welche Plattform gewinnt

Nutanix gewinnt

• Bei bestehender Nutanix-HCI-Investition mit betrieblicher Expertise
• Bei klarer Präferenz für eine integrierte Appliance mit kommerziellem Support
• Bei einem rein VM-basierten Workload-Portfolio
• Bei mittelgroßen Unternehmen mit integrierter Beschaffung

VMware gewinnt

• Bei bestehenden VMware-Umgebungen, in denen die Verlängerungskosten noch tragbar sind
• Bei tiefer vSphere-Expertise, die sich nur schwer übertragen lässt
• Bei bestimmten Funktionen, die es nur bei VMware gibt (einige Nischen im fortgeschrittenen Networking und Storage)
• (Wegen der Broadcom-Preispolitik 2026 zunehmend selten)

Cozystack gewinnt

• Beim Modell als Service-Provider oder Multi-Tenant-Cloud-Builder
• Bei Anforderungen an Souveränität oder durch die Aufsicht
• Bei einer Präferenz für Open-Source-Beschaffung
• Bei gemischten VM- und Container-Workloads auf einer Plattform
• Bei KI/GPU im großen Maßstab mit Kubernetes-nativen Werkzeugen

Wirtschaftlichkeit der Migration

Ein Wechsel zwischen diesen Plattformen ist nicht umsonst. Realistische Aufwandsschätzungen:

• VMware → Cozystack: rund 8–12 Monate für einen Bestand von ~100 VMs und 18–24 Monate für ~1.000 VMs, einschließlich Planung und Migrationswellen; Assessment (14 oder 28 Tage) + Aufbau der Zielplattform + Kohortenmigration. Typischerweise ab dem zweiten Jahr wirtschaftlich positiv.
• VMware → Nutanix: ähnlicher Zeitrahmen; nutzt das Werkzeug Nutanix Move.
• Nutanix → Cozystack: Migration des gesamten Bestands typischerweise 9–18 Monate, je nach Umfang; die Kompatibilität der KVM-Images hilft.
• Cozystack → VMware/Nutanix: 2026 selten (Rückmigration).

So treffen Sie die Entscheidung

Der Entscheidungsbaum:

1. Bestehende Plattform mit tiefer Expertise, und die Wirtschaftlichkeit stimmt noch? → Bleiben.
2. Multi-Tenant- oder Service-Provider-Modell? → Cozystack.
3. Souveränität / Open-Source-first-Beschaffung? → Cozystack.
4. Präferenz für HCI-Appliances + Nutanix-Beziehung? → Nutanix.
5. VMware-Umgebung ohne Anlass zum Wechsel? → VMware (mit Blick auf die nächste Verlängerung).
6. Greenfield + Team mit Kubernetes-Erfahrung? → Cozystack.

Was Industrie 4.0 im Jahr 2026 tatsächlich bedeutet

Der Begriff ist mit viel Marketing aufgeladen. Praktisch bedeutet Fertigung nach Industrie 4.0:

• IoT-Instrumentierung in den Fertigungshallen
• Echtzeit-Datenerfassung an den Maschinen
• KI-gestützte Qualitätskontrolle und Predictive Maintenance
• Digitale Zwillinge von Produktionslinien
• Systemübergreifende Integration der Lieferkette
• OT/IT-Konvergenz

All das erfordert Infrastruktur — typischerweise eine Mischung aus Edge Compute (nah an den Maschinen), einer regionalen bzw. zentralen Cloud (für Analytics, ML und Integration) und der Anbindung an bestehende Unternehmenssysteme.

Architekturmuster

HQ Cloud (Cozystack)
   ├── Analytics platform
   ├── ML training
   ├── Enterprise integration
   └── Data warehouse
        ↓ (data flow)
Regional sites (Cozystack)
   ├── Regional aggregation
   ├── Production planning
   └── Quality systems
        ↓
Production-floor edge (Cozystack)
   ├── Real-time control
   ├── IoT data ingestion
   ├── Local AI inference
   └── OT/IT interface

Cozystack läuft auf allen drei Ebenen mit einem einheitlichen Betriebsmodell.

Souveränität für Industrie-IP

Industrie-IP — Konstruktionsdaten, Rezepturen, Prozessspezifikationen — stellt höhere Anforderungen an die Souveränität als typische Unternehmensdaten. Die architektonische Antwort ist eine Air-Gap-fähige Plattform mit optionaler Volume-Verschlüsselung, deren Passphrase das Unternehmen selbst verwaltet.

NIS2-Compliance

Die Herstellung kritischer Produkte (Medizinprodukte, Computer, elektronische Geräte, Maschinen, Kraftfahrzeuge) fällt in den Anwendungsbereich von NIS2. Die architektonischen Folgen sind dieselben wie bei NIS2 allgemein — siehe NIS2-Compliance.

Regionale und spezialisierte Clouds erleben 2026 einen Aufschwung. Die Ökonomie der Hyperscaler, der Druck in Richtung Souveränität und die Marktdynamik nach der Broadcom-Übernahme haben Raum für Cloud-Produkte jenseits der Hyperscaler geschaffen, deren Start vor fünf Jahren noch keinen Sinn ergeben hätte. Sichtbare Beispiele sind souveräne Cloud-Produkte regionaler Anbieter in der EU, in Zentralasien und im MENA-Raum. Viele weitere befinden sich noch im Stealth-Modus oder in einem frühen Stadium.

Warum gerade jetzt

Drei voneinander unabhängige Entwicklungen begünstigen den Start neuer Cloud-Produkte:

Die Hyperscaler-Ökonomie trägt für manche Workloads nicht mehr. Dauerhafte Inference, Workloads mit hohem Egress und regulierte Workloads werden auf Hyperscalern im Vergleich zu dedizierter Infrastruktur immer teurer. Eine regionale Cloud, die genau diese Workloads bedient, hat Vorteile bei den Stückkosten.

Souveränität als Wettbewerbsvorteil. EU-Mitgliedstaaten, Kasachstan und mehrere Rechtsräume im APAC-Raum haben ausdrückliche Vorgaben für souveräne Clouds. Regionale Anbieter, die diese Vorgaben erfüllen, verfügen über einen regulatorischen Burggraben, zu dem Hyperscaler keinen Zugang haben.

Umbruch am Virtualisierungsmarkt nach Broadcom. Workloads, die im Zuge des VMware-Ausstiegs umziehen, müssen irgendwo landen; regionale Anbieter können einen Teil davon aufnehmen, sofern sie das richtige Produkt liefern.

Die sechs Schichten eines Cloud-Produkts

Ein funktionierendes Cloud-Produkt für Endkunden besteht aus sechs Schichten, und jede davon erfordert Engineering:

1. Hardware

Compute-Server, Storage, Netzwerk-Fabric, Rechenzentrum / Colocation. Dimensioniert für die erste Kundenkohorte plus Reserven für Wachstum.

2. Plattform

Eine mandantenfähige, Kubernetes-native Plattform mit KubeVirt für VMs, Cilium und Kube-OVN für das Networking sowie LINSTOR (per DRBD replizierter Block Storage) für Storage. Cozystack ist die Open-Source-Standardlösung für dieses Muster.

3. Servicekatalog

Was Kunden selbst bereitstellen können: VMs, K8s-Cluster, verwaltete Datenbanken (PostgreSQL, MariaDB, MongoDB, Redis, Valkey, Kafka, ClickHouse, OpenSearch usw.), S3-Buckets, GPU-Instanzen, Netzwerk-Grundbausteine.

4. Kundenportal

Self-Service-Oberfläche (Cozystack Dashboard oder eine Eigenentwicklung). Katalog durchsuchen, Ressourcen bereitstellen, Monitoring, Transparenz über die Abrechnung.

5. Abrechnung

Produktionsreife WHMCS-Integration in zwei Modi — von Ænix als WHMCS-Integration ausgeliefert und nicht als Teil des Open-Source-Projekts Cozystack. Individuelle Abrechnungslösungen für bestimmte Märkte.

6. Betrieb

NOC rund um die Uhr, Kundensupport, SLA-Management, Observability pro Tenant, Incident Response.

Architekturentscheidungen, die für Public-Cloud-Produkte spezifisch sind

Ein Public-Cloud-Produkt unterscheidet sich architektonisch in mehreren Punkten von einer internen Plattform:

Die Mandantentrennung muss strikt sein. Kunden vertrauen einander nicht, und regulatorische Audits finden tatsächlich statt. Das Tenant-CRD-Muster mit starker Isolation ist notwendig, nicht optional.

Der Self-Service muss ausgereift sein. Interne Plattformen können „Fragen Sie das Plattform-Team“ als Notausgang haben. Produkte für Endkunden können das nicht.

Die Abrechnung muss vom ersten Tag an stimmen. Kunden werden die erste Rechnung anfechten; das System muss dieses Gespräch tragen können.

Observability für Kunden, nicht nur für den Betrieb. Kunden wollen ihre eigenen Metriken sehen, nicht nur SLA-Daten.

Die Compliance-Ausrichtung ist das Produkt. Souveränität, Datenresidenz und Audit-Fähigkeit sind Differenzierungsmerkmale, keine nachträglichen Ergänzungen.

Reihenfolge beim Markteintritt

Starten Sie in Kohorten:

1. Beta mit 3–5 wohlgesonnenen Kunden — beheben Sie die Ecken und Kanten, bevor zahlende Kunden sie zu sehen bekommen.
2. Eingeschränkte GA mit 10–50 Kunden — lernen Sie die Muster bei Abrechnung und Support im kleinen Maßstab kennen.
3. General Availability — Öffnung für den breiten Markt.
4. Spezialisierte Erweiterung — ergänzen Sie gezielte Services (weitere GPU-Klassen, AI-Services usw.) auf Basis der beobachteten Nachfrage.

Zeitrahmen: Die Plattform selbst ist mit dem produktisierten Installer wenige Wochen nach Bereitstellung der Hardware live. Wie schnell danach die General Availability folgt, bestimmen Beta, eingeschränkte GA und Ihre Bereitschaft in Vertrieb und Betrieb. Programme im Betreibermaßstab mit mehreren Regionen rechnen mit 3–6 Monaten Pilot und danach 9–18 Monaten bis zum vollen Multi-Region-Betrieb.

Woran der Markteintritt scheitert

Stolperstein 1: unzureichend ausgebaute Mandantenfähigkeit

„Die richtige Isolation bauen wir in v2 ein.“ Kunde Nr. 1 findet die Lücke; von dem Reputationsschaden erholt man sich nur schwer.

Stolperstein 2: Abrechnung als Nachgedanke

Die Abrechnungsintegration kommt im letzten Monat vor dem Launch. Sie funktioniert nicht, Kunden zahlen nicht, und das Eintreiben der Umsätze wird zum Projekt über mehrere Quartale.

Stolperstein 3: zu geringe Investition in den Betrieb

Die Plattform steht, das Betriebsteam ist für 50 Kunden ausgelegt — und im ersten Quartal unterschreiben 200. Die Servicequalität bricht ein.

Stolperstein 4: Hyperscaler-Architektur eins zu eins kopieren

Für Hyperscaler-Maßstab entworfen, für die tatsächliche Kundenzahl überdimensioniert. Die betriebliche Komplexität übersteigt den Umsatz.

Stolperstein 5: austauschbares Standardangebot

Ein generisches Cloud-Produkt ohne Abgrenzung zum Hyperscaler. Kunden greifen dann standardmäßig zu AWS / Azure / GCP. Spezialisierung, Souveränität und Regionalität zählen als Unterscheidungsmerkmal.

Das Ænix-Engagement

Ænix hat Cloud-Produkte für Endkunden durchgängig auf Cozystack aufgebaut, für Hosting-Anbieter und regionale Cloud-Betreiber. Aufbau des Engagements:

• Platform Readiness Assessment (14 oder 28 Tage, Festpreis) — inklusive Produktreife
• Aufbau — Plattform über den Installer in Wochen live; danach Portal, Abrechnung, Betriebsabläufe und Onboarding der ersten Kohorte (im Betreibermaßstab: 3–6 Monate Pilot, dann 9–18 Monate bis zum vollen Multi-Region-Betrieb)
• Phase 3 (optional) — Managed Services während der Hochlaufphase

Details finden Sie auf der Seite zu unseren Public-Cloud-Builder-Services.

Die meisten Diskussionen bei Hosting-Anbietern zur Frage „Sollen wir ein eigenes Cloud-Produkt bauen?“ enden bei der Technologie. Die schwierigere Frage sind die Unit Economics: Was kostet ein Tenant, was ist ein realistischer ARPU, wie viele Tenants braucht es bis zum Break-even, und wo versagt das Modell?

Dieser Artikel ist die Arbeitsfassung dieser Diskussion. Er setzt voraus, dass die Technologieentscheidung gefallen ist (die Cozystack-basierte Ænix Public Cloud Platform), und konzentriert sich darauf, ob die Wirtschaftlichkeit zu Ihrem Hosting-Geschäft passt — nicht zu einem abstrakten.

Was die Public Cloud Platform tatsächlich liefert

Vor der Wirtschaftlichkeit der Umfang. Die Public Cloud Platform ist ein komplettes Public-Cloud-Produkt für Hosting-Anbieter, das Ænix an Hosting-Anbieter, MSPs, regionale Clouds sowie kleine und mittlere Rechenzentren verkauft. Sie umfasst:

• Eine mandantenfähige Cozystack-Plattform auf Bare Metal unter Kontrolle des Kunden (KubeVirt + Cilium + Kube-OVN + LINSTOR + Tenant CRD).
• Cozystack Dashboard — ein Self-Service-Portal für Ihre Kunden, das sich an Ihre Hosting-Marke anpassen lässt.
• WHMCS-Integration — die Abrechnung läuft über das Kundenverwaltungssystem, das die meisten Hosting-Anbieter ohnehin betreiben.
• Servicekatalog — VMs, Tenant-Kubernetes-Cluster, Managed-Datenbanken (PostgreSQL, MariaDB, MongoDB, Redis, Valkey, Kafka, ClickHouse usw.), S3-kompatibler Object Storage, GPU-Dienste. Pro Provider kuratierbar.
• Sperren / Suspendieren von Tenants — betriebliche Hooks für Zahlungsausfälle und die Durchsetzung von Richtlinien.
• Migrations-Tooling — produktisierte Muster für die Quellen VMware, OpenStack, Virtuozzo und Proxmox.

Was sie nicht ist: ein Hyperscaler. Sie ist ein souveränes, mandantenfähiges Cloud-Produkt für Hosting-Anbieter, die über regionale Präsenz, Souveränität und Preisflexibilität konkurrieren wollen — nicht über die Katalogtiefe eines Hyperscalers.

Preismodell

Subskriptionen der Public Cloud Platform nutzen die veröffentlichten Support-Stufen, berechnet pro 10 physische Nodes und Monat bei jährlicher Abrechnung: Basic 1.250 $, Standard 3.000 $, Plus 5.500 $; Enterprise wird individuell angeboten. Höhere Stufen bringen kürzere Reaktionszeiten, unbegrenzte Incidents, Support rund um die Uhr (Plus und Enterprise) und einen breiteren Supportumfang — die vollständige Übersicht steht auf der Preisseite. Jede Support-Stufe enthält die proprietären kommerziellen Ænix-Module (Billing-System und WHMCS-Integration). Ænix rechnet nicht pro VM, pro CPU oder pro GB ab — die Cozystack-Plattform selbst ist unter Apache 2.0 kostenlos; bezahlt werden Projektarbeit, Support und betriebliche Absicherung.

Für einen typischen mittelgroßen Hosting-Anbieter mit 30–100 Nodes im Kundenbetrieb sind das zum Listenpreis 3.750–12.500 $/Monat in der Basic-Stufe oder 9.000–30.000 $/Monat in der Standard-Stufe. Vergleichen Sie das mit den wiederkehrenden Lizenz- und Subskriptionskosten, die Sie heute an VMware oder an einen Anbieter von OpenStack-Distributionen zahlen.

Unit Economics — die Sicht pro Tenant

Die Frage, die jeder CFO eines Hosting-Anbieters stellt: Was kostet es uns, einen Tenant zu bedienen, und was können wir realistisch dafür verlangen?

Kosten pro Tenant

Die Infrastrukturkosten pro Tenant werden von Compute, Storage und Bandbreite darunter bestimmt, nicht von Cozystack selbst. Der Overhead von Cozystack liegt bei ~5–10 % der Node-Kapazität (typischer Overhead einer Kubernetes-Plattform, für die Produktion gut vertretbar). Für einen Tenant mit ungefähr folgendem Verbrauch:

• 2 vCPU
• 4 GB RAM
• 50 GB Blockspeicher (3-fach repliziert)
• 100 GB Egress pro Monat

liegen die direkten Infrastrukturkosten (abgeschriebene Hardware + Colocation + Bandbreite) nach europäischem Preisniveau 2026 typischerweise bei 15–30 €/Monat. Die anteiligen Kosten der Cozystack-Plattform (das Gehalt des Plattformteams, verteilt auf alle Tenants) kommen bei einem mittelgroßen Provider mit 500 Tenants mit weiteren 5–10 € hinzu.

Damit liegen die Gesamtkosten pro typischem Tenant bei 20–40 €/Monat am unteren Ende des Ressourcenverbrauchs.

Was Sie verlangen können

Der ARPU von Hosting-Anbietern für ein vergleichbares Ressourcenprofil liegt 2026 in EU-Märkten typischerweise bei 40–80 €/Monat. Höher in der DACH-Region und in Westeuropa, niedriger in Mittel- und Osteuropa sowie in Zentralasien. Mit Managed Services (Managed PostgreSQL, Managed S3, GPU-Zugang) steigt der ARPU auf 80–200+ €/Monat pro Tenant.

Damit liegt die Marge am unteren Ende bei etwa dem 2- bis 3-Fachen der Kosten, bei Tenants mit vielen Managed Services bei dem 4- bis 6-Fachen. Keine Hyperscaler-Margen, aber auch keine Margen eines VMware-Resellers. Eher klassische Hosting-Margen in der Realität von 2026 nach Broadcom.

Break-even-Rechnung

Die andere Frage des CFO: Wie viele Kunden brauchen wir, bis wir Geld verdienen?

Die Fixkosten eines mittelgroßen Hosting-Anbieters auf der Public Cloud Platform:

Fixkosten gesamt pro Monat: 44–85 Tsd. € plus 15 Tsd. $ für den Ænix-Support.

Die Tabelle rechnet mit einem vollständigen eigenen Team für Produkt, Plattform und Kundensupport. Der reine Plattformbetrieb ist kleiner: Der ISP-Rechner setzt dafür etwa 1,3 Vollzeit-Engineers bei 10 Nodes und etwa 2,6 bei 40 Nodes an.

Bei 25–50 €/Monat Marge pro Tenant (40–80 € ARPU nach 15–30 € direkten Infrastrukturkosten) liegt der Break-even je nach ARPU-Mix und Gehaltsniveau bei etwa 1.200–4.000 zahlenden Tenants. Das ist der Fall eines vollständigen Programms mit eigenem Team; ein Start mit 10 Nodes in der Basic-Stufe und vorhandenem Personal erreicht den Break-even deutlich früher — rechnen Sie Ihre eigenen Zahlen im ISP-Rechner durch.

Für Provider, die heute ~500 Kunden auf Legacy-Infrastruktur betreiben und den Wechsel prüfen, ist das entscheidend: Sie brauchen einen glaubwürdigen Weg, die Zahl der Tenants innerhalb von 18–24 Monaten mindestens zu verdoppeln, damit die Rechnung tatsächlich aufgeht. Ohne Wachstum ist die Public Cloud Platform eine (moderate) Kostensenkung, aber keine Transformation.

Für Provider mit weniger als ~300 Kunden ist ein vollständiges Programm mit eigenem Plattformteam von 3–5 Personen oft verfrüht — diese Fixkosten erdrücken den Deckungsbeitrag. Ein kleinerer Start (10 Nodes in der Basic-Stufe, ein schmaler Katalog, vorhandenes Personal) ist meist der bessere erste Schritt. Das sagen wir im Discovery Call offen, statt ein größeres Projekt voranzutreiben.

Wo das Modell versagt

Drei Fehlermuster wiederholen sich:

1. Zu geringe Investitionen in das Kundenportal

Hosting-Anbieter konkurrieren traditionell über Preis und Zuverlässigkeit. Das Cozystack Dashboard ist ab Werk funktional, aber generisch; Differenzierung entsteht durch Feinschliff (UX-Abläufe, die dazu passen, wie Ihre Kunden bestellen, konfigurieren und bezahlen). Provider, die das Portal als „gut genug“ behandeln, verlieren Conversion an Provider, die darin investieren.

Das Ænix-Projekt umfasst die Anpassung des Cozystack Dashboards an Ihre Marke; tiefere UX-Arbeit ist in der Regel eine separate Phase 2.

2. Servicekatalog passt nicht zum Kundenstamm

Cozystack bietet 20+ Managed Services; nicht alle passen zum Kundenstamm jedes Providers. Wer alle anbietet, ohne sie betrieblich abzusichern, erlebt Kunden, die Kafka oder ClickHouse bestellen und feststellen, dass der Provider sie nicht wirklich unterstützen kann. Kuratieren Sie den Katalog auf das, was Sie mit dem versprochenen SLA tatsächlich betreiben können. Die Einführung der Dienste in Kohorten ist das Standardvorgehen.

3. Ein Betriebsteam, das für das Wachstum unterbesetzt ist

Das größte einzelne Fehlermuster in unserer Pipeline: Die Public Cloud Platform ist ausgerollt, startet erfolgreich, gewinnt im ersten Quartal 200 Kunden — und dann skaliert das Betriebsteam mit 4 Personen, das bei 50 Kunden funktioniert hat, nicht mehr. Die Reaktionszeiten im Kundensupport verschlechtern sich, SLA-Verletzungen häufen sich, die Abwanderung steigt.

Planen Sie die Größe des Betriebsteams für die Kundenzahl in 18 Monaten, nicht für die heutige. Stellen Sie vorausschauend ein.

Die Public Cloud Platform im Vergleich zu den Alternativen für Hosting-Anbieter

Im Vergleich zu VMware Cloud Director (vCD):

vCD ist der historisch etablierte Platzhirsch bei Hosting-Anbietern. Nach Broadcom hat die Abo-Preisgestaltung die Rechnung verändert — Steigerungen um das 2- bis 5-Fache bei der Verlängerung, verpflichtende VCF-Bündelung, Ende der Dauerlizenzen. Für die meisten Provider, die heute vCD betreiben, ist der Verlängerungszyklus der Auslöser. Die Ænix Public Cloud Platform ist wenige Wochen nach Bereitstellung der Hardware live; der Umzug eines bestehenden vCD-Bestands ist ein eigenes Migrationsprojekt, dessen Umfang das Assessment je nach Bestand festlegt.

Im Vergleich zu OpenStack:

OpenStack bleibt eine valide Option für Provider mit tiefer OpenStack-Expertise und großen Deployments (>500 Nodes), bei denen sich die betriebliche Komplexität amortisiert. Für mittelgroße Provider übersteigt der betriebliche Footprint von OpenStack (50+ Dienste, eigene Upgrade-Lebenszyklen pro Komponente), was das Team stemmen kann. Die Public Cloud Platform hat eine deutlich kleinere Betriebsfläche.

Im Vergleich zum Eigenbau auf Vanilla Kubernetes + KubeVirt + Helm:

Das ist die glaubwürdige Alternative für Provider mit starker Platform-Engineering-Kapazität. Der Preis: 12–24 Monate Bauzeit plus laufende Wartung gegenüber einem schlüsselfertigen Deployment. Wir haben beides funktionieren sehen; der Eigenbau ist die richtige Wahl, wenn Sie ein Plattformteam mit 10+ Engineers haben und die Komponenten Ihren konkreten betrieblichen Vorlieben entsprechen. Für den typischen mittelgroßen Provider mit einem Plattformteam von 3–5 Engineers gewinnt die Public Cloud Platform bei Time-to-Market und betrieblicher Planbarkeit.

Im Vergleich zu einem hyperscaler-verwalteten Cloud-Produkt (White Label):

Hyperscaler (AWS, Azure, GCP) bieten Hosting-Partnern mitunter White-Label- oder Co-Branding-Modelle für Cloud-Angebote an. Der Preis: geringere betriebliche Komplexität für den Provider, aber in der Regel eine niedrigere Marge pro Kunde und eine schwächere Souveränitätspositionierung (der Provider bleibt vom Hyperscaler abhängig, was europäische Kunden zunehmend als strukturelles Risiko sehen).

Wann die Public Cloud Platform die richtige Antwort ist

Sie passt, wenn mindestens drei der folgenden Punkte zutreffen:

1. Sie betreiben heute Bare Metal oder einen kommerziellen Hypervisor mit wiederkehrendem Lizenzdruck — VMware, OpenStack, Virtuozzo oder eine kommerzielle KVM-Distribution.
2. Sie haben direkte Kundenbeziehungen, die Sie monetarisieren können — Sie sind nicht nur Wiederverkäufer der Cloud eines anderen.
3. Sie haben ein Plattformteam von 3–5 Engineers oder können es aufbauen — Cozystack braucht klare betriebliche Verantwortung.
4. Sie zielen auf regionale, regulierte oder souveränitätssensible Kunden — bei denen eine europäische, EU-basierte Positionierung zählt.
5. Sie haben heute 300+ Kunden oder einen glaubwürdigen Wachstumspfad zu 1.000+ — damit sich die Fixkosten amortisieren.
6. Sie sind bereit, in den Feinschliff des Kundenportals zu investieren — statt das Cozystack Dashboard als „gut genug“ zu behandeln.

Weniger als drei: Meist ist eine andere Antwort besser — auf der bestehenden Infrastruktur bleiben und die Kosten optimieren, als Kanal mit einem größeren souveränen Provider zusammenarbeiten oder als Weg mit geringerer Marge ein hyperscaler-verwaltetes Cloud-Produkt wählen.

Ablauf der Zusammenarbeit

Für Provider, zu denen die Public Cloud Platform passt:

• Discovery Call (30 Min., kostenlos)
• Platform Readiness Assessment (Festpreis, 14 Tage fokussiert oder 28 Tage vollständig) — Inventar des aktuellen Bestands, Zielarchitektur, Migrationsplan
• Plattform live und Pilotkohorte — die Plattform ist mit dem produktisierten Installer in wenigen Wochen auf Ihrer Hardware live; Migration von 5–10 wohlgesonnenen Kunden, Validierung der Abrechnung
• Limited GA (2–4 Monate) — 50–100 Kunden, stabilisierte Betriebsabläufe
• General Availability — Start am offenen Markt
• Support-Subskription (fortlaufend) — eine der veröffentlichten Stufen; Plus oder Enterprise für Abdeckung rund um die Uhr

Wie lange der kommerzielle Start nach dem Go-live der Plattform dauert, hängt vom Migrationsumfang und der Bereitschaft des Teams ab. Programme im nationalen oder Betreibermaßstab mit mehreren Regionen rechnen mit 3–6 Monaten Pilot und danach 9–18 Monaten bis zum vollen Multi-Region-Betrieb.

Weiterführende Inhalte

• Landingpage Public Cloud Platform — Funktionsübersicht, Preisblock, FAQ
• Branchenseite Hosting-Anbieter — Positionierung speziell für Hosting-Anbieter
• White-Label-Cloud-Leistungen — für Erweiterungen des Modells durch MSPs und Channel-Partner

Das Kürzel „IDP“ ist mehrfach belegt. Es steht für beides:

• Internal Developer Platform — den zugrunde liegenden Capability-Stack (Kubernetes, IaC, Observability, Golden Paths).
• Internal Developer Portal — die UI-/Katalogebene (Backstage, Port, Eigenbau).

Die meisten Diskussionen werfen beides durcheinander. Die eigentliche Frage — „Brauchen wir Backstage?“ — hat unterschiedliche Antworten, je nachdem, von welcher IDP die Rede ist.

Plattform vs. Portal

Eine Plattform ohne Portal funktioniert trotzdem. Ein Portal ohne Plattform ist Tapete.

Die Plattform beantwortet: „Welche Fähigkeiten können Produktteams per Self-Service nutzen?“

• Bereitstellung von Umgebungen
• Anwendungs-Deployment
• Bereitstellung von Datenbanken, Queues und Caches
• Onboarding in die Observability
• Secrets, Identity, Netzwerkzugang

Das Portal beantwortet: „Wie finden Produktteams diese Fähigkeiten und wie greifen sie darauf zu?“

• Servicekatalog
• Einstiegspunkt in die Dokumentation
• Self-Service-Formulare und -Aktionen
• Kosten- und SLO-Dashboards pro Service

Ohne Plattform funktioniert Self-Service nicht. Das Portal wird für die Auffindbarkeit gebraucht, sobald die Zahl der Services über das hinauswächst, was Teams im Kopf behalten können.

Wann Sie ein Portal brauchen

Ein Portal wird wertvoll, wenn:

• die Zahl der Services groß ist — 50+ Services, bei denen Engineers den Überblick verlieren.
• das Team groß ist — viele Engineers, von denen sich viele auf der Plattform noch nicht sicher bewegen.
• teamübergreifende Service-Discovery real ist — Engineers aus Team A nutzen Services von Team B.
• Compliance oder Audit einen Servicekatalog verlangen — ein Serviceinventar, das der Aufsicht standhält.

Trifft nichts davon zu (kleine Organisation, wenige Services, routiniertes Plattformteam), verursacht ein Portal Wartungsaufwand ohne nennenswerten Nutzen.

Portal-Optionen im Vergleich

Backstage (CNCF Incubating)

Was: Open-Source-Servicekatalog plus Plugin-Ökosystem. Ursprünglich von Spotify entwickelt, heute bei der CNCF.

Stärken: Ausgereift, breites Plugin-Ökosystem, anpassbar, starke Community.

Schwächen: Die Betriebskosten sind real — Backstage zu betreiben heißt, Plugins zu pflegen, interne Tools anzubinden und mit dem Release-Rhythmus von Backstage Schritt zu halten. Viele Anwender unterschätzen das.

Am besten für: Mittlere bis große Engineering-Organisationen (200+ Engineers) mit genug Kapazität im Plattformteam, um Backstage als Produkt zu pflegen.

Port (port.io)

Was: SaaS-Internal-Developer-Portal.

Stärken: Kein Selbstbetrieb; schneller ausgerollt als Backstage; mit klaren Vorgaben.

Schwächen: Abhängigkeit von SaaS (mit Folgen für die Souveränität); weniger anpassbar als Backstage.

Am besten für: Mittelgroße Organisationen, die SaaS nutzen wollen und sich die Betriebskosten von Backstage sparen möchten.

Cortex / Compass / Eigenbauvarianten

Verwandte Optionen mit anderen Abwägungen. Cortex konzentriert sich auf Engineering-Effektivität; Compass ist Atlassian-nativ; Eigenbau heißt „selbst bauen“.

Kein Portal

Was: IaC-Repository plus Markdown-Dokumentation plus GitOps-Schnittstelle.

Stärken: Keine Betriebskosten über Git hinaus. Kein portalspezifischer Wartungsaufwand.

Schwächen: Die Auffindbarkeit skaliert ab 30–50 Services schlecht.

Am besten für: Kleinere Organisationen (unter ~100 Engineers), in denen die Kosten eines Portals seinen Nutzen übersteigen würden.

Wo Backstage tatsächlich am besten passt

Backstage funktioniert gut, wenn:

• es 200+ Engineers und 100+ Services gibt
• das Plattformteam 5+ Engineers hat, die Zeit für die Pflege aufbringen können
• das Plugin-Ökosystem zu Ihrem Tooling passt
• Anpassbarkeit eine Priorität ist (Sie werden Plugins schreiben oder erweitern)

Trifft das nicht zu, übersteigen die Betriebskosten den Nutzen, und eine leichtgewichtigere Option passt besser.

CNOE — die Open-Source-Referenz für Platform Engineering

Die Brancheninitiative CNOE (Cloud Native Operational Excellence) verdient Erwähnung. Es ist eine Referenzarchitektur mit klaren Vorgaben, die Backstage, Argo CD, Crossplane, External Secrets und weitere CNCF-Tools zu einem stimmigen Plattformmuster verbindet. Für Organisationen, die eine „Plattform aus der Box“ aus CNCF-Projekten wollen, ist CNOE der strukturierte Ausgangspunkt.

CNOE ergänzt Cozystack: CNOE konzentriert sich auf das Developer Portal und die Tooling-Ebene; Cozystack auf die darunterliegende mandantenfähige, Kubernetes-native Plattform mit Virtualisierung. Beide können nebeneinander bestehen.

Wie Sie entscheiden

Ein praktischer Entscheidungsbaum:

1. Haben Sie darunter eine funktionierende Plattform? Wenn nein, bauen Sie zuerst diese. Die Adoption eines Portals setzt voraus, dass es eine Plattform gibt.
2. Mehr als 50 Services? Mehr als 100 Engineers? Wenn ja, hilft ein Portal. Wenn nein, ist ein Portal Over-Engineering.
3. Sind die Betriebskosten von Backstage realistisch tragbar? Wenn ja (großes Team, Plugin-freundliche Kultur), Backstage. Wenn nein, Port oder Cortex.
4. Ist SaaS akzeptabel? Wenn ja, Port oder Cortex. Wenn nein, Backstage oder Eigenbau.
5. Werden Sie tatsächlich anpassen? Wenn ja, Backstage. Wenn nein, Port.

Die Entscheidung ist kleiner, als Hersteller sie darstellen. Die größere Architekturentscheidung ist die Plattform darunter.

Die Diskussion „Sollen wir in ein Plattformteam investieren?“ bleibt meist an einer von zwei Stellen hängen: Entweder sieht der CFO den wirtschaftlichen Fall nicht („Wir bezahlen doch schon DevOps-Engineers, warum noch mehr Stellen?“), oder die Engineering-Organisation hat einmal Backstage als Plattform ausprobiert, fand es oberflächlich und hat das Vertrauen in die ganze Kategorie verloren.

Dieser Artikel geht beides durch. Wie sehen die Kosten der Reibungsverluste in der Entwicklung in Zahlen tatsächlich aus? Was liefert eine IDP, die funktioniert? Und was übernimmt die Developer-Self-Service-Schicht der Ænix Private Cloud Platform, das Sie sonst selbst bauen müssten?

Was Reibungsverluste in der Entwicklung kosten

Der beständigste Befund aus unseren Platform-Readiness-Assessments in Organisationen ab 200 Engineers lautet: Die Bereitstellung einer Umgebung dauert 2–6 Wochen für etwas, das eine Self-Service-Aktion von 30 Minuten sein sollte.

Wohin geht die Zeit? Typischerweise:

• IAM: ein Ticket an das Security-Team, 2–5 Tage
• Netzwerkanbindung: ein Ticket an das Network Engineering, 3–7 Tage
• Onboarding in die Observability: ad hoc, oft erst spät als fehlend bemerkt
• Compliance-Review: 1–3 Tage, bei regulierten Daten manchmal länger
• Freigabekette: 2–4 Tage, in Matrixorganisationen gelegentlich länger

Jeder Schritt erfordert eine Übergabe, das heißt Kontextverlust, das heißt erneute Abstimmung, das heißt mehr Zeit. Die einzelnen Schritte sind klein; die kumulierte Reibung ist groß.

Bei 5 % der Engineering-Produktivität (grobe Schätzung aus unseren Projekten in der Größenordnung von 200 Engineers und 2–6 Wochen bis zur Umgebung) kosten die Reibungsverluste eine Organisation mit 200 Engineers rund 10 Engineers an verlorenem Durchsatz pro Jahr — etwa 1,5–2 Mio. € bei voll belasteten Kostensätzen. Wer die Bereitstellung von Umgebungen auf Stunden verkürzt, holt den Großteil davon zurück.

Die Investition in eine Internal Developer Platform, die diese Verkürzung leistet, amortisiert sich bei Organisationen dieser Größe typischerweise innerhalb von 12 Monaten.

Was eine „Plattform, die funktioniert“ tatsächlich liefert

Für eine glaubwürdige IDP zählen fünf Merkmale mehr als die Wahl der Tools:

1. Schneller als die Alternative per Ticket

Dauert der Self-Service 2 Tage und ein Ticket 3 Tage, nehmen Teams das Ticket — Warten ist bequemer als Lernen. Die Plattform muss deutlich schneller sein, damit die Adoption kippt.

2. Verlässlich genug, um ihm zu vertrauen

Der Self-Service-Pfad funktioniert für den dokumentierten Anwendungsfall beim ersten Mal und jedes Mal. Bricht er in einem von zehn Fällen, verlieren Teams das Vertrauen. Die Adoption stockt.

3. Auf höchstens einer Seite dokumentiert

Ist die Dokumentation länger als eine Seite, ist die Architektur zu komplex. Echte Golden Paths sind von vornherein einfach.

4. Im Besitz eines echten Teams

Ein Team pflegt den Pfad, fängt Sonderfälle auf und liefert Verbesserungen aus. Ohne klare Verantwortung verfallen Pfade. Die Platform-Engineering-Funktion muss eine Funktion sein, kein Hobby.

5. Mit Ausweichmöglichkeiten

Produktteams können abweichen, wenn ihr Fall besonders ist. Die Ausweichmöglichkeit ist ein echtes Gespräch mit dem Plattformteam, nicht „Nutzen Sie den Pfad oder scheitern Sie“.

Was Developer Self-Service mitbringt

Die Developer-Self-Service-Schicht der Ænix Private Cloud Platform macht diese Merkmale auf dem Fundament von Cozystack zum Produkt. Konkret:

Eine mandantenfähige Cozystack-Plattform mit Tenant CRD

Jedes Produktteam bekommt einen Tenant — ein Kubernetes-natives Objekt mit eigenem Namespace, eigener Quota, eigenem RBAC und eigenem Observability-Bereich. Isolation pro Tenant ohne den Overhead eines Clusters pro Team. Verschachtelte Tenants bilden Hierarchien von Geschäftsbereichen ab.

Damit löst sich das Trilemma „Weiche Mandantenfähigkeit ist zu durchlässig, ein Cluster pro Team ist im Betrieb zu teuer“ ohne Kompromiss.

Ein Cozystack Dashboard, das von den Golden Paths her gedacht ist

Das Cozystack Dashboard in Developer Self-Service bietet klar vorgegebene Pfade für die 5–10 häufigsten Bedürfnisse von Produktteams: Bereitstellung von Umgebungen, Anwendungs-Deployment, Bereitstellung von Managed-Datenbanken, Onboarding in die Observability, Secrets-Management. Jeder Pfad ist in Minuten abgeschlossen.

Kuratiert, nicht erschöpfend — das, was Ihr Plattformteam tatsächlich mit Support absichern kann, nicht jede Fähigkeit von Cozystack.

GitOps-Automatisierung

Argo CD und Argo Workflows sind in die Plattform vorintegriert. GitLab-Integration für das in Unternehmen verbreitetste SCM. Produktteams committen IaC, die Plattform reagiert. Kein Herumklicken für Änderungen an der Produktion.

Vorgefertigte Service-Templates

Standard-Service-Templates (HTTP-API, Batch-Worker, geplanter Job) mit eingebauter Observability, Deployment und Alerting. Ein neuer Dienst ist eine Instanz eines Templates. Die Zeit bis zum ersten Produktions-Deployment beträgt Stunden, nicht Wochen.

Interne Produktmanagement-Disziplin eingebaut

Das Plattformteam wird als Funktion behandelt, deren Kunden die Produktteams sind. Ein Developer-Self-Service-Projekt umfasst eine RACI-Matrix für das Plattformteam, interne NPS-Kennzahlen, Vorlagen für Abkündigungsrichtlinien und Muster für das Roadmap-Management. Gerade diese Disziplin ist oft das fehlende Stück.

Was in der Verantwortung des Kunden bleibt

Developer Self-Service ist das Plattformsubstrat plus die betriebliche Disziplin. Einiges bleibt bei Ihnen:

• Die Definition Ihrer konkreten Golden Paths — welche 5–10 Sie zuerst bauen, hängt davon ab, was Ihre Produktteams tatsächlich am häufigsten anfragen.
• Die Größe des Platform-Engineering-Teams — das typische reife Verhältnis ist 1 Platform Engineer pro 10–20 Produkt-Engineers; wir empfehlen, vor dem Bedarf einzustellen.
• Die Adoption — eine großartige Plattform, die niemand nutzt, ist versenktes Kapital. Produktmanagement-Praktiken im Plattformteam (Interviews mit Produktteams, Messung der Adoption pro Pfad, Einstellen ungenutzter Pfade) müssen gelebt werden.

Das Projektmodell von Ænix unterstützt alle drei Punkte, ersetzt aber nicht die Verantwortung des Kunden. Plattformen, für die der Kunde organisatorisch keine Verantwortung übernimmt, überdauern das Projekt nicht.

Der wirtschaftliche Fall im Vergleich zu den Alternativen

Im Vergleich zu reinem DevOps

DevOps ohne eigenes Platform Engineering skaliert linear mit der Zahl der Teams — jedes Produktteam löst Infrastruktur, Observability, Identity und Release Engineering für sich. Ab etwa 50 Engineers frisst die Doppelarbeit die Einsparungen auf. Ab etwa 200 Engineers wird sie zur betrieblichen Bremse.

Developer Self-Service verändert das Modell: Platform Engineering wächst sublinear mit der Zahl der Teams. Das 21. Produktteam bringt nicht den Plattform-Overhead eines 21. Teams mit — die bestehende Plattform nimmt es auf.

Im Vergleich zum Eigenbau auf Vanilla Kubernetes plus Backstage

Für Organisationen mit starker Platform-Engineering-Kapazität und klaren architektonischen Vorstellungen ist das eine glaubwürdige Alternative. Der Preis: 12–24 Monate Bauzeit, bis die Plattform für Produktteams „produktionsreif“ ist, plus laufender Wartungsaufwand für die Plattformkomponenten.

Developer Self-Service auf der Ænix Private Cloud Platform liefert das Plattformsubstrat in 3–6 Monaten, mit laufendem Support durch Ænix. Für Organisationen, die nicht für einen Aufbau über 12–24 Monate besetzt sind, entscheidet das darüber, ob Platform Engineering in diesem Jahr stattfindet oder 2028.

Im Vergleich zum Backstage-als-Plattform-Antipattern

Backstage ist ein Portal, keine Plattform. Wer Backstage kauft, bevor die zugrunde liegenden Fähigkeiten als Self-Service verfügbar sind, bekommt einen schönen Katalog über demselben betrieblichen Chaos. Die Adoption stockt.

Das Cozystack Dashboard von Developer Self-Service lässt sich durch Backstage ersetzen oder ergänzen, wenn der Kunde das bevorzugt — aber die zugrunde liegenden Fähigkeiten (Bereitstellung von Umgebungen, Observability, Secrets, Identity) sind Self-Service, weil die Plattform es ist, und nicht, weil das Portal es vorgibt.

Im Vergleich zu hyperscaler-verwaltetem Kubernetes (EKS / AKS / GKE)

Von Hyperscalern verwaltetes Kubernetes ist im Betrieb einfacher als selbst verwaltete Cluster. Der Preis: Vendor-Lock-in (die Control Plane gehört dem Anbieter; Sie können sie anderswo nicht exakt nachbilden), eine Kostendecke (Hyperscaler-Ökonomie bei dauerhaften Workloads) und Folgen für die Souveränität.

Developer Self-Service passt, wenn die Abwägungen bei Kosten oder Souveränität den betrieblichen Aufwand des Selbstbetriebs rechtfertigen. Für Unternehmen in einer frühen Phase ohne Souveränitätsdruck ist hyperscaler-verwaltetes Kubernetes nach wie vor die richtige Wahl.

Wann Developer Self-Service die richtige Antwort ist

Gute Passung:

• 200+ Engineers in 5+ Produktteams
• Die Bereitstellung einer Umgebung dauert heute 2–6 Wochen; Ziel sind Stunden
• Das bestehende Plattformteam ertrinkt in Tickets, statt Pfade zu bauen
• Mandantenisolation ist wichtig (regulierte Daten, Trennung von Geschäftsbereichen oder Service-Provider-Modell)
• Die Investition in Platform Engineering wird von der Engineering-Leitung getragen

Bedingte Passung:

• 100–200 Engineers mit wachsenden Plattformproblemen, aber begrenztem Budget; mit Cozystack Enterprise Support starten und mit dem Team in die Ænix Private Cloud Platform hineinwachsen
• Eine starke bestehende Eigenentwicklung mit konkreten Lücken — ein Teilprojekt passt hier eventuell besser als vollständiges Developer Self-Service

Schlechte Passung:

• Weniger als 50 Engineers, ein einziges Produktteam; hier ist reines DevOps richtig
• Hyperscaler-verwaltetes Kubernetes erfüllt alle Anforderungen; Souveränität spielt keine Rolle

Ablauf der Zusammenarbeit

• Discovery Call (30 Min., kostenlos) — Prüfung der Passung
• Platform Readiness Assessment (14 oder 28 Tage, Schwerpunkt auf dem IDP-Arbeitspaket) — heutige Zeit bis zur Umgebung, Reifegrad, empfohlene Golden Paths
• Pilot-Deployment (3–6 Monate) — Cozystack-Plattform plus 3–5 Golden Paths plus Onboarding von 2–3 Pilot-Produktteams
• Vollständiger Aufbau von Developer Self-Service (3–12 Monate je nach Umfang) — die Plattform wird auf die gesamte Engineering-Organisation ausgeweitet, alle geplanten Golden Paths sind ausgeliefert
• Managed Retainer (optional, fortlaufend) — Support der Plus- oder Enterprise-Stufe unter SLA (siehe Preise)

Projektumfang: Projekt plus Managed Retainer, Angebot pro Ausschreibung (RFP).

Weiterführende Inhalte

• Ænix Private Cloud Platform mit Developer Self-Service — Funktionsübersicht, produktspezifisches FAQ
• Leistungen rund um die Internal Developer Platform — Details zum Projekt
• Leistungen für Platform Engineering — breiterer Umfang
• Lösungen für Developer Self-Service — die Landingpage aus Sicht des Einkäufers
• Internal Developer Platform Beispiele — 6 Muster — die sechs IDP-Muster aus der Produktion
• Internal Developer Portal vs. Plattform — der Platz von Backstage im Jahr 2026

Sie liefern einem Tenant einen Managed-Postgres- oder ClickHouse-Cluster in zwei Minuten aus. Jetzt müssen Sie abrechnen — minutengenau, aufgeschlüsselt nach CPU, Memory und Speicher, cent-genau abstimmbar. AWS RDS kann das. GCP kann das. Auf eigener Hardware? Bisher: ein eigenes Prometheus-Skript, ein monatlicher Tabellen-Export und ein Vertriebsgespräch, das erklärt, „warum die Zahl so groß ist“. Ænix Billing schließt diese Lücke.

Was Ænix Billing ist

Ein nativer Kubernetes-Extension-API-Server, der die billing.aenix.io/v1alpha1-API bereitstellt. Sie fragen ihn genauso ab wie die reguläre Kubernetes-API — mit kubectl, kubeconfig-RBAC, Ihrem bestehenden Tooling — und erhalten einen strukturierten UsageReport für jeden Tenant, jeden Workload, jedes Zeitfenster.

Unter der Haube:

• Cozystack Workload CRD — jeder Managed-Service (Postgres Primary, Redis Sentinel, ClickHouse Shard, KubeVirt-VM, Kubernetes-Worker, S3-Bucket) ist ein Workload-Objekt.
• Billing-Controller — wandelt Workload-State in Prometheus-Metriken um: operative Lebensdauer, Owner-Tenant, Kind/Typ, Ressourcenreservierungen.
• VictoriaMetrics — speichert Metriken mit Stream-Aggregation. (Ænix und Cozystack standardisieren auf VictoriaMetrics + VictoriaLogs, nicht Prometheus/Loki.)
• Billing-API-Server — bedient die API und berechnet das bestimmte Integral der Reservierungen über das angefragte Zeitfenster.

Die Form: ein schlanker Extension-API-Server, ein kleiner Controller, Ihr bestehender Metrics-Store. Keine neue Abhängigkeit zu betreiben. Ihr Plattform-Team betreibt all diese Komponenten bereits.

Was abgerechnet wird

Jeder Consumer (ein einzelner Postgres-Pod, eine Redis-Instanz, eine ClickHouse-Replica) wird gemeldet mit:

• vCPUHours oder CPUHours — umschaltbar, je nachdem ob Sie physische oder virtualisierte CPU abrechnen
• MemoryGiBHours (oder dezimal MemoryGBHours)
• EphemeralStorageGiBHours
• PersistentVolumeGBHours — aufgeschlüsselt nach Storage-Class (NVMe vs HDD vs repliziert)
• IPAddressHours — abgeleitet aus MetalLB-IP-Pool-Labels
• LifetimeHours — reine Laufzeit, unabhängig von Reservierungen
• S3StorageGBHours und S3PhysicalStorageGBHours — für Object-Storage-Tenants

Workload-Metadaten reisen mit dem Report mit — kind: postgres, type: master vs. replica, der Owner-Tenant, eigene Cozystack-Labels — sodass Preisregeln so feingranular sein können wie Sie wollen. Replicas zum halben Preis von Primaries abrechnen. NVMe-Volumes 3× HDD-Volumes. Einem strategischen Tenant 20 % Rabatt geben. Die Daten sind da; die Policy ist Ihre.

Wie Sie abfragen

Ein UsageReport ist ein Kubernetes-Objekt. Sie bauen die Anfrage wie jede andere CRD:

apiVersion: billing.aenix.io/v1alpha1
kind: UsageReport
query:
  tenant: tenant-acme
  includeSubTenants: true
  startTimestamp: 2026-04-01T00:00:00Z
  endTimestamp:   2026-05-01T00:00:00Z

kubectl create -f report.yaml -o yaml

Sie erhalten dasselbe Objekt zurück mit befülltem report.consumers[] — ein Eintrag pro Postgres-Replica, Redis-Pod, ClickHouse-Shard, K8s-Worker — jeder mit eigener Verbrauchsaufschlüsselung.

• includeSubTenants: true zieht rekursiv jeden verschachtelten Tenant
• excludeTenants: filtert interne Namespaces heraus
• workload: postgres-myapp-1 schränkt auf einen einzelnen Cluster ein
• Zeitfenster auf einen Abrechnungsmonat, einen einzelnen Tag oder die Lebensdauer eines Tenants — die API akzeptiert jedes RFC3339-Intervall

Derselbe kubectl get-Mechanismus, der eine Pod-Liste zieht, zieht jetzt Tenant-Rechnungspositionen. RBAC funktioniert genauso — das Billing-Team bekommt eine kubeconfig, die auf die Billing-API beschränkt ist; mehr nicht.

Warum das für Hosting-Provider relevant ist

Sie hosten bereits Managed Postgres, Redis, Kafka, ClickHouse, S3 und Kubernetes über Cozystack. Mit Ænix Billing bekommen Sie das fehlende Stück — präzise Buchhaltung pro Tenant, pro Workload, pro Ressource, die direkt in Ihre Rechnungsstellung einfließt. Keine Tabellen. Keine quartalsweise Abstimmung. Keine „warum ist meine Rechnung so hoch“-Diskussionen mit Kunden.

Drei Dinge ändern sich für das Operations-Team:

1. Billing ist kein separates System mehr. Dieselbe API wie der Rest der Plattform. Dasselbe RBAC. Dasselbe kubectl. Nichts Neues zu lernen oder zu betreiben.
2. Reklamationen sinken. Die Rechnungspositionen mappen 1:1 auf die Ressourcen, die Cozystack tatsächlich geschedult hat. Der Kunde kann dieselbe Abfrage laufen lassen, dieselben Zahlen sehen, cent-genau abstimmen.
3. Preisexperimente sind günstig. Sie wollen A/B-testen, eine bestimmte Service-Klasse nach MemoryGiBHours statt vCPUHours abzurechnen? Nicht den Billing-Pipeline-Code ändern — die Policy ändern, die denselben Report konsumiert.

Wie es sich von AWS RDS / GCP-Abrechnung unterscheidet

AWS RDS und Cloud SQL rechnen minutengenau gegen eine Managed-Service-Preisliste ab — der Provider besitzt die Preisliste und der Kunde akzeptiert die Rechnungspositionen als verbindlich. Sie sind dieser Provider auf Cozystack. Ænix Billing liefert dieselbe Minutengenauigkeit, mit Preismodell und Ressourcen-Taxonomie unter Ihrer Kontrolle. Die Daten liegen offen, die Policy gehört Ihnen.

Für Hosting-Provider auf Bare Metal — Hetzner, OVH, regionale Rechenzentren, Sovereign-Cloud-Betreiber — ist das der Unterschied zwischen „mit Hyperscalern auf Funktion konkurrieren“ und „mit Hyperscalern nur auf Preis konkurrieren“. Die Funktion war bisher die Lücke.

Distribution

Ænix Billing ist ein proprietäres Ænix-Modul und wird zusammen mit Cozystack als Teil der kommerziellen Ænix-Plattformen ausgeliefert. Die Cozystack-Plattform bleibt Apache-2.0 und CNCF-gesteuert. Für Ænix-Kunden ist die Billing-Schicht Bestandteil der Subskription.

Wenn Sie ein Hosting-Geschäft oder eine Private Cloud auf Cozystack betreiben und Billing out of the box wollen, vereinbaren Sie einen Discovery-Call — wir besprechen Scope, Pricing und Rollout.

Community

• Cozystack — cozystack.io
• GitHub — github.com/cozystack
• Telegram — t.me/cozystack
• Kubernetes Slack — #cozystack (Einladung nötig? slack.kubernetes.io)
• Community-Meetings — Kalender

Platform Engineering bei 200–500 Engineers ist vor allem eine Frage von „gut machen“ — Golden Paths definieren, den Capability-Stack der IDP aufbauen, ein Plattformteam einstellen, ausliefern. Platform Engineering ab 1.000 Engineers ist ein anderes Problem: Governance über Geschäftsbereiche hinweg, Konsistenz ohne Starrheit, betriebliche Koordination über mehrere Regionen, Change-Management auf dem Niveau, das die Aufsicht erwartet, und die politische Dynamik geschäftsbereichsübergreifender Infrastrukturentscheidungen.

Was sich ab 1.000 Engineers ändert

Drei strukturelle Verschiebungen:

1. Mehrere Platform-Engineering-Teams

Ein einzelnes Plattformteam skaliert bis etwa 50–100 Produktteams oder 500–1.000 Produkt-Engineers. Darüber zerfällt die Plattformfunktion — nach Domäne (Datenplattform, ML-Plattform, Infrastrukturplattform), nach Geschäftsbereich (Consumer Cloud, Enterprise Cloud, interne IT) oder nach Geografie (regionale Plattformteams unter regulatorischen Vorgaben).

Die Koordination mehrerer Plattformteams wird zu einer eigenen Disziplin — Governance einer Plattform aus Plattformen, gemeinsame Standards, Eskalationswege für plattformübergreifende Entscheidungen.

2. Der Governance-Aufwand wird erheblich

Architekturentscheidungen betreffen Tausende Engineers und Millionen Euro an wiederkehrenden Kosten. Entscheidungen können nicht ad hoc fallen; sie brauchen Governance — Architecture Review Boards, Prozesse für das Technologie-Radar, Abkündigungsrichtlinien, die Übergangsfenster von 2–3 Jahren respektieren, und eine Abstimmung über die Geschäftsbereiche hinweg.

Bei 200 Engineers funktioniert „Das Plattformteam entscheidet“. Ab 1.000 Engineers erzeugt „Das Plattformteam entscheidet allein“ einen politischen Gegenwind, der die Adoption stärker bremst, als die Entscheidung Zeit spart.

3. Change-Management auf Aufsichtsniveau

Für regulierte Unternehmen (Banken, Versicherer, öffentlicher Sektor, Telekommunikation, Energie, Gesundheitswesen) laufen Plattformen im Enterprise-Maßstab unter einem prüfungsfesten Change-Management. Produktionsänderungen durchlaufen eine dokumentierte Freigabe, sind aus Artefakten reproduzierbar und erzeugen Nachweise, die die Aufsicht verwerten kann.

Die Plattform selbst wird zu einem aufsichtsrelevanten Objekt — die Kontrollen nach DORA Artikel 6 leben im Code der Plattform.

Muster für das Organisationsdesign

Drei Muster, die wir im Enterprise-Maßstab sehen:

Muster A: An Domänen ausgerichtete Aufteilung der Plattform

Eigene Plattformteams pro großer Engineering-Domäne:

• Infrastrukturplattform — Compute, Networking, Storage, Identity
• Datenplattform — Data Warehousing, ETL, Echtzeit-Streams
• ML-/KI-Plattform — GPU-Scheduling, Model Serving, Feature Stores
• Anwendungsplattform — Laufzeitdienste, Deployment-Automatisierung

Jedes Plattformteam hat eigene Kunden (die Produktteams, die die jeweilige Domäne nutzen). Gemeinsame Standards werden über die Governance-Funktion gesichert.

Passt zu: Organisationen mit klaren Grenzen zwischen Engineering-Domänen (die meisten Fintechs, die meisten Consumer-Tech-Unternehmen dieser Größe).

Muster B: An Geschäftsbereichen ausgerichtete Plattformföderation

Eigene Plattformteams pro Geschäftsbereich:

• Plattform für das Privatkundengeschäft
• Plattform für das Firmenkundengeschäft
• Plattform für das Wealth Management
• Plattform für konzernweite Shared Services

Jeder Geschäftsbereich betreibt seine eigene Plattform auf einem gemeinsamen Substrat. Die Föderation läuft über Governance — Architecture Review Board, Technologie-Radar, Abkündigungsrichtlinien.

Passt zu: Organisationen mit starker Autonomie der Geschäftsbereiche (die meisten etablierten Finanzdienstleister, die meisten großen Industriekonglomerate).

Muster C: Hybrid — gemeinsames Substrat plus Domänen-Erweiterungen

Eine einzige grundlegende Plattform (Compute, Networking, Storage, Identity), die alle Geschäftsbereiche teilen. Domänenspezifische Plattformerweiterungen (ML-Plattform, Datenplattform) setzen darauf auf und werden von spezialisierten Domänenteams betrieben.

Passt zu: Organisationen, die Konsistenz (grundlegendes Substrat) mit Spezialisierung nach Domänen (ML, Daten) ausbalancieren.

In allen drei Mustern ist die Governance der Plattform aus Plattformen das tragende Element. Ohne sie führt die Aufteilung zu 50 verschiedenen Plattformen mit 50 verschiedenen Betriebsmodellen — deutlich schlechter als eine gut gesteuerte Plattform.

Personalrechnung

Für Platform Engineering im Enterprise-Maßstab hilft folgende Faustregel:

• Team für die grundlegende Substrat-Plattform — 1 Engineer pro 50–100 Produkt-Engineers. Bei 2.000 Produkt-Engineers sind das 20–40 Platform Engineers, verteilt auf Teilteams für Infrastruktur, Daten, Anwendungen und SRE.
• Domänen-Plattformteams — jeweils 5–15 Engineers, skaliert mit der domänenspezifischen Komplexität und der Zahl der Kunden.
• Governance- und Architekturfunktion — 3–8 Personen (Architekten, Verantwortliche für das Technologie-Radar, Verantwortliche für Abkündigungen).
• Betrieb und Rufbereitschaft — getrennt vom Build-Engineering; skaliert nach Vorfallvolumen und SLA-Stufe.

Gesamte Platform-Engineering-Funktion: etwa 5–10 % der gesamten Engineering-Belegschaft in reifen Plattformorganisationen. Darunter ist die Plattform strukturell unterfinanziert.

Governance-Modelle

Das Muster des Architecture Review Board (ARB) funktioniert im Enterprise-Maßstab, wenn es bewusst gestaltet wird:

Besetzung des ARB

Leitende Platform Engineers (eine Person pro Plattformteam) plus leitende Produkt-Engineers (rotierend, etwa 5 gleichzeitig) plus Security-Leitung plus Compliance-Leitung plus Chief Architect (Vorsitz).

Das Board prüft Architekturentscheidungen, die mehrere Teams betreffen, legt Zeitpläne für die Abkündigung ausgemusterter Fähigkeiten fest, genehmigt neue Abhängigkeiten von Herstellern oder Open-Source-Projekten und pflegt das Technologie-Radar (Adopt / Trial / Assess / Hold).

Entscheidungsrhythmus

Monatliche ARB-Sitzung für Routineentscheidungen. Quartalsweise für den strategischen Review. Asynchrone Entscheidungen zwischen den Sitzungen, wenn es zeitkritisch ist.

Was das ARB NICHT tut

Das ARB steuert nicht die Architekturentscheidungen einzelner Produktteams innerhalb ihres eigenen Verantwortungsbereichs im Detail. Diese bleiben Entscheidungen der Produktteams. Das ARB verantwortet ausschließlich teamübergreifende Entscheidungen.

Diese Grenze ist wichtig: ARBs, die übergreifen, erzeugen politische Reibung, die die Governance-Funktion selbst untergräbt.

Woran Enterprise Platform Engineering scheitert

Fünf Fehlermuster wiederholen sich:

1. Plattformfunktion als Kostenstelle statt als Werttreiber

Das Plattformteam wird als Overhead budgetiert. Die Stellen werden aus Kostengründen begrenzt. Investitionen in Golden Paths werden auf „nach der Auslieferung von Feature X“ verschoben. Sechs Monate später hat die Geschwindigkeit der Plattform nachgelassen, aber die Kosteneinsparungs-Erzählung bestimmt weiter das Budget.

Lösung: Messen Sie den Wert des Plattformteams in Kennzahlen der Geschwindigkeit des Produkt-Engineerings (Zeit bis zur Umgebung, Zeit bis zur Produktion, Fehlerquote der Deployments). Zeigen Sie die Wirkung in denselben Kennzahlen, mit denen der CFO die Produktivität der Produktteams bewertet.

2. Das Backstage-als-Plattform-Antipattern

Backstage kaufen und das Plattformproblem für gelöst erklären. Backstage funktioniert als Portal nur, wenn die zugrunde liegenden Fähigkeiten tatsächlich als Self-Service verfügbar sind. Enterprise-Organisationen, die Backstage vor dem Plattformsubstrat kaufen, bekommen schöne Kataloge über betrieblichem Chaos. Die Adoption stockt.

Lösung: Backstage als Oberfläche für die Nutzer, nachdem das Plattformsubstrat real existiert. Developer Self-Service von Ænix lässt sich mit Backstage kombinieren, wenn der Kunde das bevorzugt; das Cozystack Dashboard funktioniert ebenfalls.

3. Aufteilung ohne Governance

Mehrere Plattformteams entstehen organisch (jeder Geschäftsbereich baut seine eigene Plattform). Es gibt keine gemeinsamen Standards. Workloads zwischen Geschäftsbereichen zu verschieben, ist schwer oder unmöglich. Engineers können nicht ohne erhebliche Umschulung zwischen Geschäftsbereichen wechseln.

Lösung: Investieren Sie früh in Governance. Das ARB muss nicht schwerfällig sein; es muss nur existieren und Entscheidungsbefugnis haben.

4. Die herstellergeführte „Plattform aus der Box“

Ein großer Hersteller verkauft dem Kunden eine komplette Platform-Engineering-Lösung. Der Kunde akzeptiert. 18–24 Monate später funktioniert die Plattform für die Referenzkunden des Herstellers, aber nicht für diese konkrete Organisation. Der Vendor-Lock-in ist strukturell, die Kosten für einen Austausch sind enorm.

Lösung: ein Open-Source-Substrat (Cozystack, Vanilla Kubernetes usw.) mit optionalem kommerziellem Support. Der Kunde behält die architektonische Hoheit.

5. Optimierung auf technische Eleganz statt auf die Adoption durch Produktteams

Eine architektonisch schöne Plattform, die Produktteams nicht nutzen wollen. Die Adoption stockt. Das Plattformteam gibt den Produktteams die Schuld, die Produktteams dem Plattformteam.

Lösung: Interviews mit Produktteams als wiederkehrende Disziplin des Plattformteams. Messen Sie die Adoption pro Golden Path. Stellen Sie Pfade ein, die nicht angenommen werden. Bauen Sie Pfade, die dem entsprechen, was Produktteams tatsächlich anfragen.

Was Enterprise Platform Engineering von Ænix liefert

Ein typisches Projekt umfasst:

Arbeitspaket 1 — Bestandsaufnahme des Ist-Zustands

Erfassung der bestehenden Plattforminvestitionen: Teams, Technologie-Stack, Governance-Funktion, Adoptionskennzahlen, Ausgangswerte für die Zeit bis zur Umgebung. Oft ist das erste nützliche Artefakt die Bestandsaufnahme selbst — die meisten Enterprise-Organisationen haben kein einziges Dokument, das den gesamten Plattform-Footprint abbildet.

Arbeitspaket 2 — Design des Soll-Zustands

Empfehlung zum Organisationsdesign nach den oben beschriebenen Mustern. Personalprognosen pro Plattformteam. Design der Governance-Funktion (ARB-Charta, Entscheidungsrhythmus, Eskalationswege). Ersteinrichtung des Technologie-Radars.

Arbeitspaket 3 — Plattformsubstrat auf Basis von Cozystack (wo zutreffend)

Grundlegendes Substrat auf der Ænix Private Cloud Platform (für regulierte Organisationen) oder auf Developer Self-Service (für produktorientierte Organisationen). Multi-Region, Multi-DC, für Audits isolierte Umgebungen, Ausrichtung an DORA / NIS2, wo zutreffend.

Dieses Arbeitspaket ist nicht immer Teil des Projekts — manche Kunden behalten ihr bestehendes Substrat und beauftragen Ænix nur mit Governance und Disziplin.

Arbeitspaket 4 — Roadmap der Golden Paths

Die 5–15 Golden Paths mit der größten Hebelwirkung für die konkreten Bedürfnisse der Produktteams des Kunden identifizieren. In eine Reihenfolge bringen. Gestaffelt ausrollen. Adoptionskennzahlen.

Arbeitspaket 5 — Kompetenztransfer und betriebliche Übergabe

Die Ænix-Engineers reduzieren ihre direkte Beteiligung schrittweise. Die Platform-Engineering-Funktion des Kunden übernimmt die Verantwortung. Der Ænix-Retainer läuft für Beratung und Eskalationen unter SLA (Plus- oder Enterprise-Support-Stufe) weiter.

Wann dieses Projekt passt

Gute Passung:

• 1.000+ Engineers über mehrere Geschäftsbereiche oder Domänen
• Eine bestehende Platform-Engineering-Funktion, aber Probleme mit Governance, Adoption oder teamübergreifender Konsistenz
• Rückhalt durch Vorstand oder Geschäftsleitung für eine mehrjährige Plattforminvestition
• Regulatorische Pflichten (Finanzdienstleistungen, öffentlicher Sektor, Telekommunikation, Energie, Gesundheitswesen)
• Betrieb über mehrere Regionen oder Rechtsräume hinweg

Bedingte Passung:

• 500–1.000 Engineers — hier passt eher Developer Self-Service (schlankerer Umfang) als ein vollständiges Enterprise-Platform-Engineering-Projekt

Schlechte Passung:

• Kleinere Organisationen — Developer Self-Service oder Leistungen für Platform Engineering haben den richtigen Umfang
• Organisationen mit nur einem Geschäftsbereich, unabhängig von der Zahl der Engineers — der Governance-Aufwand zahlt sich nicht aus

Weiterführende Inhalte

• Leistungen für Enterprise Platform Engineering — die kommerzielle Landingpage
• Leistungen für Platform Engineering — der kleinere Umfang
• Leistungen rund um die Internal Developer Platform — das Projekt auf der IDP-Ebene
• Lösungsseite Developer Self-Service — für Organisationen mit Fokus auf Produkt-Engineering
• Produktseite Private Cloud Platform — für regulierte Organisationen
• Internal Developer Platform — 6 Muster ohne Backstage-Lock-in — sechs Muster aus der Produktion
• Reifegradmodell für Platform Engineering — Reifegradmodell mit fünf Stufen und acht Dimensionen
• Developer Self-Service — die Ökonomie der Entwicklungsgeschwindigkeit — der wirtschaftliche Fall für die IDP
• Private Cloud aufbauen — 90-Tage-Playbook — für das Arbeitspaket zum Aufbau des Substrats

Die DORA-Diskussion zerfiel in den meisten Finanzinstituten 2024–2025 in zwei Hälften. Die erste Hälfte — Governance, Richtlinien, Dokumentation des IKT-Risikomanagements — landete bei Rechtsabteilung, Compliance und CISO. Als DORA am 17. Januar 2025 in Kraft trat, war diese Dokumentation bei den meisten regulierten Unternehmen in ordentlichem Zustand.

Um die zweite Hälfte — die Cloud-Architektur nachweisbar an DORA auszurichten, wenn ein echter TLPT-Zyklus ansteht — war es stiller. Diese Stille bricht 2026 auf. TLPT-Übungen der Aufsicht erreichen inzwischen Architekturen, die beim Start von DORA als konform galten, aber nie unter realistischer Prüfung durch die Aufsicht getestet wurden.

Was TLPT bedeutet und warum es jetzt zählt

Threat-Led Penetration Testing (TLPT) ist unter DORA für bedeutende Finanzunternehmen vorgeschrieben. Alle drei Jahre führt ein externer Testdienstleister eine strukturierte Red-Team-Übung gegen die laufende Produktionsumgebung durch, wobei das CSIRT / SOC des Finanzunternehmens als echter Verteidiger behandelt wird.

Es geht nicht darum, Schwachstellen zu finden (das leistet jeder Pentest). Es geht darum, die operationale Resilienz unter realistischen Angriffsszenarien nachzuweisen — dass Menschen, Prozesse und Infrastruktur des Unternehmens innerhalb der von DORA erwarteten Fristen erkennen, reagieren und wiederherstellen können.

Für Platform Engineers zählen drei Fragen der TLPT-Readiness:

1. Erkennung im Takt der Meldefristen. DORA Artikel 17–19 setzen für die Erstmeldung eines schwerwiegenden IKT-bezogenen Vorfalls eine kurze Frist, und NIS2 Artikel 23 legt für Unternehmen, die unter beide Regelwerke fallen, eine Frühwarnung binnen 24 Stunden fest. Ist Ihre Detection-Telemetrie auf Performance statt auf Sicherheit abgestimmt, ist jede dieser Fristen eine Fiktion.
2. Vollständigkeit des Audit-Trails. DORA Artikel 6 verlangt einen dokumentierten Rahmen für das IKT-Risikomanagement, den Sie der Aufsicht mit Nachweisen belegen können — welche Kontrollen zum Zeitpunkt des Vorfalls in Kraft waren. Dokumentation reicht nicht; die Messlatte sind Nachweise aus dem laufenden System.
3. Eindämmung und Wiederherstellung. TLPT-Übungen spielen reale Angriffsmuster ein. Die Network Policies, das Identitätsmodell und die Isolationsgrenzen der Plattform müssen realistischen Versuchen von Lateral Movement und Persistenz standhalten.

Wie eine „DORA-fähige Architektur“ tatsächlich aussieht

Eine belastbare Cloud-Architektur für Finanzdienstleister hat sechs Eigenschaften, auf die die Aufsicht achtet:

1. Auf Sicherheit abgestimmte Detection-Telemetrie

Die meisten Banken, mit denen wir arbeiten, haben eine reichhaltige Performance-Telemetrie und eine von Alert Fatigue geplagte Sicherheitstelemetrie. Das Verhältnis der Alerts stimmt nicht: zu viel Performance-Rauschen, zu wenig Signal bei den Sicherheitsereignissen, die einem meldepflichtigen Vorfall nach DORA Artikel 18–19 (und NIS2 Artikel 23, wo beide gelten) entsprechen.

Lösungsmuster:

• Kuratierte Alert-Regeln, abgestimmt auf die für Cloud-Infrastruktur relevanten MITRE-ATT&CK-Techniken
• Logs fließen aus VictoriaLogs / VictoriaMetrics (selbst gehostet, im eigenen Rechtsraum) in ein SIEM, das das SOC tatsächlich überwacht
• Erkennung rund um die Uhr (24×7) mit dokumentierter Eskalation
• Alert-Hygiene als wiederkehrende Aufgabe

Die Ænix Private Cloud Platform liefert VictoriaMetrics und VictoriaLogs standardmäßig für Telemetrie in Sicherheitsqualität konfiguriert aus, dazu sicherheitsorientierte Alert-Regeln. Die Anbindung an das SIEM des Kunden ist Projektarbeit.

2. Workload-Identität statt weit offener Service Accounts

Die Standard-Service-Accounts von Kubernetes sind weit offen. In einer an DORA ausgerichteten Architektur hat jeder Workload eine Identität, jede Identität ist eng begrenzt, und jeder Aufruf zwischen Diensten ist authentifiziert und autorisiert.

Muster: SPIFFE/SPIRE für die Workload-Identität, External Secrets Operator mit dem Schlüsselspeicher des Kunden als Backend, Pod Security Standards als durchgesetzte Policy. Das Ænix-Projekt umfasst die Integration; der IdP und die Mitarbeiteridentität des Kunden bleiben unter Kontrolle des Kunden.

3. Tenant-CRD-Isolation als strukturelle Antwort auf das Konzentrationsrisiko

Artikel 29 bewertet das Konzentrationsrisiko anhand der tatsächlichen Resilienz, nicht anhand vertraglicher Diversifizierung. Das Tenant-CRD-Modell bietet Isolation auf Namespace-Ebene pro Geschäftsfunktion, pro Datenklasse und pro Kritikalitätsstufe — mit Quotas, RBAC-Geltungsbereich, Observability-Geltungsbereich und Audit-Trail-Geltungsbereich pro Tenant.

Das ist keine „weiche Mandantenfähigkeit nach dem Prinzip Hoffnung“. Das Tenant CRD ist ein Kubernetes-natives Objekt, das der cozystack-controller abgleicht; der laufende Zustand entspricht der Spezifikation, oder der Operator macht die Abweichung sichtbar.

4. Für Audits isolierte Umgebungen

Kritische Workloads laufen in Tenants, die ausdrücklich für Audits isoliert sind: getrennte Cluster von nicht produktiven Workloads, manipulationssicheres Logging, das das Audit-Team des Kunden unabhängig nachvollziehen kann, keine gemeinsame Infrastruktur zwischen auditrelevanten und nicht auditrelevanten Workloads.

Das kostet mehr Infrastruktur. Diese Kosten sind der Preis für belastbare Audit-Nachweise.

5. Exit-Readiness mit geübten Exit-Drills

Artikel 28(8) verlangt für Vereinbarungen zu kritischen Funktionen einen erprobten Exit-Plan. Die Aufsicht erwartet zunehmend einen teilweisen Exit-Drill innerhalb der letzten 24 Monate.

Die Cozystack-basierte Architektur macht Exit-Drills mechanisch einfacher: Die Workloads sind Standard-KubeVirt-VMs und Kubernetes-Ressourcen. Das Ziel des Exits kann „dieselbe Kubernetes-API auf anderer Hardware oder bei einem anderen Anbieter“ sein. Das Projektmodell von Ænix enthält ein dokumentiertes Playbook für den Exit-Drill, das Kunden jährlich durchspielen.

6. Transparenz über die Lieferkette bis zur zweiten Stufe

Artikel 30(2)(a) verlangt Einblick in die IKT-Lieferkette mindestens bis zur zweiten Stufe. Für die Beziehung zum Plattformanbieter steht Ænix in der Pflicht — wir stellen ein attestiertes Dokument zur Offenlegung der Lieferanten bereit, das Upstream-Open-Source-Komponenten, Kanäle für Sicherheitsmeldungen und betriebliche Abhängigkeiten abbildet.

Jenseits des Plattformanbieters ist der Kunde dafür verantwortlich, seine eigene Lieferkette abzubilden. Ænix-Projekte enthalten Tooling für die Erfassung, die Bestandsaufnahme selbst ist aber Arbeit auf Kundenseite.

Wo die meisten Cloud-Architekturen von Finanzdienstleistern noch zu kurz greifen

Vier wiederkehrende Muster aus unseren Assessments 2025–2026:

Lücke 1: Observability verlässt still den regulierten Perimeter

Die Produktionsdatenbank liegt in einer EU-Region, die dem regulatorischen Mandat entspricht. Die darauf laufende Anwendung schickt Logs an einen SaaS-Anbieter für Observability, dessen Region für die Datenverarbeitung standardmäßig in den USA liegt. In jeder Minute, in der die Anwendung läuft, wandern Anwendungslogs mit Transaktionsdetails, Kundenkennungen und geschützten Daten in eine nicht konforme Jurisdiktion.

Die meisten Banken bemerken das erst nach einem Hinweis der Aufsicht. Dann bedeutet die Behebung entweder, den SaaS-Anbieter auszutauschen (ein Projekt über mehrere Quartale), oder eine regionale Datenverarbeitungsvereinbarung auszuhandeln (bei manchen Anbietern möglich, bei anderen langwierig).

Die architektonische Antwort auf Basis von Cozystack: selbst gehostetes VictoriaMetrics und VictoriaLogs auf derselben Infrastruktur wie die Workloads. Damit ist das Residency-Leck beseitigt.

Lücke 2: Der Exit-Plan existiert auf dem Papier, getestet wurde er nie

Der Exit-Plan wurde für die Aufsicht geschrieben; geübt hat ihn niemand. Die Schätzungen zur Dauer eines Exits stammen aus Tabletop-Übungen und sind nicht an einem Drill kalibriert. Fragt die Aufsicht „Wann haben Sie den Exit-Plan zuletzt getestet?“, herrscht Schweigen.

Lösung: jährliche Exit-Drill-Übung mit dokumentiertem Ergebnis. Das Ænix-Projekt liefert das Playbook; der Kunde führt die Übung durch.

Lücke 3: Konzentrationsrisiko als Beschaffungsfrage behandelt

„Wir nutzen AWS in zwei Regionen; wir haben eine Vertragsklausel, die eine geografische Verteilung unseres Backups vorschreibt.“ Beides stimmt. Keines von beidem adressiert, was Artikel 29 tatsächlich bewertet — die materielle architektonische Resilienz gegen den Ausfall eines einzelnen Anbieters.

Die materielle Antwort: Workloads nutzen Plattformabstraktionen (Kubernetes, KubeVirt, S3-kompatiblen Storage, relationale Standarddatenbanken), die es auf mehreren Substraten gibt. Das Ziel des Exits wird auf Architekturebene benannt, nicht auf juristischer Ebene.

Lücke 4: Das Risiko der Unterauftragnehmer ist jenseits der ersten Stufe unsichtbar

Der beauftragte Hyperscaler ist dokumentiert. Seine Rechenzentrumsbetreiber, Anbieter der Netzwerkanbindung und die darunterliegenden gemeinsam genutzten Plattformdienste sind es nicht. Artikel 30(2)(a) verlangt Transparenz bis zur zweiten Stufe.

Bei einer Cozystack-basierten Architektur legt der Plattformanbieter (Ænix) die Herkunft der Upstream-Komponenten offen. Der Hardwarelieferant ist die nächste Stufe; alles darüber hinaus liegt in der Verantwortung des Kunden.

Das Projektmodell von Ænix für Finanzdienstleister

Wir gehen Projekte mit Finanzdienstleistern anders an als in anderen Branchen, weil die Treiber Regulierung und Audit-Readiness die Arbeit prägen.

Phase 0 — Discovery und DORA-Scoping

Den regulatorischen Rahmen bestätigen (DORA plus nationale Zusatzregeln plus sektorale Vorschriften). Die Kritikalitätsklassifizierung der Workloads bestätigen. Sponsor und Ansprechpartner für die Kommunikation mit der Aufsicht auf Kundenseite. Projektmodell (typisch: Ænix übernimmt Beratung und Support unter SLA, der Kunde den Produktionsbetrieb).

Phase 1 — Platform Readiness Assessment mit DORA-Arbeitspaket

Assessment über 14 oder 28 Tage zum Festpreis. Architektur-Review Kontrolle für Kontrolle gegen die Erwartungen aus DORA Artikel 6 und Artikel 28–30. Ergebnis: ein Bericht von 30–50 Seiten mit Gap-Analyse, priorisierter Behebung und Zeitplan.

Phase 2 — Pilot-Deployment der Private Cloud Platform

3–6 Monate. Ein definierter Ausschnitt der Workloads kritischer Funktionen wird auf die Cozystack-basierte Private Cloud Platform migriert. Der Nachweiskatalog für die Aufsicht wird teilweise aufgebaut. Die TLPT-Readiness wird für den Pilotumfang validiert.

Phase 3 — Vollständiger Aufbau der Private Cloud Platform

3–12 Monate, je nach Workload-Umfang und Multi-DC-Struktur; der TLPT-Zyklus kann den Zeitpunkt der Abnahme zusätzlich bestimmen. Deployment in Produktionsqualität mit vollständiger Compliance-Dokumentation als Lieferergebnis. Ænix wirkt an der TLPT-Vorbereitung mit; den Test selbst führen akkreditierte Red-Team-Dienstleister durch.

Phase 4 — Managed Retainer

Ænix-Beratung plus Support der Plus- oder Enterprise-Stufe unter SLA. Gearbeitet wird über GitOps-PR-Reviews; Fernzugriff auf den Produktionscluster gibt es nur mit Freigabe des Kunden. Entscheidend für die Governance einer Bank.

Wann dieses Projektmodell passt

Gute Passung:

• Europäische Tier-1- oder Tier-2-Bank mit aktivem DORA-Programm
• Versicherer mit regulatorischer Exposition in mehreren Rechtsräumen
• Zahlungsinstitut im Überschneidungsbereich von DORA und PSD2/PSD3
• Marktinfrastruktur (CSDs, CCPs) unter DORA und CSDR
• Ein laufender TLPT-Zyklus, der Arbeit an der Architektur-Readiness erfordert

Bedingte Passung:

• Kleinere Banken, deren Budgetrahmen noch nicht auf ein mehrjähriges Programm ausgelegt ist; die Public Cloud Platform mit souveränitätsorientierter Architektur kann eine Brücke sein

Schlechte Passung:

• Banken, die sich bereits auf ein mehrjähriges Hyperscaler-Programm festgelegt haben und diese Entscheidung nicht neu öffnen — Ænix kann zu konkreten DORA-Architekturlücken im Hyperscaler-Kontext beraten, die vollständige Private Cloud Platform passt dort aber nicht

Weiterführende Inhalte

• Branchenseite Finanzdienstleistungen — die kommerzielle Landingpage, ausgehend von den Auslösern
• Leistungen zur DORA-Compliance — die DORA-Landingpage aus Sicht des Einkäufers
• Produktseite Private Cloud Platform — das Produkt für regulierte Unternehmen
• DORA-Compliance-Checkliste für Cloud-Infrastruktur — DORA-Durchgang auf Architekturebene
• Private Cloud Platform — DORA- und NIS2-Pflichten in der Architektur — architektonische Details auf Produktebene
• DORA-Compliance-Checkliste — Checkliste der Kontrollen zum Herunterladen

Cloud-Architektur für regulierte Unternehmen ist 2026 ein anderes Gespräch als 2022. DORA gilt seit dem 17. Januar 2025. Die Frist zur Umsetzung von NIS2 ist im Oktober 2024 abgelaufen. Die Erwartungen der Aufsicht werden mit jedem TLPT-Zyklus schärfer. Das Muster aus der Zeit vor DORA — eine Hyperscaler-Region mit ein paar Vertragsklauseln — hält einer realistischen Prüfung nicht stand.

Die zehn Maßnahmenbereiche — NIS2 Artikel 21(2) und wo DORA sie trifft

NIS2 Artikel 21(2) verlangt „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen“ in zehn aufgezählten Bereichen. DORA deckt weitgehend dasselbe Terrain auf anderem Weg ab: über den Rahmen für das IKT-Risikomanagement (Artikel 5–16, insbesondere Artikel 6), das Management und die Meldung von Vorfällen (Artikel 17–23) und das IKT-Drittparteienrisiko (Artikel 28–30). Ein reguliertes Unternehmen, das unter beide Regelwerke fällt, betreibt nicht zwei Architekturen — es betreibt eine und weist sie zweimal nach. Die zehn Bereiche unten folgen der Aufzählung in NIS2; wo DORA dieselbe Kontrolle in einem anderen Artikel regelt, ist dieser genannt.

Für Platform Engineers übersetzen sich die zehn Bereiche in konkrete Architekturentscheidungen:

1. Konzepte für Risikoanalyse und Sicherheit der Informationssysteme

Folge für die Architektur: Jeder Workload einer kritischen Funktion hat einen dokumentierten Eintrag im Risikoregister. Die Artefakte des Threat Models liegen beim Workload (nicht in einem separaten „Compliance-System“, das auseinanderdriftet). Pod Security Standards und Kubernetes Network Policies setzen die technischen Kontrollen um, die das Risikoregister benennt.

2. Bewältigung von Sicherheitsvorfällen

Die Erkennung muss innerhalb der Meldefristen nach NIS2 Artikel 23 funktionieren: Frühwarnung binnen 24 Stunden, Meldung des Vorfalls binnen 72 Stunden, Abschlussbericht nach einem Monat. DORA regelt das in den Artikeln 17–19 eigenständig — Klassifizierung nach Artikel 18, Meldung schwerwiegender IKT-bezogener Vorfälle an die zuständige Behörde nach Artikel 19 — mit Fristen, die in den technischen Durchführungsstandards festgelegt sind und nicht im Artikeltext selbst. Bauen Sie die Erkennung auf die strengere der beiden Vorgaben aus; die Architektur ist in beiden Fällen dieselbe. Der Engpass in der Praxis ist die Detection-Telemetrie — Alert Fatigue überdeckt das Signal. Die Private Cloud Platform wird mit VictoriaMetrics und VictoriaLogs sowie kuratierten Alert-Regeln ausgeliefert, die auf Sicherheit abgestimmt sind, nicht nur auf Performance.

3. Aufrechterhaltung des Betriebs

RTO und RPO sind pro kritischem Workload dokumentiert und werden jährlich getestet — mit Telemetrie, die das Testergebnis belegt. Reine Backups reichen nicht. Die Private Cloud Platform enthält Velero plus anwendungsspezifische Muster (PostgreSQL PITR, Kafka-Snapshots usw.) sowie Hooks für Chaos Engineering zur kontrollierten Fehlerinjektion.

4. Sicherheit der Lieferkette

Die anspruchsvollste Anforderung im Drittparteienkapitel von DORA (Artikel 28–30): IKT-Drittparteienvereinbarungen werden erfasst, nach Kritikalität klassifiziert, und die Kette der Unterauftragnehmer wird nach Artikel 30(2)(a) bis zur zweiten Stufe abgebildet. Die Private Cloud Platform liefert Ihnen die Anbieterbeziehung, für die Ænix einstehen kann (wir sind der Plattformanbieter); das Open-Source-Fundament (Cozystack) schafft Transparenz bis auf die Ebene der Upstream-Komponenten. Alles darüber hinaus liegt in der Verantwortung des Kunden.

5. Sicherheit bei Erwerb, Entwicklung und Wartung

SAST/DAST in der CI, Container-Scanning plus SBOM, Schwachstellenmanagement mit dokumentiertem SLA, veröffentlichte Disclosure-Policy. Die Private Cloud Platform bringt die Disziplin auf Betreiberseite mit; die Pipelines des Kunden werden angebunden.

6. Bewertung der Wirksamkeit

Für wesentliche Einrichtungen erwartet die Aufsicht eine jährliche externe Bewertung. Die Dokumentation der Private Cloud Platform folgt den Arbeitsformaten, mit denen die Aufsicht arbeitet — Mapping auf Kontrollebene, Nachweiskatalog, vollständiger Audit-Trail.

7. Cyberhygiene und Schulungen

Nicht Teil der Plattform selbst, aber Teil der Aufgaben des Betriebsteams beim Kunden. Ænix kann den Kubernetes Deep Dive Course als Teil des Projekts liefern (separates Produkt).

8. Kryptografie

Die Verschlüsselung ruhender Volumes ist pro Storage-Klasse verfügbar und wird beim Design aktiviert (Opt-in). Schlüsselverwaltung, Rotation und Notfallzugriff entwerfen und dokumentieren wir gemeinsam mit Ihnen. Secrets lassen sich über den External Secrets Operator aus dem Schlüsselspeicher des Kunden beziehen.

9. Personalsicherheit, Zugriffskontrolle und Asset-Management

Workload-Identität über SPIFFE/SPIRE oder Gleichwertiges. Privileged Access Management. Automatisierter Joiner-Mover-Leaver-Prozess. Vollständiges und aktuelles Asset-Register. Die Private Cloud Platform wird mit dem cozystack-controller ausgeliefert, der das Asset-Register als Kubernetes-natives Objekt führt — ohne Abweichung zwischen Policy und laufendem Zustand.

10. MFA, kontinuierliche Authentifizierung, gesicherte Kommunikation

Mindestens MFA auf allen privilegierten Konten. Der Enterprise-Tier des Ænix-Supports verlangt MFA für jeden Cluster-Zugriff auf Kundenseite. Gesicherte Notfallkommunikation über den Supportkanal selbst.

DORA Artikel 28–30 — die Lieferantenrisiko-Dimension, an der die meisten Setups scheitern

Im Drittparteienkapitel von DORA haben die meisten Banken und Versicherer, mit denen wir arbeiten, die größten Lücken. Drei Muster wiederholen sich:

Muster 1 — Observability-Daten verlassen still den regulierten Perimeter

Die Produktionsdatenbank liegt in einer EU-Region, die dem regulatorischen Mandat entspricht. Die darauf laufende Anwendung schickt Logs und Metriken an einen SaaS-Anbieter für Observability — Datadog, New Relic, Splunk Cloud —, dessen Region für die Datenverarbeitung standardmäßig in den USA liegt. Anwendungslogs mit Transaktionsdetails, Kundenkennungen und geschützten Daten wandern in jeder Minute, in der die Anwendung läuft, in eine nicht konforme Jurisdiktion.

Die Drittparteienanforderungen von DORA gelten für die gesamte IKT-Drittparteienvereinbarung — Observability-Tools eingeschlossen. Prüfungen der Aufsicht decken das zunehmend auf; herkömmliche „Richtlinien zur Datenklassifizierung“ nicht. Die Private Cloud Platform ersetzt SaaS-Observability durch selbst gehostetes VictoriaMetrics und VictoriaLogs auf derselben Infrastruktur des Kunden. Damit ist das häufigste Residency-Leck beseitigt.

Muster 2 — Exit-Pläne auf dem Papier, nie getestet

Artikel 28(8) verlangt für Vereinbarungen zu kritischen Funktionen einen dokumentierten Exit-Plan mit erprobter Durchführbarkeit. Die meisten Unternehmen haben einen Plan; deutlich weniger haben ihn geübt. Die Aufsicht fragt inzwischen nach einer Übung innerhalb der letzten 24 Monate.

Das Open-Source-Fundament der Private Cloud Platform macht den Exit-Test mechanisch einfacher: Die Workloads sind Standard-KubeVirt-VMs und Kubernetes-Ressourcen. Das Ziel des Exits kann „dieselbe Kubernetes-API auf anderer Hardware oder bei einem anderen Anbieter“ sein statt einer kompletten Migration. Das Projektmodell von Ænix enthält ein dokumentiertes Playbook für die Exit-Übung, das Kunden jährlich durchspielen.

Muster 3 — Konzentrationsrisiko als Beschaffungsfrage behandelt

Konzentrationsrisiko wird oft erkannt und dann über vertragliche Diversifizierungsklauseln „gemindert“. Die eigentliche Bedingung — Workloads, die architektonisch über mehrere Anbieter verteilt sind — ist meist nicht erfüllt. Artikel 29 bewertet das Konzentrationsrisiko anhand der tatsächlichen Gegebenheiten, nicht anhand der Beschaffungsformalitäten.

Die Architektur der Private Cloud Platform löst die Konzentration von sich aus auf: Die Beziehung zum Cloud-Anbieter beschränkt sich auf Hardware und Bandbreite, nicht auf Plattformdienste. Die Abbildung der Unterauftragnehmer wird drastisch kürzer. Souveränität wird zu einer Frage der Architektur statt des Vertrags.

Was die Private Cloud Platform zusätzlich zur Public Cloud Platform mitbringt

Mehrere Ebenen speziell für regulierte Unternehmen:

• Air-Gap-Installation, dokumentiert und als vollwertiger Deployment-Modus unterstützt. Updates laufen über kontrollierte Kanäle (Harbor-Mirror, Artefakt-Registry auf Kundenseite, manuelle Freigabe). Geeignet für Umgebungen mit Verschlusssachen und für die sensibelsten Bank-Workloads.
• Multi-DC aktiv/passiv oder aktiv/aktiv — die Private Cloud Platform wird in der Regel in zwei oder mehr Rechenzentren ausgerollt, mit rechenzentrumsübergreifender Replikation, die auf die RTO-/RPO-Ziele abgestimmt ist. Ein VM-Failover zwischen Standorten ist ein geprobtes Runbook, kein automatischer Schalter.
• Zugriff nach Ihrer Wahl — Beratung, Runbooks und GitOps-PR-Reviews brauchen keinen Zugriff auf Ihren Produktionscluster. Wo Ihre Support-Stufe es vorsieht, gibt es Fernzugriff auf Ihre Cluster nur mit Ihrer Freigabe. Entscheidend für Banken, bei denen ein Zugriff des Anbieters ein strukturelles Risiko darstellt.
• Anbindung an den Schlüsselspeicher des Kunden — Secrets kommen über den External Secrets Operator aus dem System des Kunden; die genaue Schlüsselarchitektur wird im Projekt festgelegt.
• Für Audits isolierte Umgebungen — getrennte Cluster für Produktion, Audit und forensische Kopie. Audit-Logs lassen sich in einen unveränderlichen Speicher des Kunden ausleiten.
• Compliance-Dokumentation als Lieferergebnis — zum Projektabschluss erhält der Kunde einen Nachweiskatalog Kontrolle für Kontrolle, ausgerichtet an den Erwartungen der Aufsicht zu DORA und NIS2.

Was in der Verantwortung des Kunden bleibt

Die Private Cloud Platform ist architektonisch an DORA und NIS2 ausgerichtet. Sie ist keine Zertifizierung. Mehrere Pflichten bleiben beim Kunden:

• Interne Governance — Berichterstattung an den Vorstand, Risikomanagement-Ausschuss, IKT-Risikofunktion. Außerhalb des Plattformumfangs.
• Sektorale Zusatzregeln — Bankgeheimnis, Versicherungsaufsicht, Gesetze zu Gesundheitsdaten. Sie neben DORA auszulegen, liegt in der Verantwortung des Kunden.
• Das Audit selbst — die Private Cloud Platform liefert Ihnen eine belastbare Architektur und die Nachweise; den Auditzyklus durchzuführen, ist Aufgabe Ihres Audit-Teams.
• Workload-spezifische Risikoentscheidungen — die Private Cloud Platform liefert das Fundament; welche Workloads kritisch sind, wie sie klassifiziert werden und welches Restrisiko Sie akzeptieren, entscheiden Sie.

Wann die Private Cloud Platform die richtige Antwort ist

Gute Passung:

• Sie sind in einem regulierten Sektor tätig (Finanzdienstleistungen, öffentlicher Sektor, Gesundheitswesen, Energie, Telekommunikation) mit Pflichten aus DORA, NIS2 oder sektoralen Zusatzregeln.
• Es gibt eine Entscheidung auf Vorstandsebene, Workloads kritischer Funktionen vom Hyperscaler zu holen.
• Sie können ein mehrjähriges Plattformprogramm budgetieren, dessen Umfang im Scoping festgelegt wird.
• Sie haben ein Plattformteam von 5–10 Engineers für den Betrieb der Infrastruktur oder können es aufbauen.
• In den nächsten 12–18 Monaten besteht sektoraler Druck in Richtung TLPT, Audit der Lieferkette oder Exit-Readiness.

Bedingte Passung:

• Mittelgroße Organisationen, bei denen der regulatorische Druck real ist, das Budget für ein mehrjähriges Programm aber noch fehlt. Die Public Cloud Platform mit souveränitätsorientierter Architektur kann eine Brücke sein.

Schlechte Passung:

• Organisationen ohne regulatorischen Druck. Nutzen Sie ein anderes Produkt (Developer Self-Service oder Cozystack Enterprise Support) — der Compliance-Aufwand der Private Cloud Platform zahlt sich ohne den Treiber Regulierung nicht aus.

Ablauf der Zusammenarbeit

• Discovery Call (30 Min., kostenlos)
• Platform Readiness Assessment (14 oder 28 Tage, Schwerpunkt auf dem Arbeitspaket DORA / NIS2) — Gap-Analyse auf Kontrollebene gegen die aktuelle Architektur
• Pilot (3–6 Monate) — ein definierter Ausschnitt wird auf die Ænix Private Cloud Platform migriert, der Nachweiskatalog für die Aufsicht teilweise aufgebaut
• Vollständiger Aufbau der Private Cloud Platform (3–12 Monate je nach Umfang) — Multi-DC-Deployment in Produktionsqualität mit vollständiger Compliance-Dokumentation
• Managed Retainer (fortlaufend) — Beratung, Runbooks, Review von GitOps-PRs, Incident Response unter SLA

Zeitrahmen: 30-minütiges Discovery-Gespräch, Assessment über 14 oder 28 Tage, danach 3–12 Monate Aufbau je nach Umfang. Bei großen Banken bestimmen TLPT-Zyklus und Abnahmen durch die Aufsicht zusätzlich, wann der Produktivbetrieb beginnt.

Weiterführende Inhalte

• Landingpage Private Cloud Platform — Funktionsübersicht, produktspezifisches FAQ, Kundennachweise
• Leistungen zur DORA-Compliance — Details zu DORA-orientierten Projekten
• Leistungen zur NIS2-Compliance — Details zu NIS2-orientierten Projekten
• DORA-Compliance-Checkliste — kostenlose Checkliste der Kontrollen zum Herunterladen
• DORA-Compliance-Checkliste für Cloud-Infrastruktur — ausführlicherer DORA-Durchgang auf Architekturebene

Die meisten Artikel zur „Developer Experience“ hören 2026 bei „Nehmen Sie Backstage“ auf. Das ist keine Antwort, sondern eine Tooling-Entscheidung, die nach den Architekturentscheidungen kommt. Und die Architekturentscheidungen bestimmen, ob Self-Service-Pfade tatsächlich funktionieren.

Warum Self-Service der Hebel ist

In einer Organisation mit 200 Engineers kostet eine Wartezeit von 2–5 Wochen bis zur Bereitstellung einer Umgebung rund 5 % der Engineering-Produktivität (grobe Schätzung aus unseren Projekten). Diese Zeit auf Stunden zu verkürzen, rechtfertigt die Investition in die Plattform.

Die Einsparungen werden aber nur realisiert, wenn die Produktteams die Self-Service-Pfade tatsächlich nutzen. Eine Plattform, die technisch Self-Service bietet, im Betrieb aber umständlich ist, wird nicht angenommen; Teams schreiben weiter Tickets, weil Tickets sich verlässlich anfühlen.

Die Adoption ist die Kennzahl. Die Architekturentscheidungen leiten sich daraus ab.

Fünf Merkmale von Golden Paths, die funktionieren

1. Schneller als die Alternative per Ticket

Der Self-Service-Pfad liefert schneller ein funktionierendes Ergebnis als ein Ticket. Dauert ein Ticket 3 Tage und der Self-Service 2 Tage, wählen Teams das Ticket, weil Warten bequemer ist als Lernen.

2. Verlässlich genug, um ihm zu vertrauen

Der Self-Service-Pfad funktioniert für den dokumentierten Anwendungsfall beim ersten Mal und jedes Mal. Bricht er in einem von zehn Fällen, verlieren Teams das Vertrauen.

3. Auf höchstens einer Seite dokumentiert

Eine Dokumentation, die länger als eine Seite ist, deutet auf eine falsche Architektur hin. Echte Golden Paths sind von vornherein einfach.

4. Im Besitz eines echten Teams

Ein Team, das den Pfad pflegt, Sonderfälle auffängt und Verbesserungen ausliefert. Ohne klare Verantwortung verfallen Pfade.

5. Mit Ausweichmöglichkeiten

Produktteams können abweichen, wenn ihr Fall besonders ist. Die Ausweichmöglichkeit ist ein echtes Gespräch mit dem Plattformteam, nicht „Nutzen Sie den Pfad oder scheitern Sie“.

Die 10 Pfade, die sich am meisten lohnen

Grob nach Hebelwirkung sortiert:

1. Bereitstellung von Umgebungen — Dev / Staging / Preview / Prod. Der größte einzelne Gewinn durch Self-Service.
2. Anwendungs-Deployment — Image-Push → automatisiertes Deployment.
3. Bereitstellung von Datenbanken — am häufigsten Managed PostgreSQL; danach MySQL und Redis.
4. Onboarding in die Observability — automatisch instrumentierte Metriken, Logs und Traces.
5. Object-Storage-Bucket — S3-kompatibel, mit Lifecycle-Policies.
6. Secrets-Management — Anlegen von Secrets und Zuweisen von Zugriffen.
7. Netzwerkzugang — zu Legacy-Diensten, gemeinsam genutzten Datenbanken und Partnern.
8. Einrichtung von CI/CD-Pipelines — Service-Template plus automatisierte Pipeline.
9. Identity-/SSO-Integration — von der Mitarbeiteridentität zur Serviceidentität.
10. Einrichtung von Backup/DR — für zustandsbehaftete Workloads.

Die ersten drei (Umgebung, Deployment, Datenbank) decken rund 60 % des typischen Anfragevolumens von Produktteams ab. Bauen Sie diese zuerst.

Architekturentscheidungen, die Self-Service prägen

Bereitstellungsmodell

• GitOps + IaC — Produktteams committen IaC-Manifeste, die Plattform reagiert darauf. 2026 am weitesten verbreitet.
• API-getrieben — die Plattform stellt eine REST-/RPC-API bereit; Produktteams rufen sie direkt oder über ein Portal auf.
• Operator-getrieben — Kubernetes-Operatoren pro Ressourcentyp; Produktteams legen CRD-Instanzen an.
• Click-Ops über ein Portal — Backstage / Port / eigene UI, die Operator-gestützte Aktionen bereitstellt.

Die meisten Organisationen kombinieren mehrere Modelle: GitOps plus IaC als Source of Truth, das Portal als Ebene zum Auffinden für Teams, die sich in Kubernetes nicht zu Hause fühlen.

Mandantenmodell

• Namespace pro Team — weiche Isolation, am einfachsten, Standard für Organisationen, in denen sich die Teams gegenseitig vertrauen.
• Cluster pro Team — harte Isolation, im Betrieb teuer, nötig für Fälle mit hohen Isolationsanforderungen.
• Tenant CRD pro Team — Kubernetes-native Isolation in einem gemeinsamen Cluster, im Betrieb effizient. Standard in Cozystack.

Identitätsmodell

Die Mitarbeiteridentität (Keycloak / Okta / Azure AD) wird in die Plattformidentität föderiert. Die Serviceidentität (SPIFFE/SPIRE oder Service Accounts) regelt die Kommunikation zwischen Diensten. Beides zusammenzuführen, ist Aufgabe des Plattformteams.

Was schiefgeht

Fallstrick 1: Backstage als die Plattform

Wer Backstage kauft, bevor die zugrunde liegenden Fähigkeiten als Self-Service verfügbar sind, bekommt einen schönen Katalog über demselben betrieblichen Chaos. Die Adoption stockt.

Fallstrick 2: zu starr

Golden Paths müssen 80 % der Fälle abdecken. Die übrigen 20 % brauchen Ausweichmöglichkeiten; ohne sie umgehen Teams mit speziellen Anforderungen die Plattform komplett.

Fallstrick 3: Pfade ohne Personal

Das Plattformteam baut Pfade und wendet sich dann anderem zu. Die Pfade verfallen, Fehlermeldungen stapeln sich. Die Teams verlieren das Vertrauen.

Fallstrick 4: Optimierung auf technische Eleganz

Architektonisch schöner Self-Service, der im Betrieb umständlich ist. Produktteams interessieren sich für Ergebnisse, nicht für Architektur.

Fallstrick 5: die Bestandsaufnahme überspringen

Das Plattformteam baut Pfade, die es selbst für nötig hält; dann stellt sich heraus, dass die tatsächlichen Top-10-Anfragen andere sind. Die Lösung: Fragen Sie die Produktteams, was sie am häufigsten anfragen, und bauen Sie dafür.

Reihenfolge der Umsetzung

1. Den aktuellen Ticketfluss erfassen — welche 10 Dinge fragen Produktteams am häufigsten an? Interviews mit den einzelnen Teams bringen das zutage.
2. Die Top 3–5 auswählen — sie decken rund 60 % des Volumens ab.
3. Für jeden einen Golden Path bauen — typischerweise 1–2 Monate pro Pfad bei ausreichender Kapazität im Plattformteam.
4. An der Adoption iterieren — Feedback einsammeln, Reibung beseitigen, Dokumentation ergänzen.
5. Die Pfade 4–10 in den folgenden Quartalen ergänzen — orientiert an der beobachteten Nachfrage.

Bewerten und loslegen

Steht Self-Service zur Debatte, benennt ein strukturiertes Assessment die wichtigsten Anfragen, zeigt, wo die heutigen Pfade versagen, und legt die Reihenfolge fest, in der gebaut werden sollte. Ænix führt das als Teil des Platform Readiness Assessment durch.

Details finden Sie unter Developer Self-Service und Leistungen rund um die Internal Developer Platform.

Dieser Artikel setzt voraus, dass Sie beide Plattformen kennen. Eine breitere Orientierung zum Ausstieg aus VMware finden Sie unter VMware-Alternative oder VMware-Migration.

Compute-Schicht

VMware vSphere/ESXi: ausgereifter Typ-1-Hypervisor. Starkes Lifecycle-Management für VMs, Live-Migration mit Shared Storage, vMotion. Enge Integration der VMware Tools in die Gastsysteme.

Cozystack KubeVirt: qemu/KVM, verpackt in Pods. KVM selbst ist ein Hypervisor im Kernel-Modus, der Gast läuft also weiterhin auf den Virtualisierungserweiterungen der Hardware — der Pod ist eine Hülle für Scheduling und Lifecycle, keine zusätzliche Emulationsschicht. Live-Migration (CPU; GPU-Live-Migration ist eine branchenweite Einschränkung). Unter der Haube Standard-QEMU/KVM; breite Unterstützung für Gastbetriebssysteme.

In der Praxis liefern beide VM-Workloads in Produktionsqualität. Das KubeVirt-Modell bringt zusätzlich die betriebliche Integration in Kubernetes mit (deklarative VM-Konfiguration, GitOps-Lifecycle, natives Ingress, Observability).

Storage-Schicht

VMware vSAN: in vSphere integrierter Software-defined Storage. Im Betrieb reibungslos, eng integriert. An die VMware-Lizenzierung gebunden.

Cozystack LINSTOR: replizierter Open-Source-Blockspeicher, ausgerollt über den Piraeus-Operator. LINSTOR nutzt DRBD für die synchrone Replikation; Object Storage ist eine eigene Schicht (SeaweedFS). Mehr Verantwortung im Betrieb, mehr architektonische Flexibilität.

Für die meisten Workloads erreicht LINSTOR die betrieblichen Eigenschaften von vSAN. Wo zusätzlich Object Storage im S3-Stil gebraucht wird, liefert Cozystack SeaweedFS als verwalteten Bucket-Service mit.

Netzwerkschicht

VMware NSX: Software-defined Networking. Verteilte virtuelle L2-Switches, L3-Routing, Mikrosegmentierung, Edge Gateway. Ausgereift, aber komplex.

Cozystack Cilium: eBPF-basiertes CNI mit L4/L7-Policies, Observability, Service-Mesh-Integration, MetalLB / BGP. Neuere Architektur, oft einfacher.

Die Migration aus einer NSX-lastigen Umgebung zu Cilium erfordert ein Redesign der Policies — eine 1:1-Abbildung gibt es nicht. Das Architekturmodell ist ein anderes.

Mandantenschicht

VMware vCloud Director: ausgereiftes Multi-Tenant-Overlay auf vSphere. Funktionen für Service Provider (Organisationen, vDC, Kataloge).

Cozystack Tenant CRD: Kubernetes-native Abstraktion für Mandantenfähigkeit. Verschachtelte Tenants, Quotas pro Tenant, mandantenbezogenes Audit, abrechnungsfreundlich.

Das Mandantenmodell ist konzeptionell ein anderes — vCD-Organisationen gegenüber Instanzen des Tenant CRD. Bei der Migration muss die Mandantenstruktur auf das Kubernetes-native Äquivalent neu abgebildet werden.

Folgen für den Betrieb

Tagesgeschäft

VMware: vCenter-UI für Ad-hoc-Aufgaben; PowerCLI / Ansible für die Automatisierung. SSH ist nicht das Standardmodell.

Cozystack: kubectl plus GitOps als Standardmodell. Cozystack-Dashboard-UI für Tenant-Aufgaben. Review von GitOps-PRs als Change-Management.

Der Wechsel vom vCenter-zentrierten zum kubectl-zentrierten Arbeiten ist für VMware-geschulte Teams eine echte Lernkurve im Betrieb. Die meisten Engineers arbeiten sich mit gezieltem Training in 4–8 Wochen ein.

Upgrades

VMware: zuerst Upgrade von vCenter, dann ESXi-Upgrade Host für Host (rollierend). Ausgereifter Prozess.

Cozystack: Upgrade von Talos OS, von Kubernetes und vom Cozystack-Operator. GitOps-gesteuert. Rollierend Host für Host.

Beide arbeiten mit Rolling Upgrades. Im Betrieb ähnlich im Geist, aber mit unterschiedlichem Tooling.

Backup / DR

VMware Site Recovery Manager: ausgereifte DR-Orchestrierung mit automatisiertem Failover. Im großen Maßstab erprobt.

Cozystack Velero plus PITR pro Anwendung: Velero übernimmt das Backup auf Cluster-Ebene; anwendungsspezifische Muster (PostgreSQL PITR usw.) kommen darüber. Mehr bewegliche Teile, mehr Flexibilität.

Das Muster ist ein anderes — SRM ist eine vom Hersteller verwaltete Plug-and-Play-Lösung mit orchestriertem Failover. Auf Cozystack heißt DR: Backup und Wiederherstellung mit Velero plus geübte Runbooks; ein orchestriertes standortübergreifendes Failover wie bei SRM gibt es nicht. Dafür ist der Velero-Stack transparenter und besser anpassbar.

Migrationsmuster

Die Migration von VMware zu Cozystack in der Produktion:

1. Discovery — Inventar von vSphere/VCF; Klassifizierung der Workloads.
2. Cozystack-Fundament — paralleles Deployment; kein Tenant von VMware.
3. Image-Migration — KubeVirt CDI importiert VMDK- oder qcow2-Images. Bei Windows-VMs werden die VMware Tools vor dem ersten Start unter KubeVirt bereinigt.
4. Netzwerk-Cutover — Abbildung der VLANs in Cilium; die Gleichwertigkeit der Policies wird gegen die NSX-Regeln validiert.
5. Storage-Cutover — vSAN → LINSTOR (DRBD); Datenmigration während des Cutovers der jeweiligen Kohorte.
6. DR-Cutover — Backup und Wiederherstellung mit Velero plus Runbooks an Stelle der SRM-Pläne (kein orchestriertes Failover wie bei SRM); wird pro Kohorte getestet.
7. Abschaltung von VMware — gestaffelt, sobald die Kohorten abgeschlossen sind.

Typische Gesamtdauer nach einem Platform Readiness Assessment von 14 oder 28 Tagen: rund 8–12 Monate für einen Bestand von ~100 VMs und 18–24 Monate für ~1.000 VMs, einschließlich Planung und Migrationswellen; Bestände dazwischen liegen je nach Abhängigkeiten zwischen diesen Werten. Treiber ist selten die reine Kopiergeschwindigkeit — es sind die Regressionstests und die Parallelbetriebsfenster, denen die Verantwortlichen der Anwendungen zustimmen.

Wann der Vergleich zählt

Diese Detailtiefe ist hilfreich, wenn:

• ein Architektur-Review läuft
• die Umsetzung in Phase 2 geplant wird
• konkrete betriebliche Fragen anstehen (Storage-Performance, Netzwerklatenz usw.)
• Schulungen für das Team geplant werden

Für eine Bewertung auf höherer Ebene ist VMware-Alternative der passendere Einstieg.

„Cloud-Strategie“ ist ein abgenutzter Begriff. Hyperscaler bieten sie an (Azure Cloud Adoption Framework, AWS Migration Acceleration Programme, Google Cloud Adoption Framework). Die Big 4 bieten sie an (Deloitte, KPMG, EY und PwC haben jeweils Cloud-Beratungssparten mit Tausenden Beratern). Partner der Hyperscaler bieten sie an (Systemintegratoren mit Tausenden zertifizierten Cloud-Beratern). Boutique-Beratungen bieten sie an. Interne Strategieteams erarbeiten sie selbst.

Der Markt ist voll, und die Methoden sehen von außen ähnlich aus. Der Unterschied zeigt sich darin, was die Strategie tatsächlich empfiehlt, wer welchen Anreiz für welche Empfehlung hat und ob die Empfehlung 18 Monate Praxis übersteht.

Dieser Artikel ist die ehrliche Fassung: Was liefert eine herstellerneutrale Cloud-Strategieberatung nach Art von Ænix, warum unterscheidet sie sich von Hyperscaler-nahen oder Big-4-Alternativen, und wann passt welche Variante.

Was eine „Cloud-Strategie“ 2026 wirklich beantworten muss

Fünf strategische Fragen bestimmen die Diskussion 2026:

1. Wo sollte jede Workload-Klasse laufen?

Der Standard von 2018 — „alles in die Public Cloud“ — ist überholt. DORA-relevante Workloads laufen anders als SaaS-Workloads. Dauerhafte KI-Inferenz läuft anders als kundenseitige Anwendungen mit Lastspitzen. Regulierte Datenklassen laufen anders als offene Daten. Die Strategie muss pro Workload-Klasse Position beziehen, statt alle über einen Kamm zu scheren.

2. Wie lautet die Position zur Souveränität?

Unterschiedliche Rechtsordnungen, Branchen und Kundenbeziehungen stellen unterschiedliche Anforderungen an die Souveränität. Die Strategie muss die Position ausdrücklich benennen — einschließlich der Kosten in Form betrieblicher Komplexität und der Auswirkungen auf die Anbieterauswahl.

3. Wie entwickeln sich die Kosten?

Public-Cloud-Rechnungen wachsen mit Zinseszinseffekt. Die Strategie muss die Kosten über die nächsten 3–5 Jahre für jede Workload-Klasse und jede Substrat-Option prognostizieren. Eine ehrliche Prognose — einschließlich Hardware-Erneuerung, Kapazität im Platform Engineering und Wechselkosten durch Vendor-Lock-in —, nicht die Marketing-Version.

4. Welches Betriebsmodell skaliert?

Nur DevOps? Platform Engineering? In die Teams eingebettete SREs? Zentrales SRE? Das Modell muss zum Personalprofil und zum Wachstumspfad der Engineering-Organisation passen; Fehlanpassungen kosten mehr, als sie sparen.

5. Wie entwickelt sich das regulatorische Umfeld?

DORA gilt seit Januar 2025. Die NIS2-Umsetzung erfolgte im Oktober 2024. EUCS wird finalisiert. Branchenspezifische Vorgaben weiten sich aus. Regelwerke für souveräne Clouds werden schärfer. Die Strategie darf nicht auf den heutigen regulatorischen Stand festgeschrieben sein; sie muss die wahrscheinliche Entwicklung der nächsten 24–36 Monate einbeziehen.

Eine „Cloud-Strategie“-Beratung, die nicht zu allen fünf Fragen Position bezieht, ist keine Strategie. Sie ist eine Tooling-Roadmap.

Warum Herstellerneutralität zählt

Hyperscaler-nahe Beratung und die meisten Big-4-Beratungssparten haben eine implizite kommerzielle Ausrichtung, die ihre Empfehlungen prägt:

• Beratung unter Führung der Hyperscaler — AWS, Azure, GCP und IBM Cloud finanzieren jeweils eigene und partnergeführte Beratungssparten. Die Beratung ist strukturell darauf ausgerichtet, den jeweiligen Hyperscaler zu empfehlen. Ehrliche Praktiker versuchen gegenzusteuern, aber der kommerzielle Anreiz ist eindeutig.
• Cloud-Beratung der Big 4 — Deloitte, KPMG, EY und PwC haben jeweils Partnerprogramme mit Hyperscalern, die die Empfehlungen beeinflussen. Die meisten Projekte enden mit einem Modernisierungsplan, der auf einen Hyperscaler ausgerichtet ist, weil dort die Integrationsumsätze liegen.
• Systemintegratoren als Hyperscaler-Partner — Capgemini, Accenture, Infosys und Wipro haben den Status zertifizierter Partner bei Hyperscalern und verdienen an Umsetzungen unter Führung der Hyperscaler. Herstellerneutral laut Marketing, herstellergebunden laut Ökonomie.

Herstellerneutrale Beratung bedeutet: Das kommerzielle Ergebnis des Projekts hängt nicht davon ab, dass sich der Kunde für einen bestimmten Hyperscaler, eine bestimmte Distribution oder ein bestimmtes Produkt entscheidet. Das Geschäftsmodell von Ænix — wir bauen und betreiben die Cloud-Plattform-Produkte von Ænix — schafft eine andere Ausrichtung: Wir möchten, dass die Strategie bei einem davon landet, wo es passt, drängen aber ausdrücklich nicht darauf, wo es nicht passt.

Wir sagen „bleiben Sie beim Hyperscaler“, wenn die Abwägung es rechtfertigt. Und zwar schriftlich. Der negative Anreiz, der daraus entsteht, ist real — manche Projekte enden ohne Folgeauftrag für Plattformarbeit bei Ænix —, und genau so soll Herstellerneutralität funktionieren.

Was unsere Beratung tatsächlich liefert

Eine typische Cloud-Strategieberatung von Ænix umfasst:

Arbeitsstrang 1 — Strategie für das Workload-Portfolio

Taxonomie der Workload-Klassen: reguliert / nicht reguliert, Dauerlast / Lastspitzen, sensible / nicht sensible Datenklasse, latenzkritisch / elastisch. Für jede Klasse die Eignung des Substrats (Public Cloud / von Hyperscalern verwaltet / Private Cloud / souverän / hybrid / Edge).

Ergebnis: eine Matrix von Workload-Klassen zu Substraten mit Begründung pro Klasse.

Arbeitsstrang 2 — Position zur Souveränität

Anwendbarkeit der Regulierung über Rechtsordnungen und Branchen hinweg. Substanzielle Souveränitätsanforderungen pro Workload-Klasse. Bewertungskriterien für Anbieter aus Sicht der Souveränität.

Ergebnis: eine schriftliche Position zur Souveränität mit benannten Rechtsordnungen, benannten Einschränkungen für Substrate und dokumentierter Akzeptanz der Restrisiken.

Arbeitsstrang 3 — Kostenentwicklung

Kostenprognose über drei bis fünf Jahre für die verschiedenen Substrat-Optionen. Ehrliche TCO einschließlich versteckter Kosten (Egress, schlecht genutzte Reservierungen, Kapazität im Platform Engineering, Wechselkosten durch Vendor-Lock-in, Hardware-Erneuerungszyklen). Sensitivitätsanalyse für die wichtigsten Annahmen.

Ergebnis: eine Tabellenkalkulation, die Ihr CFO prüfen kann, plus erläuternder Text.

Arbeitsstrang 4 — Empfehlung zum Betriebsmodell

Gestaltung der Funktionen DevOps / SRE / Platform Engineering. Personalprognosen. Einstellungsplan. Empfehlungen zur Organisationsstruktur. Prioritäten beim Tooling.

Ergebnis: Empfehlungen zum Organisationsdesign mit benannten Rollen, RACI-Matrizen und priorisierter Einstellungsreihenfolge.

Arbeitsstrang 5 — regulatorische Entwicklung

Ausblick auf 24–36 Monate für die anwendbaren Regelwerke. Finalisierung von EUCS, Durchsetzung von NIS2, Verschärfung branchenspezifischer Vorgaben, Ausweitung der Souveränitäts-Regelwerke. Wie sich die Strategie für das Workload-Portfolio anpasst, wenn sich das regulatorische Umfeld verändert.

Ergebnis: eine regulatorische Roadmap mit Prüfterminen und Entscheidungsauslösern.

Synthese: der Plan für 18–36 Monate

Die Ergebnisse von fünf Arbeitssträngen werden zu einem Strategiedokument auf Vorstandsniveau zusammengeführt. Management Summary (3–5 Seiten). Details der Arbeitsstränge (5–8 Seiten je Strang). Roadmap mit Meilensteinen (2–3 Seiten). Empfehlungen zur Reihenfolge der Umsetzung.

Insgesamt: ein Dokument mit 30–50 Seiten plus Management-Präsentation für Vorstand bzw. Sponsoren.

Varianten der Zusammenarbeit

• Strategisches Assessment über 28 Tage — engerer Umfang, Festpreis, ein einzelnes Segment des Workload-Portfolios
• Strategieprojekt über 8 Wochen — voller Umfang mit fünf Arbeitssträngen, Festpreis
• Quartalsweise strategische Beratung — laufende Begleitung bei strategischen Entscheidungen, sobald sie anstehen (typischerweise für Tier-1-Kunden)

Wo der Nutzen der Beratung wächst

Strategieprojekte haben oft ein „Schrankware“-Problem — das Ergebnis wird abgeliefert, verteilt, und 18 Monate später weiß niemand mehr, was drinstand. Das Beratungsmodell von Ænix setzt hier an:

• Von Engineers geschrieben, nicht von Beratern — unsere Ergebnisse schreiben dieselben Engineers, die sie umsetzen würden; technische Nachvollziehbarkeit bedeutet, dass sich jede Aussage auf konkrete Artefakte zurückführen lässt.
• Kontinuität in der Umsetzung — beauftragt der Kunde Ænix mit der Umsetzung, wirkt das Engineering-Team, das die Strategie geschrieben hat, an der Ausführung mit. Kein Verlust bei der Übergabe.
• Entscheidungstempo statt Folienglanz — wir liefern 30–50 Seiten verwertbarer Details, nicht 100 Seiten Management-Theater.
• Quartalsweise strategische Beratung für Tier-1-Kunden hält die Strategie aktuell, während sich das Umfeld des Kunden und die Regulierung weiterentwickeln.

Wann diese Beratung passt

Gute Eignung:

• CIO / CTO / Head of Cloud in einer Organisation mit über 100 Mio. € Umsatz
• Vor der Entscheidung über eine mehrjährige Cloud-Ausrichtung (Modernisierung, Repatriierung, souveräne Cloud, KI-Infrastruktur)
• Bisherige Strategiearbeit hat herstellergebundene Optionen hervorgebracht, mit denen man sich unwohl fühlt
• Regulatorischer Druck (DORA, NIS2, branchenspezifisch) erfordert eine substanzielle Positionierung über die Erfüllung von Beschaffungsklauseln hinaus

Bedingte Eignung:

• Mittelgroße Organisationen mit einfacherem Entscheidungsraum — hier passt eher ein Platform Readiness Assessment (taktischer) als ein vollständiges Strategieprojekt
• Entscheidung für eine einzelne Workload-Klasse (z. B. nur KI-Infrastruktur) — hier passt eher das KI-spezifische Sovereign AI Architecture Review

Schlechte Eignung:

• Organisationen, die sich bereits auf ein bestimmtes Hyperscaler-Programm festgelegt haben — Ænix kann zu konkreten Architekturlücken innerhalb dieser Festlegung beraten, aber eine vollständige Strategiearbeit setzt voraus, dass die Entscheidungen noch offen sind
• Strategiearbeit, bei der es vor allem um Change Management oder Umstrukturierung der Organisation geht — das ist eine andere Kategorie

Der Unterschied zum Platform Readiness Assessment

Die beiden Angebote überschneiden sich im Umfang, verfolgen aber unterschiedliche Zwecke:

• Platform Readiness Assessment ist taktisch — es bewertet den Ist-Zustand gegenüber einer Zielarchitektur und liefert einen Maßnahmenplan in 14 oder 28 Tagen. Es kommt zum Einsatz, wenn die strategische Richtung feststeht.
• Cloud-Strategie-Beratung ist strategisch — sie definiert die Zielarchitektur und die Substrat-Position. Sie kommt zum Einsatz, wenn die strategische Richtung noch offen ist.

Die meisten Kunden nehmen am Ende beides nacheinander in Anspruch: zuerst die Strategie, dann das Assessment, dann die Umsetzung.

Weiterführende Informationen

• Cloud-Strategie-Beratung — die Angebotsseite
• Platform Readiness Assessment — das taktische Assessment
• Cloud Readiness Assessment — Methodik für 14 Tage — Details zur Methodik des taktischen Assessments
• Cloud Engineering 2026 — die sieben Disziplinen des Cloud Engineering

Apache CloudStack ist bei Service Providern in mehreren Märkten in der EU, im MENA-Raum und in APAC fest etabliert. Es bringt ein ausgereiftes Mandantenmodell, breite Unterstützung durch die Community und gut verstandene Betriebsmuster mit. Warum also prüfen Betreiber 2026 eine Modernisierung?

Drei Druckfaktoren stechen heraus:

1. Fachkräftemangel — der Pool an CloudStack-Expertise ist kleiner als früher, und neue Engineers werden auf Kubernetes ausgebildet, nicht auf das Komponentenmodell von CloudStack.
2. Grenzen des Servicekatalogs — der Kern von CloudStack sind VMs, Netzwerke und Storage. Managed-Datenbanken, S3-kompatibler Object Storage, Container-native Workloads und GPU-as-a-Service werden entweder umständlich angeflanscht oder laufen komplett außerhalb der Plattform.
3. Nachfrage der Kunden nach Kubernetes-nativen Diensten — Kunden wollen zunehmend Tenant-Kubernetes-Cluster, Container-Workloads und Kubernetes-natives Networking. CloudStack löst das über Integrationen, Cozystack nativ.

Wo CloudStack weiterhin die bessere Wahl ist

Bevor wir über Modernisierung sprechen, sollten wir ehrlich benennen, wo CloudStack nach wie vor die richtige Antwort ist:

• Etablierte Expertise und stabiler Kundenstamm — Betreiber mit tiefer CloudStack-Betriebserfahrung und stabiler Kundenzahl, bei denen die Migrationskosten den Nutzen der Modernisierung übersteigen könnten
• VMware-on-CloudStack-Deployments — wo CloudStack als Orchestrierungsschicht über einem bestehenden VMware-Bestand läuft, lautet die Modernisierungsfrage zuerst „Verlassen wir VMware?“ und erst danach „Wechseln wir den Orchestrator?“
• Spezifische CloudStack-Funktionen ohne direktes Kubernetes-Äquivalent — tiefgehende Netzwerkkonfigurationsmuster, bestimmte Load-Balancer-Integrationen, an regionale Beschaffung gebundene Funktionen

Die Modernisierung passt woanders: bei Providern mit wachsender Kundennachfrage nach Kubernetes-nativen Diensten, bei Providern, deren Betriebskomplexität mit jeder Fluktuation im Team weiter zunimmt, und bei Providern, die Managed-Datenbanken, S3 oder GPU-Dienste einführen, die nicht nativ in CloudStack passen.

Architektur-Mapping: CloudStack → Cozystack

Zwei Bereiche brauchen ein grundlegendes Redesign statt einer 1:1-Abbildung: das Networking (das eBPF-Modell von Cilium ist grundlegend anders als der L2/L3-Virtual-Router von CloudStack) und der Servicekatalog (CloudStack Service Offerings gegenüber Cozystack-Paket plus ApplicationDefinition).

Migrationsphasen

Phase 0 — Assessment (14 oder 28 Tage)

Workload-Inventar: Anzahl der VMs, Betriebssystem-Mix, vCPU-/RAM-/Disk-Profile, Kritikalitätsstufe. Netzwerk-Inventar: Anzahl der VPCs, Vergabe öffentlicher IPs, Load-Balancer-Konfigurationen, Security-Group-Regeln. Storage-Inventar: Kapazität von Primary und Secondary Storage, Aufbewahrung von Snapshots, Volume-Typen. Mandanten-Inventar: Anzahl der Accounts, Domain-Hierarchie, Projektstruktur.

Kundenbezogenes Inventar: ARPU pro Kunde, Servicenutzung, vertragliche Verpflichtungen, SLA-Stufen, Berührungspunkte mit der Billing-Integration.

Ergebnis: ein Migrationsplan mit Workload-Gruppen (jetzt migrieren / später migrieren / bleibt / neu architektieren), Risikomarkierungen und Zeitplan.

Phase 1 — Cozystack-Fundament (2–4 Monate)

Hardwarebeschaffung (oder Weiterverwendung vorhandener Hardware). Die Cozystack-Plattform wird auf neuer Infrastruktur parallel zum bestehenden CloudStack-Bestand aufgebaut. Cilium-Networking wird validiert, LINSTOR-Storage in den Betrieb überführt. Anbindung an das Identity-Management (Keycloak oder den IdP, den der Provider betreibt).

Das Tenant-CRD-Modell wird so entworfen, dass es sich sauber aus der Account-/Domain-Hierarchie von CloudStack ableiten lässt — in der Regel wird jeder CloudStack-Account der obersten Ebene zu einem Cozystack-Tenant, verschachtelte CloudStack-Domains werden zu verschachtelten Tenants.

Endzustand: eine funktionierende Cozystack-Plattform, interne Validierung abgeschlossen, noch nicht für Kunden freigegeben.

Phase 2 — Servicekatalog und Kundenportal (2–4 Monate)

Anpassung des Cozystack Dashboards an die Marke des Providers. WHMCS-Integration, falls der Provider WHMCS nutzt (das tun die meisten CloudStack-Provider mit WHMCS). Rollout des Servicekatalogs — zuerst die Basisdienste (VMs, Volumes, S3-Buckets, grundlegendes Networking), danach schrittweise Managed Services, die es in der CloudStack-Ära nicht gab.

Phase 3 — VM-Migration (3–9 Monate)

Die Workloads ziehen in Kohorten von jeweils 50 bis 200 Kunden um. Pro Kohorte:

1. Image-Konvertierung — CloudStack-Templates und Kunden-Images werden in ein KubeVirt-kompatibles Format konvertiert. Die meisten CloudStack-KVM-Images lassen sich mit qemu-img plus kleinen Metadaten-Anpassungen konvertieren. In Windows-VMs der Kunden werden virtio-Treiber injiziert (Standardvorgehen).
2. Netzwerk-Mapping — Übersetzung von VLANs in Cilium-Policies, von Security-Group-Regeln in NetworkPolicies und vom VPC-Routing in ClusterPool plus Cilium L3.
3. Storage-Migration — die Volume-Daten werden vom CloudStack-Primary-Storage nach LINSTOR migriert. Die Snapshot-Historie wird je nach Aufbewahrungsrichtlinie übernommen oder bereinigt.
4. Cutover — der Workload läuft für ein Validierungsfenster (typischerweise 7–14 Tage) parallel auf Cozystack. Der Kunde wird über den Cutover informiert; der endgültige Cutover erfolgt in einem geplanten Wartungsfenster.

Phase 4 — Rückbau von CloudStack (2–6 Monate)

Mit jeder abgeschlossenen Migrationskohorte wird Hardware in den Cozystack-Cluster übernommen. Der CloudStack Management Server wird abgeschaltet. Das Betriebstooling (Monitoring, Ticketing-Integrationen) wird auf den Cozystack-Stack konsolidiert.

Wo Migrationen von CloudStack zu Cozystack ins Stocken geraten

1. Übersetzung des Netzwerkmodells

Das Netzwerkmodell von CloudStack war historisch konfigurierbarer als das der meisten Cloud-Orchestrierungsplattformen — Advanced Networking, Basic Networking, Isolated Networks, VPC, öffentliche IPs, Hairpin-Routing, aufwendige Security-Group-Konfigurationen. All das in Cilium, MetalLB und Standard-Kubernetes-NetworkPolicies zu übersetzen, erfordert sorgfältige Architekturarbeit. Wer das in Phase 0–1 überspringt, produziert in Phase 3 Produktionsvorfälle.

2. Billing-Integration für Kunden

Die Billing-Hooks von CloudStack unterscheiden sich von denen von Cozystack. Provider mit WHMCS-integriertem CloudStack-Billing nutzen die WHMCS-Integration von Ænix (ein proprietäres Ænix-Modul, nicht Teil von Cozystack); die Anpassung an Tarife und Prozesse ist für jeden Provider spezifisch.

3. Abweichende Self-Service-API für Kunden

CloudStack bietet eine umfassende API für Kunden (cmdkit / SDK). Kunden, die eigenes Tooling gegen die CloudStack-API gebaut haben, brauchen einen Migrationspfad: entweder einen CloudStack-API-kompatiblen Shim auf Cozystack (für einen Teil der Operationen möglich) oder eine Migration der kundenseitigen API auf Cozystack-native Muster. Planen Sie das ein.

Wann die Migration von CloudStack zu Cozystack die richtige Antwort ist

Gute Passung:

• Service Provider mit KVM-basiertem CloudStack und wachsender Kundennachfrage nach Managed-Datenbanken, S3, Container-nativen Diensten oder GPU-Diensten
• Der Fachkräftemangel beginnt, die Betriebsqualität zu beeinträchtigen
• Der Kundenstamm wächst oder ist stabil, schrumpft aber nicht
• Der Betreiber hat Budget für ein Modernisierungsprogramm von 9 bis 24 Monaten

Bedingte Passung:

• VMware-on-CloudStack-Provider — zuerst die VMware-Migration lösen
• Stabile, langsam wachsende Betreiber mit tiefer CloudStack-Expertise, die den betrieblichen Schmerz nicht spüren — die Modernisierung ist ein aufschiebbares Investitionsprojekt

Schlechte Passung:

• Betreiber mit sinkender Kundenzahl — die Modernisierungskosten sind schwer zu rechtfertigen
• Sehr kleine Betreiber (<200 Kunden) — die Fixkosten der Cozystack Public Cloud Platform übersteigen die Einsparungen

Ablauf der Zusammenarbeit

• Discovery Call (30 Min., kostenlos)
• Migrations-Assessment (14 oder 28 Tage, Festpreis) — Inventar, Workload-Gruppen, Zeitplan
• Pilot-Deployment (3–6 Monate) — Aufbau der Cozystack-Plattform, Migration von 5–10 wohlgesonnenen Kunden, Validierung der Billing-Workflows
• Migration der Kundenkohorten (6–18 Monate) — Workload-Migration in Kohorten, parallel dazu Rückbau von CloudStack
• Managed Retainer (optional, fortlaufend) — mit Plus- oder Enterprise-Support-Stufe (siehe Preise)

Gesamtdauer: 12–24 Monate vom Projektstart bis zur vollständigen Abschaltung von CloudStack.

Weiterführende Inhalte

• CloudStack-Migrations-Hub — der Einstiegspunkt zur Migration im Überblick
• Produktseite Public Cloud Platform — das häufigste Zielprodukt bei CloudStack-Migrationen
• Branchenseite Hosting-Anbieter — Positionierung speziell für Hosting-Anbieter
• Plattformmodernisierung für Hosting-Anbieter — Artikel zu einem verwandten Modernisierungsmuster

Warum die meisten Cloud-TCO-Modelle falsch sind

Die Rechnung ist eine einzige Zahl. Die echte TCO der Public Cloud umfasst:

• Egress-Gebühren — oft 5–15 % der Gesamtausgaben, leicht zu übersehen
• Schlecht genutzte Reservierungen — eine Ausschöpfung von 30–50 % ist üblich; der Rabatt verpufft
• Ungenutzte und überdimensionierte Ressourcen — 10–20 % der Compute-Ausgaben
• Aufschlag für Managed Services der Hyperscaler — 2–4× gegenüber Eigenbetrieb im großen Maßstab
• Wechselkosten durch Vendor-Lock-in — unsichtbar, bis etwas bricht
• Kapazität im Platform Engineering, die durch die Komplexität der jeweiligen Public Cloud gebunden ist

Ein echtes TCO-Modell erfasst all das.

Zielkosten — was übersehen wird

Für die Private Cloud als Ziel:

• Hardware-Anschaffung + Erneuerung nach 5 Jahren (die Erneuerungswelle kommt)
• Rechenzentrum oder Colocation
• Netzwerkbandbreite, einschließlich Egress zwischen Standorten
• Storage-Tiering und Wachstum
• Infrastruktur für Backup und DR
• Identity, Observability, Plattform-Tooling
• Kapazität im Platform Engineering für den Betrieb
• Softwarelizenzen, sofern anfallend

Lassen Sie diese Posten weg, sieht die TCO künstlich gut aus; im zweiten Jahr holt Sie die Realität ein.

Sensitivitätsanalyse

Ein ehrliches TCO-Modell reagiert empfindlich auf Annahmen zur Auslastung:

• Eine Dauerauslastung von 50 % statt 80 % verändert die Wirtschaftlichkeit der Private Cloud dramatisch
• Ein Wachstum der Workloads von 20 %/Jahr statt 50 %/Jahr verändert die Erneuerungszyklen der Hardware
• Änderungen beim Egress-Volumen haben einen unverhältnismäßig großen Einfluss

Entscheidungen auf Ebene der Workloads

Auf Portfolio-Ebene kann die TCO neutral ausfallen. Auf Ebene der Workloads zeigt sich meist:

• Top-10-Workloads: 60–80 % der Kostenbilanz
• Der Rest der Workloads: allenfalls leicht kostenpositiv oder neutral

Die Top-10-Workloads zurückzuholen und den Rest in der Cloud zu lassen, ist oft am besten.

So nutzen Sie das Arbeitsblatt

Laden Sie das Cloud-Repatriation-TCO-Worksheet herunter. Tragen Sie Ihre Zahlen ein und gehen Sie sie mit Ihrem Partner aus dem Finanzbereich und dem Platform Engineering durch. Bestimmen Sie die Top-10-Kandidaten für die Repatriierung. Prüfen Sie die Annahmen.

Für die vollständige Zusammenarbeit siehe Cloud Repatriation.

Die IT von Hochschulen und Forschungsinstituten steht 2026 an einem schwierigen Schnittpunkt: steigender Bedarf an Research Computing (vor allem KI/ML), Vorgaben zur Reproduzierbarkeit (Plan S, FAIR, Horizon Europe), Lehrbedarf für Cloud-native Technologien, Governance mit vielen Beteiligten und Budgets, die nicht im Tempo des Rechenbedarfs wachsen. Cloud-native Plattformen — Open Source, Kubernetes-nativ, mandantenfähig — beantworten zunehmend all das zugleich, wo Infrastruktur aus der Zeit vor der Cloud für jeden Anwendungsfall eigens spezialisiert werden musste.

Die drei Aufgaben im Detail

Auf der Branchenseite haben wir drei Aufgaben von Hochschulen beschrieben. Hier gehen wir auf jede tiefer ein.

Aufgabe 1 — Research Computing im KI-Zeitalter

Der Bedarf an Research Computing hat sich in den letzten 5 Jahren erheblich verschoben. KI/ML-Workloads sind von einer „Spezialtätigkeit einzelner Labore“ zu einer „allgemeinen Forschungsmethode“ quer durch die Disziplinen geworden. Computational Biology, Materialwissenschaften, Klimamodellierung, NLP in den Geisteswissenschaften — alle setzen zunehmend auf Deep-Learning-Ansätze, die GPUs brauchen.

Die Infrastruktur-Antwort darauf bestand bisher aus:

• EuroHPC / nationalem HPC — für die größten Workloads
• Institutsclustern — für mittlere Workloads, von den Laboren selbst verwaltet
• Cloud-GPU-Guthaben — für gelegentliche und experimentelle Workloads
• Persönlichen Workstations — für leichte Workloads

Jede Variante hat Grenzen:

• HPC hat Zugangshürden und Wartezeiten und eignet sich nur bedingt für iterative KI/ML-Entwicklung
• Institutscluster zersplittern das Know-how; jedes Labor pflegt seinen eigenen
• Cloud-GPU-Guthaben sind im großen Maßstab nicht tragfähig; dazu kommen Souveränitätsbedenken bei sensiblen Daten
• Persönliche Workstations stoßen bei kleinen Modellen an ihre Grenzen

Was modernes Research Computing zunehmend will: einen gemeinsamen GPU-Pool mit starker Isolation, Self-Service für PIs, Verwaltung per IaC für Reproduzierbarkeit und, wo sinnvoll, Integration in nationale und europäische Forschungsinfrastruktur.

Eine Kubernetes-native Plattform wie Cozystack liefert genau das. KubeVirt bedient ältere, VM-basierte Forschungs-Workflows; native Container bedienen moderne ML-Pipelines. Der NVIDIA GPU Operator übergibt ganze GPUs an Workloads, und HAMi teilt eine einzelne GPU nach Speicher und Rechenkernen zwischen Laboren auf; VMs erhalten VFIO-Passthrough ganzer GPUs oder NVIDIA vGPU (erfordert Ihre NVIDIA-vGPU-Lizenz). Das Tenant CRD sorgt für Isolation pro Labor. Das Cozystack Dashboard gibt PIs Self-Service. Dieselbe Infrastruktur lässt sich für die größten Workloads mit EuroHPC verbinden (viele Hochschulen haben hybride Vereinbarungen).

Aufgabe 2 — Infrastruktur für reproduzierbare Forschung

Reproduzierbarkeit ist in vielen Förderkontexten vom Anspruch zur Pflicht geworden. Plan S, die FAIR-Prinzipien für Daten, die Anforderungen von Horizon Europe und fachspezifische Replikationskrisen (Psychologie, Sozialwissenschaften, Biomedizin) drängen alle zu reproduzierbaren Artefakten.

Für rechnergestützte Forschung erfordert Reproduzierbarkeit heute typischerweise:

• die Daten (mit persistenten Identifikatoren, DOIs)
• den Code (mit Versionierung)
• die Laufzeitumgebung (Container-Images, IaC-Manifeste, Abhängigkeitsspezifikationen)

Beim dritten Punkt kommt es auf die Infrastrukturebene an. Ein Forschungsartefakt mit der Angabe „wir haben Python 3.10 mit PyTorch 2.1 auf Ubuntu 22.04 verwendet“ ist nach 5 Jahren nicht reproduzierbar — die Pakete haben sich weiterentwickelt. Ein Forschungsartefakt mit Dockerfile (oder KubeVirt-VM-Image) IST reproduzierbar — die Laufzeitumgebung bleibt bitgenau erhalten.

Cozystack unterstützt dieses Muster nativ:

• Containerisierte Umgebungen als Kubernetes-Manifeste + Image-Registry
• Langzeitarchivierung — Registries mit Aufbewahrungsrichtlinien
• Air-Gap-Installation — für sensible Forschung, die nicht von externen Registries abhängen darf
• Föderierte Muster — Forschungskonsortien mehrerer Einrichtungen können Container-Images über eine gemeinsame Registry teilen

Die European Open Science Cloud (EOSC) ist die Dachinitiative, die die Infrastruktur für reproduzierbare Forschung an europäischen Hochschulen verbindet; Cozystack-Plattformen können sich an EOSC-Föderationen beteiligen.

Aufgabe 3 — Cloud-native Lehre

Informatik- und Ingenieurfakultäten lehren zunehmend Kubernetes, Container-Orchestrierung, GitOps, Observability und verwandte Themen. Die Herausforderung: Studierende brauchen echte Infrastruktur, an der sie praktisch lernen, und diese Infrastruktur muss:

• der Produktionsrealität entsprechen (damit Absolventen sofort einsetzbar sind)
• gefahrloses Experimentieren erlauben (eine kaputte Umgebung darf benachbarte Studierende nicht beeinträchtigen)
• sich zwischen Jahrgängen sauber zurücksetzen lassen
• mit den Kapazitäten der Hochschul-IT laufen (ohne Betrieb auf kommerziellem Niveau zu erfordern)

Cozystack deckt jeden Punkt ab:

• Echte Plattform in Produktionsqualität — Studierende lernen, was die Industrie einsetzt (Cozystack läuft produktiv bei Hosting-Providern, Banken usw.)
• Tenant CRD pro Jahrgang — kaputte Studierendenumgebungen beeinträchtigen benachbarte Studierende nicht
• Durchgesetzte Quotas und RBAC — Fehlkonfigurationen von Studierenden bleiben eingegrenzt
• Self-Service für Lehrende — Lehrende legen Studierendenumgebungen ohne IT-Ticket an und löschen sie wieder
• Status als CNCF-Projekt — Studierende lernen das CNCF-Ökosystem kennen, was nach dem Abschluss wertvoll ist

Erwähnenswert ist auch die Brancheninitiative CNOE (Cloud Native Operational Excellence) — es liefert Referenzmuster für Cloud-native Umgebungen, die sich für die akademische Lehre eignen.

Architekturmuster, die sich bewährt haben

Speziell an Hochschulen und Forschungsinstituten haben sich mehrere Architekturmuster als tragfähig erwiesen:

Muster A — zentraler Research-Computing-Dienst

Eine Cozystack-Installation, betrieben von einem zentralen Research-Computing-Team, das mehrere Fakultäten bzw. Labore als Tenants bedient. Am besten für mittlere bis große Hochschulen (10.000+ Studierende, mehrere forschungsstarke Fakultäten).

Muster B — föderierte Institutscluster

Mehrere Cozystack-Installationen, eine pro großer Fakultät, mit gemeinsamer Identity und Föderation für fakultätsübergreifende Projekte. Am besten für sehr große Hochschulen oder Systeme mit mehreren Standorten.

Muster C — Plattform für Forschungskonsortien

Forschungskonsortien mehrerer Einrichtungen betreiben eine gemeinsame Cozystack-Plattform unter gemeinsamer Governance. Am besten für kooperative Forschung mit erheblichem Rechenbedarf.

Muster D — Plattform für F&E-Institute

Forschungsinstitute (IT, Ingenieurwesen, Biotech) betreiben Cozystack als zentrale Forschungsinfrastruktur. Oft kombiniert mit Zugängen für Industriepartner über das Tenant-CRD-Modell.

Besonderheiten von Hochschulen

Open-Source-Ethos

Die akademische Kultur bevorzugt klar Open-Source-Infrastruktur. Apache 2.0, transparente Governance, die Möglichkeit, Code einzusehen und zu verändern — all das entspricht akademischen Werten. Der Status von Cozystack als CNCF-Projekt und die Lizenz Apache 2.0 passen dazu.

Realistische Budgets

Die IT-Budgets von Hochschulen wachsen nicht mit dem Rechenbedarf. Eine Open-Source-Plattform mit optionalem kommerziellem Support ist ein wirtschaftlich tragfähiges Modell. Subscriptions mit Preisen pro CPU (typisch für kommerzielle Alternativen) passen nicht zur Hochschulfinanzierung.

Planung über Jahrzehnte

Hochschulen planen in Jahrzehnten, nicht in Quartalen. Herstellergetriebene Plattformen, deren Roadmap und Preise sich mit Konzernentscheidungen ändern, sind für eine Planung über Jahrzehnte riskant. Von der Community gesteuerte Open-Source-Projekte sind in dieser Hinsicht berechenbarer.

Souveränität für manche Forschung

Medizinische Forschungsdaten, Verschlusssachen, Forschung mit Industriepartnern unter NDA — all das profitiert von Infrastruktur, die Daten unter der Kontrolle der Einrichtung hält. Die Air-Gap-Unterstützung von Cozystack, die optionale Volume-Verschlüsselung im Ruhezustand (LINSTOR und LUKS) mit einer Passphrase, die die Einrichtung verwaltet, und der Betrieb On-Premises erfüllen diese Anforderungen.

Föderation mit nationaler und europäischer Infrastruktur

EuroHPC für die größten Workloads. EOSC für die Föderation von Open Science. GÉANT für das europäische Forschungsnetz. Nationale Forschungsnetze. Cozystack-Plattformen lassen sich über Standard-Kubernetes-APIs mit all diesen verbinden.

Industriepartnerschaften

Hochschulen arbeiten bei geförderter Forschung zunehmend mit der Industrie zusammen. Die Plattform muss Zugriffsmuster für viele Beteiligte unterstützen — Forschende der Hochschule und der Industriepartner, mit angemessener Isolation und Schutz des geistigen Eigentums. Das Tenant CRD mit verschachtelten Tenants leistet das.

Häufige Fallstricke

Fallstrick 1: reines HPC-Denken

Wer Research Computing als „kleines HPC“ behandelt, übersieht, dass der iterative Entwicklungsablauf bei KI/ML nicht zum Warteschlangenmodell von HPC passt. Moderne Research-Computing-Plattformen müssen sowohl interaktive (Notebook-artige) als auch Batch-Workloads abdecken.

Fallstrick 2: Zersplitterung durch Cluster pro Labor

Baut jedes Labor seinen eigenen Cluster, zersplittert das Know-how, die Wartung verdoppelt sich, und Ressourcen lassen sich bei Lastspitzen nicht teilen. Eine zentrale oder föderierte Plattform steigert den Nutzen immer weiter.

Fallstrick 3: zu wenig in den Betrieb investiert

Research Computing, das Doktoranden oder Postdocs nebenbei betreiben, ist nicht von Dauer. Ein eigenes Research-Computing-Team (auch ein kleines) ist notwendig.

Fallstrick 4: Lehrinfrastruktur, die nicht zur Praxis passt

Kubernetes auf einem Single-Tenant-minikube zu lehren heißt, an einem Spielzeug zu lehren. Wer auf einer mandantenfähigen Plattform nach Produktionsmustern lehrt, bringt Absolventen hervor, die mit den Plattformen arbeiten können, die die Industrie tatsächlich betreibt.

Fallstrick 5: Reproduzierbarkeit als Nachgedanke

Wer Forschungsinfrastruktur ohne Muster für Reproduzierbarkeit ab dem ersten Tag aufbaut, muss später teuer nachrüsten. Containerisierung und IaC-Disziplin sollten der Standard sein.

Was Ænix für Hochschulen konkret bietet

Ænix hat Cozystack-basierte Plattformen für Hochschulen und Forschungsinstitute in der EU und in Zentralasien gebaut. Die Besonderheiten der Zusammenarbeit:

• Vertraut mit öffentlicher Beschaffung — RFI / RFP über die üblichen Kanäle in der EU und in Zentralasien
• Kapazitätstransfer als Kernbestandteil — die Wissensübergabe an die hochschuleigene IT ist ein ausdrückliches Ergebnis
• Schrittweise Zusammenarbeit, wo sinnvoll abgestimmt auf Förderzyklen
• Konsortien mehrerer Einrichtungen werden unterstützt

Details finden Sie auf der Branchenseite für Hochschulen.

Die souveräne Cloud ist kein Nischenthema mehr. Vorgaben der EU-Mitgliedstaaten, Souveränitätsklauseln auf dem Beschaffungsportal Kasachstans und mehrere Initiativen im asiatisch-pazifischen Raum haben Souveränität zu einer eigenen Marktkategorie gemacht. Die „souveränen“ Regionen der Hyperscaler versuchen, darauf zu antworten, stoßen aber an strukturelle Grenzen (Bindung an US-Anbieter, Abhängigkeiten in der Control Plane).

Die Chance für eigens gebaute souveräne Cloud-Produkte ist real — doch der Aufwand für Engineering, Zertifizierung und Betrieb ist erheblich.

Was Souveränität wirklich bedeutet

Souveränität ist mehr als Datenresidenz. Die vollständigen Anforderungen:

1. Datenresidenz auf jeder Ebene — Produktion, Backup, Observability, CI/CD, Telemetrie
2. Verschlüsselung mit vom Kunden kontrollierten Schlüsseln — HSM, dokumentierte Rotation, Verfahren für den Notfallzugriff
3. Open-Source-Fundament der Plattform — Transparenz und Ausstiegsfähigkeit
4. Transparente Lieferkette — mindestens bis zur zweiten Stufe
5. Air-Gap-Option für die sensibelsten Workloads
6. Vollständiger Audit-Trail in Formaten, die die Aufsicht verarbeiten kann
7. Keine Phone-Home-Telemetrie — nur Opt-in
8. Betriebliche Unabhängigkeit — das Team der souveränen Cloud untersteht einer souveränen Rechtsordnung

Ein „souveränes Cloud“-Produkt, das nicht alle diese Punkte substanziell erfüllt, scheitert beim Audit der Aufsicht.

Konkrete Regelwerke zur Souveränität

Jede Rechtsordnung hat ihr eigenes Regelwerk:

EU

• EUCS (EU Cybersecurity Certification Scheme for Cloud Services) — vorgeschlagenes EU-weites Schema (Annahme ausstehend)
• SecNumCloud (Frankreich) — strenge französische Souveränitätsanforderung
• BSI C5 (Deutschland) — deutscher Kriterienkatalog für Cloud-Sicherheit
• DORA — speziell für Finanzdienstleistungen, gilt für Cloud-Provider, die Banken bedienen
• NIS2 — breitere Cybersicherheit; Cloud-Anbieter gehören zu einem Sektor nach Anhang I (wesentliche oder wichtige Einrichtungen, je nach Größe)

Zentralasien

• Kasachstan — durch die Beschaffung vorgeschriebene Souveränität für Workloads des öffentlichen Sektors.
• Weitere GUS-Staaten — verschiedene nationale Regelwerke im Entstehen

Andere Regionen

• Französisches SecNumCloud außerhalb Frankreichs: wird zunehmend als Referenz herangezogen
• Asien-Pazifik — Singapur IM8, Indien MeitY, Australien IRAP usw.

Architekturmuster für die souveräne Cloud

Muster 1: vollständig On-Premises betriebene souveräne Cloud

Hardware des Kunden, vom Kunden betrieben, auf jeder Ebene vom Kunden kontrolliert. Maximale Souveränität bei maximalem Betriebsaufwand. Richtig für die sensibelsten Workloads (Verschlusssachen, Kernbankensysteme).

Muster 2: verwaltete souveräne Cloud

Hardware des Cloud-Providers + souveräne Rechtsordnung + vom Kunden kontrollierte Schlüssel + transparente Lieferkette. Vereinfachter Betrieb bei substanzieller Souveränität. Richtig für die meisten regulierten Unternehmens-Workloads.

Muster 3: Hybrid aus souveräner und nicht souveräner Cloud

Workloads mit kritischen Funktionen auf der souveränen Cloud, unkritische beim Hyperscaler. Ein verbreitetes Muster bei Finanzdienstleistern.

Muster 4: souveräne Edge-Cloud

Die souveräne Cloud wird auf Edge-Standorte innerhalb der Rechtsordnung verteilt. Richtig für Workloads, die sowohl Souveränität als auch Nähe zum Edge brauchen (IoT, Telco).

Cozystack als Fundament der souveränen Cloud

Cozystack ist Open Source (Apache 2.0), wird als CNCF-Projekt gesteuert (die Roadmap bestimmt die Community), unterstützt Air-Gap-Installationen, Volume-Verschlüsselung mit Schlüsseln beim Kunden (Opt-in) und Audit-Logs, die sich in Systeme des Kunden ausleiten lassen.

Speziell für Betreiber souveräner Clouds:

• Mandantenmodell mit dem Tenant CRD — für ein souveränes Cloud-Produkt für Endkunden
• Cozystack Dashboard — Self-Service-Oberfläche für Kunden
• Integration der WHMCS-Abrechnung — für ein Abonnement-Angebot an Endkunden (ein Ænix-Produkt auf Basis von Cozystack, keine Upstream-Komponente)
• Air-Gap-Installation unterstützt und dokumentiert
• VictoriaMetrics + VictoriaLogs — selbst gehostete Observability (keine SaaS-Abhängigkeit)
• Cilium-Netzwerk — souveränitätsfreundlich, keine Abhängigkeit von einer proprietären Netzwerkplattform

Zeitplan der Umsetzung

Ein souveränes Cloud-Produkt aufzubauen dauert länger als eine nicht souveräne Cloud:

• Discovery + Assessment: kostenloses 30-minütiges Discovery-Gespräch, danach ein Platform Readiness Assessment zum Festpreis (14 oder 28 Tage)
• Einzelner Anbieter im Providermaßstab: Plattform mit dem produktisierten Installer wenige Wochen nach Bereitstellung der Hardware live
• Nationales oder Betreiberprogramm: 3–6 Monate Pilot, danach 9–18 Monate bis zum vollen Multi-Region-Betrieb
• Zertifizierung: läuft parallel zum Aufbau; ihr Umfang kann den Termin des ersten zertifizierten Dienstes verschieben
• Onboarding der Kunden: fortlaufend

Zusammenarbeit mit Ænix

Ænix baut souveräne Cloud-Produkte von Anfang bis Ende, mit einem Team von rund 20 Personen in der EU und in Zentralasien. Open-Source-Fundament. Dokumentation, die für die Beschaffung bereit ist.

Details finden Sie auf der Seite zum Sovereign Cloud Builder und bei der Ænix Public Cloud Platform.

„Die eigene Cloud bauen“ war 2018 noch ein Nischenthema. 2026 ist es Mainstream — die Preisänderungen von Broadcom, der Druck in Richtung Souveränität und die Wirtschaftlichkeit von KI-Workloads haben Tausende Organisationen von „Wir mieten einfach Cloud“ zu „Wir brauchen eine Plattform, die wir selbst kontrollieren“ gebracht.

Was früher 18 Monate dauerte, schafft man heute für das Fundament in rund 90 Tagen; die folgenden Quartale bringen dann Reife. Der Grund: Der Open-Source-Plattform-Stack ist ausgereift.

Tag 0: Discovery (1 Woche)

Bevor Sie bauen, verständigen Sie sich auf:

• Auslöser — was treibt Sie zum Aufbau? (VMware-Ausstieg, Souveränität, Kosten, KI.) Der Auslöser prägt die Architektur.
• Workload-Portfolio — was läuft heute, was kommt hinzu. Daraus folgt die Dimensionierung.
• Kapazität — die Kapazität des internen Teams, die Plattform nach dem Aufbau zu betreiben.
• Hardware-Rahmenbedingungen — Rechenzentrums- oder Colocation-Vereinbarungen, Erneuerungszyklen, Netzwerkanbindung.
• Compliance-Umfang — DORA, NIS2, DSGVO, branchenspezifische Vorgaben.

Ergebnis: ein einseitiges Architektur-Briefing. Noch kein Code.

Tag 1–30: Fundament

Woche 1: Hardware einrichten

• Compute-Server beschafft bzw. umgewidmet
• Storage-Tier bereitgestellt
• Netzwerk-Fabric konfiguriert (BGP, Leaf-Spine)
• Out-of-Band-Management

Woche 2: Betriebssystem und Plattform

• Talos Linux installiert (Standard für Cozystack) oder die gewählte Betriebssystemschicht
• Cozystack-Plattform ausgerollt
• Erster Cluster in Betrieb
• Zugriff für Operatoren und Admins geprüft

Woche 3: Storage und Netzwerk

• LINSTOR (DRBD) ausgerollt und validiert
• Cilium mit Network Policies konfiguriert
• MetalLB / Ingress eingerichtet
• Replikation über Nodes hinweg getestet

Woche 4: Identity und Observability

• Keycloak (oder der gewählte IdP) integriert
• VictoriaMetrics + VictoriaLogs ausgerollt
• Erste Dashboards und Alerts
• Audit-Logging konfiguriert

Ende von Tag 30: eine funktionierende Plattform. Single-Tenant, ein Cluster, grundlegende Observability. Für Kunden noch nicht produktionsreif.

Tag 31–60: Mandantenfähigkeit und Betrieb

Woche 5–6: Mandantenfähigkeit

• Tenant CRD konfiguriert
• RBAC und Quotas pro Tenant
• Playbook für das Onboarding von Tenants
• Erste Test-Tenants bereitgestellt

Woche 7–8: Betrieb

• Runbooks für typische Szenarien (Ausfall eines Pods, Ausfall eines Nodes, Wiederherstellung der Control Plane, Zertifikatsrotation)
• Rufbereitschaft eingerichtet
• Backup und DR mit Velero
• Prozess für die Incident Response dokumentiert

Ende von Tag 60: Die Plattform trägt mehrere Tenants mit dokumentiertem Betrieb. Bereit für das Onboarding der ersten echten Workload.

Tag 61–90: Workload-Onboarding und Golden Paths

Woche 9–10: Migration der ersten Workload

• Pilot-Workload (geringes Risiko) aus der bestehenden Infrastruktur migriert
• Performance und Stabilität validiert
• Backup und Wiederherstellung getestet
• Feedback der (internen) Kunden eingeholt

Woche 11–12: Golden Paths

• Self-Service-Pfade für die 5–10 häufigsten Bedürfnisse der Produktteams
• Service-Vorlagen dokumentiert
• Automatisches Onboarding in die Observability
• CI/CD auf Anwendungsebene integriert

Ende von Tag 90: Die Plattform trägt produktive Workloads mit Self-Service. Von hier an wächst die Reife immer weiter.

Was Sie in 90 Tagen weglassen

Ehrlich benannt:

• Ausgefeiltes Kundenportal — das Cozystack Dashboard funktioniert, der Feinschliff der Oberfläche erfolgt aber schrittweise.
• Betrieb über mehrere Regionen / Rechenzentren — zuerst eine Region; mehrere Regionen in den Monaten 4–6.
• Optimierung für GPU-/KI-Workloads — generische GPU-Unterstützung ja; KI-spezifische Optimierungen später.
• Umfassende Compliance-Zertifizierung — die Architektur ist auf DORA/NIS2/DSGVO ausgerichtet; das Zertifizierungsaudit ist ein eigenes Vorhaben.
• Stilllegung der Altinfrastruktur — meist in den Monaten 4–12 in Kohorten.

Wo Teams regelmäßig straucheln

Stolperstein 1: unterbesetztes Plattform-Team

Ein Plattform-Team aus 5 Personen, das eine Private Cloud baut und nebenbei die bestehende Infrastruktur betreibt, bleibt in Woche 4 stecken. Realistische Teamgröße: 5–10 dedizierte Engineers für die Aufbauphase; für den Regelbetrieb kann es auf 3–5 schrumpfen.

Stolperstein 2: an der Observability sparen

Die Observability wird zusammengestrichen, weil sie in den Demos an Tag 0 nicht auftaucht. In der Produktion rächt sich das. Bauen Sie die Observability in Woche 4 zusammen mit der Kernplattform auf.

Stolperstein 3: herstellergetriebene „Private-Cloud-Appliance“

Wer eine „komplette Private Cloud in der Box“ kauft, baut den Lock-in wieder auf. Auch der Aufbau geht langsamer voran, weil die Appliance im Weg steht.

Stolperstein 4: keine Produktorientierung im Plattform-Team

Exzellentes Engineering ohne Produktorientierung bringt eine Plattform hervor, die interne Kunden nicht so annehmen, wie sie gedacht war.

Stolperstein 5: die Compliance-Ebene überspringen

Eine Architektur, die Compliance auf später verschiebt, muss nachgerüstet werden. Bauen Sie Souveränität, Audit und Observability von Tag 0 an mit Blick auf die Compliance.

Was 90 Tage nicht umfassen

Das 90-Tage-Playbook liefert ein Fundament. Die Reife wächst weiter:

• Monate 4–6: Migrationskohorten für Workloads, Ausbau der Golden Paths, regionaler Standort / DR-Standort
• Monate 7–12: GPU-/KI-Subsysteme, fortgeschrittene Muster für Mandantenfähigkeit, FinOps-Integration
• Jahr 2: Reife, Optimierung, Skalierung

Eine Private Cloud im zweiten Jahr ist eine andere Plattform als eine Private Cloud an Tag 90.

Der Markt für VMware-Alternativen sieht 2026 anders aus als 2022. Die Preisänderungen von Broadcom, der Druck in Richtung Souveränität und die Reife Kubernetes-nativer Alternativen haben die Landschaft verschoben. Dies ist die praxistaugliche Fassung der „besten VMware-Alternativen“ — mit genug Tiefe, um tatsächlich zu entscheiden.

Entscheidungsrahmen — fünf Fragen

Bevor Sie Produkte bewerten, beantworten Sie diese fünf Fragen:

1. Was ist Ihre wichtigste Workload? Nur VMs / überwiegend VMs / gemischt aus VMs und Containern / nur Container.
2. Mandantenfähigkeit? Single-Tenant / mehrere Geschäftsbereiche / Service-Provider-Modell mit Endkunden.
3. Größenordnung? <50 Hosts / 50–500 Hosts / >500 Hosts.
4. Bestehende Beziehungen? Red Hat / Microsoft / Erfahrung mit OpenStack / offen für Open Source / nur kommerzielle Anbieter.
5. Auslöser? Kosten (Broadcom-Preise), Souveränität (Aufsicht), KI-Workload, Größenordnung, Greenfield.

Ihre Antworten grenzen die realistischen Optionen auf 1–2 Kandidaten ein.

Die wichtigsten Alternativen nach Anwendungsfall

Für Service-Provider und Betreiber mandantenfähiger Clouds

Beste Wahl: Cozystack (Open Source, Kubernetes-nativ, native Mandantenfähigkeit über das Tenant CRD)

Zweitbeste Wahl: OpenStack (ausgereift, mandantenfähig über Keystone, im Telco-Maßstab bewährt; hohe betriebliche Komplexität)

Warum Cozystack vorne liegt: Das Mandantenmodell ist strukturell angelegt, nicht nachträglich angeflanscht. Eine Plattform für VMs + Container + Datenbanken + S3 + GPU. Open Source — kein Vendor-Lock-in. Geringerer Betriebsaufwand als OpenStack.

Für regulierte Unternehmen (Banken, Versicherungen, Finanzdienstleister)

Beste Wahl: Cozystack (Souveränität durch Architektur, optionale Volume-Verschlüsselung mit einer Passphrase, die Sie verwalten, auditfähig)

Zweitbeste Wahl: OpenShift Virtualization (kommerzieller Support von Red Hat, etablierte Beschaffungsbeziehungen)

Warum Cozystack bei Souveränität vorne liegt: Open-Source-Plattform auf Kunden-Hardware, Zugriff auf den Cluster kontrolliert der Kunde. Die Souveränität ist strukturell, kein „souverän mit Einschränkungen“.

Für bestehende Red-Hat- / OpenShift-Kunden

Beste Wahl: OpenShift Virtualization (KubeVirt-basiert, in bestehendes OpenShift integriert)

Zweitbeste Wahl: Cozystack (sofern die Beschaffung es zulässt; bessere Mandantenfähigkeit)

Warum OpenShift in diesem Fall vorne liegt: Bestehende Beziehung zu Red Hat / IBM, etablierte Beschaffung, vertraut für das Team.

Für KMU / Single-Tenant / Labs

Beste Wahl: Proxmox VE (ausgereift, einfache Installation, starke Community)

Zweitbeste Wahl: Scale Computing HC3 (Einfachheit einer Appliance)

Warum Proxmox vorne liegt: Open Source, große Community, gut geeignet für Single-Tenant-Installationen unter etwa 50 Hosts.

Für ROBO / Edge

Beste Wahl: Scale Computing HC3 (Appliance, für ROBO/Edge konzipiert)

Zweitbeste Wahl: Cozystack (wenn ein einheitlicher Betrieb über mehrere Standorte zählt)

Warum Scale bei reinem ROBO vorne liegt: Betriebliche Einfachheit an Edge-Standorten; konzipiert für Umgebungen ohne eigenes Infrastruktur-Team.

Für KI / GPU im großen Maßstab

Beste Wahl: Cozystack (KubeVirt + NVIDIA GPU Operator für NVIDIA-Rechenzentrums-GPUs; Passthrough ganzer GPUs an VMs, NVIDIA vGPU für VMs (erfordert Ihre NVIDIA-vGPU-Lizenz), fraktionierte Freigabe über HAMi)

Zweitbeste Wahl: OpenShift Virtualization (Red-Hat-Ökosystem mit GPU)

Warum Cozystack bei KI vorne liegt: Kubernetes-nativ bedeutet GPU-Workloads in Containern und VMs auf einer Plattform. Das Mandantenmodell bietet Platz für mehrere Data-Science-Teams. Souveränität für die Datenresidenz.

Für Microsoft-orientierte Organisationen

Beste Wahl: Azure Stack HCI (Hyper-V + Integration mit Azure Arc)

Zweitbeste Wahl: Cozystack (wenn Open Source wichtiger ist als das Microsoft-Ökosystem)

Warum Azure Stack HCI bei Microsoft-Häusern vorne liegt: Vertrautes Fundament mit Hyper-V; Azure Arc schlägt die Brücke zur Azure-Cloud; die Microsoft-Lizenzierung rechnet sich.

Für Telekommunikation und Behörden mit OpenStack-Erfahrung

Beste Wahl: OpenStack (im Telco-Maßstab bewährt)

Zweitbeste Wahl: Cozystack (geringerer Betriebsaufwand; Option zur schrittweisen Migration)

Warum OpenStack bei eingespielten Teams vorne liegt: Vorhandene Expertise, ausgereifte Distributionen der Hersteller, im Telco-Maßstab validiert.

Für reine Container-Workloads (ohne VMs)

Beste Wahl: Vanilla-Kubernetes (kleinste Plattform, geringster Overhead)

Zweitbeste Wahl: Cozystack (mandantenfähiges Kubernetes, wenn Isolation wichtig ist)

Warum reines Kubernetes vorne liegt: Ohne VMs ist die KubeVirt-Schicht überflüssig; reine Container-Plattformen sind einfacher.

Was sich wirklich von VMware unterscheidet

Für jede Alternative die architektonischen Abweichungen von VMware, die einen Neuentwurf erfordern:

Cozystack

• Netzwerk: Cilium (eBPF) ≠ NSX. Ein anderes Modell; wird während der Migration neu entworfen.
• Mandantenfähigkeit: Tenant CRD ≠ vCloud Director. Konzeptionell anders; Abbildung während der Migration.
• Betrieb: Betriebsmodell von Kubernetes; Lernkurve für das Team.

OpenShift Virtualization

• Betrieb: OpenShift ist umfangreicher als VMware; Lernkurve für das Team.
• Preise: Subscription-Modell von Red Hat.

Nutanix AHV

• Herstellermodell: Closed Source / Appliance — anders als das offene VMware-Ökosystem.
• Netzwerk: Weniger flexibel als NSX; vom Hersteller verwaltet.

OpenStack

• Betrieb: Deutlich komplexer als VMware. Realistisch, wenn das Team die Expertise hat.

Proxmox

• Mandantenfähigkeit: Begrenzt. Nur für Single-Tenant geeignet.

Scale Computing

• Obergrenze der Skalierung: Niedriger als bei VMware-Installationen in Großunternehmen.

Azure Stack HCI

• Herstellerbeziehung: An Microsoft gebunden statt an VMware — eine andere Abhängigkeit.

Überlegungen zur Migration

Für jede Alternative die Komplexität des Migrationspfads:

• VMware → Cozystack: Image-Konvertierung (qcow2 nach KubeVirt CDI). Neuentwurf des Netzwerks (NSX → Cilium). Neuentwurf des Mandantenmodells (vCD → Tenant CRD). Migration der Storage-Schicht (vSAN → LINSTOR/DRBD). Typisch: Platform Readiness Assessment von 14 oder 28 Tagen, danach rund 8–12 Monate für einen Bestand von ~100 VMs und 18–24 Monate für ~1.000 VMs, einschließlich Planung und Migrationswellen.
• VMware → OpenShift: Ähnlich wie bei Cozystack, aber auf Red-Hat-Basis.
• VMware → Nutanix: AHV-Migration über Nutanix Move (Herstellerwerkzeug). Weniger Kontrolle während der Migration.
• VMware → OpenStack: Betrieblich am komplexesten; erfordert tiefe Expertise im Team.
• VMware → Proxmox: Image-Konvertierung unkompliziert; Neuentwurf für Mandantenfähigkeit erforderlich.

Dieser Beitrag vertieft das Thema unserer Seite KMU und Mittelstand.

Der ehrliche Test

Cozystack passt, wenn mindestens drei zutreffen:

1. Regulierte Daten
2. Multi-Tenant-Modell
3. Stetig-state-Workloads
4. Internes Plattform-Team
5. KI/GPU-Workloads im großen Maßstab
6. Spezifischer Exit-Trigger

Bei 0-1: Over-Engineering. Bei 2: marginal. Bei 3+: passt.

Wenn nicht passt

• Hyperscaler-managed (AWS, Azure, GCP)
• Hetzner / OVHcloud
• Proxmox VE für on-prem

Wenn passt — Beispiele

• Mittelstand mit DORA-relevant Tochter
• Mittelstand wird Multi-Tenant SaaS
• Mittelstand mit starker Plattform-Engineering-Investition

Ænix-Engagement

• 30-minütiges Discovery-Gespräch — kostenlos, ohne Vertriebsdruck
• Platform Readiness Assessment (Festpreis, 14 Tage fokussiert) — wenn Sie eine strukturierte Bewertung wollen
• Umsetzung — nur, wenn es tatsächlich passt; im Mittelstand reicht oft selbst betriebenes Cozystack mit Enterprise-Support von Ænix

Für die meisten KMU lautet die ehrliche Antwort: Bleiben Sie, wo Sie sind.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite VMware-Migration.

Drei Migrations-Pfade

1. VMware-managed Migration — VMware HCX, Red Hat MTV
2. KubeVirt-basierte Migration — virtv2v, Forklift, KubeVirt CDI, Cozystack-spezifische Skripte
3. Lift-and-Shift in Public Cloud — VMware-on-Cloud (selten die richtige Antwort 2026)

Strategie

1. Discovery und Bewertung
2. Zielplattform produktionsreif bereitgestellt
3. Kohorten-basierte Migration
4. VCF-Verfallszeit-aligned Sequenzierung
5. Decommission

Wo Migrationen scheitern

• Zielplattform nicht bereit
• Big-Bang-Cutover-Versuch
• Datenschwerkraft ignoriert
• Networking-Redesign übersprungen
• Post-Migration-Kapazität unterschätzt

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft unsere Seite zur VMware-Alternative. Er führt durch den Wandel unter Broadcom, was eine glaubwürdige VMware-Ablösung in der Produktion tatsächlich bedeutet, und wie eine echte Migration End-to-End abläuft.

Nach Broadcom ist die VMware-Rechnung unkalkulierbar geworden. Subscription-only-Lizenzierung, verpflichtende VCF-Bündelung, Preiserhöhungen von 2-5× bei Verlängerung und das Ende der ewigen Lizenzen haben die Kalkulation für jedes Infrastruktur-Team grundlegend verändert.

Diese Veränderung hat einen dokumentierten Wandel ausgelöst — Service Provider, Banken, öffentlicher Sektor und KI/GPU-Betreiber bewerten Alternativen.

Warum die VMware-Ablösung jetzt anläuft

Drei unabhängige Druckpunkte treffen die gleiche Architektur gleichzeitig:

Kostenklippe nach dem Verlängerungszyklus. VMware-Ausgaben, die 2020-2022 akzeptabel wirkten, haben sich über mehrere Jahre kumuliert. Verlängerungszyklen treffen jetzt auf Vorstände, die diesen Verlauf nicht genehmigt haben.

Regulatorischer Druck. DORA seit Januar 2025; NIS2 in der Umsetzung in den EU-Mitgliedstaaten; sektorale Regeln im Finanzdienstleistungssektor; explizite souveräne Cloud-Mandate in Deutschland (BSI C5), Frankreich (SecNumCloud) und anderen Märkten.

KI-Workload-Ökonomie. GenAI-Inferenz im großen Maßstab hat Egress-, GPU-Pricing- und Datenresidenz-Profile, die Hyperscaler nicht optimiert haben.

Architektur-Mapping: VMware → Cozystack

Zwei Bereiche erfordern Redesign anstelle eines 1:1-Mappings: Networking (Cilium ist grundlegend anders als NSX) und Multi-Mandanten-Modell (Cozystack-Mandanten sind Kubernetes-nativ).

Wie eine echte VMware-Migration abläuft

Migrationspfade sind workload-abhängig. Für die meisten Teams ist dies die realistische Reihenfolge.

1. Discovery und Assessment

Strukturierte Bewertung des aktuellen vSphere/VCF/vCD-Bestands: Workload-Anzahl, OS-Mix, vSAN/NSX-Abhängigkeiten, Integrationen, Mandantenmodell.

2. Cozystack parallel deployed

Cozystack wird auf neuer oder umgewidmeter Hardware neben dem bestehenden VMware-Bestand installiert. Kein Big-Bang-Cutover.

3. VM-für-VM-Image-Migration zu KubeVirt

Für die meisten VMs ist die Migration eine Disk-Image-Kopie. KubeVirt CDI plus ein Set spezieller Migrations-Skripte. Für Windows-VMs läuft ein automatischer Cleanup-Pass vor dem Boot auf KubeVirt.

4. Netzwerk- und Speicher-Cutover

Networking: VLAN-Mapping in Cilium mit Policy-Parität gegen NSX-Regeln. Storage: Disks in LINSTOR importieren.

5. Validierung und DR-Cutover

Jede migrierte Workload läuft parallel auf Cozystack bis zur Validierung. Vor dem finalen Cutover stehen Backup und Wiederherstellung mit Velero und PostgreSQL PITR plus geübte Runbooks; ein orchestriertes standortübergreifendes Failover wie bei SRM gibt es nicht.

6. VMware-Decommission

Lizenzen enden zu ihren eigenen Bedingungen. Hardware in den Cozystack-Cluster umgewidmet.

Souveränität-by-Architecture

Cozystack ist Open Source unter Apache 2.0. Ihre Binaries, Ihre Hardware, Ihre Datenebene. Ænix liefert Air-Gap-Installations-Workflows und ein Supportmodell, bei dem Sie den Zugriff bestimmen: Beratung und GitOps-PR-Review ohne Clusterzugriff, Fernzugriff nur mit Ihrer Freigabe.

Architektonische Implikationen:

• Tenant CRD — jeder Mandant ist ein Kubernetes-Objekt
• Air-Gap-Install unterstützt
• Kein Phone-Home — Telemetrie ist standardmäßig deaktiviert
• Auf DORA/NIS2 ausgerichtete Kontrollen — operative Resilienz, Dokumentation des Lieferantenrisikos
• Ænix-Supportmodell — Zugriff nach Ihrer Wahl: Beratung, Runbooks und GitOps-PR-Review ohne Clusterzugriff; Fernzugriff auf Ihre Cluster mit Ihrer Freigabe und externes Monitoring in den höheren Support-Stufen

Migrations-Zeitplan

Nach einem Platform Readiness Assessment von 14 oder 28 Tagen:

• Rund 100 VMs: rund 8–12 Monate, einschließlich Planung und Migrationswellen
• Rund 1.000 VMs: 18–24 Monate, in Kohorten
• Dazwischen: je nach Abhängigkeiten zwischen diesen beiden Werten

Treiber sind Regressionstests und Parallelbetriebsfenster, nicht die reine Kopiergeschwindigkeit.

Wie geht es weiter?

Für eine spezifische Bewertung Ihres VMware-Ausstiegs siehe fokussierte Seite zur VMware-Alternative oder Platform Readiness Assessment.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts — CNCF Certified Kubernetes Distribution.

Dieser Beitrag vertieft das Thema unserer Seite Transport und Logistik.

Drei Druckpunkte

1. NIS2: Sektor nach Anhang I (wesentliche oder wichtige Einrichtung, je nach Größe)
2. KI-Optimierung
3. Edge-Compute-Dichte

Three-Tier-Architekturmuster

• Zentrale Cloud — TMS, Fleet-Management, KI-Training
• Regionale Standorte — operative Zentren, regionale Disposition
• Edge — Depots, Häfen, Terminals, On-Vehicle-Compute

NIS2-Architekturkontrollen für Transport

Übliche Zuordnung zu Artikel 21 und 23; dazu transportspezifisch:

• Multi-modale Datensouveränität
• Sub-Lieferanten-Transparenz (Logistikketten 5+ Ebenen)
• Notfallplanung für physische Störungen
• Air-gap für sicherheitskritische OT

KI-Use-Cases im Transport

• Routenoptimierung
• Nachfrageprognose
• Predictive Maintenance für Flotte
• Last-Mile-Optimierung
• Customer-facing KI (Lieferzeit, Kundenservice)

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite Energiewirtschaft.

Drei Druckpunkte konvergieren auf Energie-Infrastruktur

1. NIS2-Compliance mit operativer Realität
2. KI für Netzoperationen
3. Edge-Compute an Substation-Dichte

Three-Tier-Referenz-Architektur

• Zentrale Cloud — EMS, KI-Training, Marktintegration
• Regionale Standorte — SCADA-Aggregation, regionale Netzführung
• Umspannstation-Edge — lokale SCADA / RTU-Integration, Air-gapped OT-Boundary

IT/OT-Konvergenz mit Grenzen

• Strikte Grenze: OT-Zone — Air-gapped, OT-bewusste Cybersicherheit
• Permeable Grenze: IT-Zone — Standard-Cloud-native operativ
• Brücke: Datenfabric — kontrollierte Datenflüsse OT→IT

NIS2-spezifische Architekturkontrollen

• Risikoregister pro kritische Funktion
• 24-Stunden-Zeitfenster Erkennungsfähigkeit
• Geschäftskontinuität getestet
• Lieferanten-Transparenz bis zum zweiten Hop
• Verschlüsselung mit kundenkontrollierten Schlüsseln

KI-Workloads auf Netzbetriebsdaten

• Lastprognose
• Erzeugungsprognose (besonders für Erneuerbare)
• Predictive Maintenance
• Demand-Response-Automatisierung
• Marktpreis-Optimierung

Typische Hardware-Größe für mittelgroßen Energieversorger (5-10 GW): 16-64 GPUs.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite Cloud Repatriation.

Repatriation ist nicht alles-oder-nichts

Typischer repatriierter Bestand:

• 30-50% on-prem oder Private Cloud (steady-state, reguliert, teuer, latenz-kritisch)
• 30-50% bleibt in Public Cloud (elastisch, hyperscaler-proprietär, latenzempfindlich)
• 10-20% in Übergang

Fünf-Schritte-Playbook

1. Ehrliche TCO-Modellierung — alle versteckten Kosten erfasst
2. Workload-Klassifikation — repatriate now / later / stay / reassess
3. Zielarchitektur — vollständige Plattform mit Ops-Modell
4. Cutover-Sequenzierung — respektiert Commitment-Verfallszeiten
5. Plattform betreiben — nach der Migration

Häufige Fehler

• Wishful TCO ohne Hardware-Refresh / Plattform-Team-Kapazität
• Zielarchitektur als Gedanke später
• Datenschwerkraft als Checkbox
• Vollumfänglicher Ausstieg, wenn selektiv die richtige Antwort ist

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite Proxmox-Alternative.

Drei Hauptoptionen für Open-Source-fähige Virtualisierung im Jahr 2026: Proxmox VE, VMware (nach Broadcom) und Cozystack. Jede hat ein anderes architektonisches Ziel.

Proxmox VE — SMB-fokussiert

Architektur: KVM + LXC + ZFS + Ceph (Community). Beste Wahl für SMB-IT, Labs, single-tenant Bereitstellungen.

VMware (Post-Broadcom) — enterprise legacy

Architektur: vSphere + vSAN + NSX + vCD. Beste Wahl für bestehende VMware-Bestände bis zur Renewal-Krise.

Cozystack — Open Source, Kubernetes-nativ

Architektur: KubeVirt + Cilium + LINSTOR + Tenant CRD + Cozystack Dashboard. Beste Wahl für Service Provider, regulierte Mandanten, KI/GPU.

Wie wählen

1. <50 Hosts, single-tenant, mostly VMs → Proxmox VE
2. Service Provider, Multi-Tenant Cloud → Cozystack
3. Bestehende VMware-Investition stabil → bleiben (mit Exit-Plan)
4. KI/GPU im großen Maßstab → Cozystack

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite Kubernetes-Beratung.

10 Architekturentscheidungen, die zählen

1. Distribution (vanilla / OpenShift / Cozystack / vendor-led)
2. Multi-Tenancy (soft, hard via Tenant CRD, cluster pro tenant)
3. Networking / CNI (Cilium ist 2026 Standard)
4. Storage (LINSTOR, Ceph, vendor SAN)
5. Identität und Secrets
6. GitOps-Engine (Argo CD oder Flux)
7. Observability-Stack (VictoriaMetrics + VictoriaLogs)
8. Backup und DR (Velero + per-app PITR)
9. Ingress und Load Balancing
10. Lifecycle-Management

Operative Praktiken

• SLOs und Error Budgets
• Dokumentierte Runbooks
• Capacity Planning
• Upgrade-Disziplin (Kubernetes minor jedes Quartal)
• Incident Response
• Sicherheitsposture (Pod Security Standards, Network Policies)

Häufige Fehler

• Dev-Cluster auf Prod skaliert
• Kein Observability-Budget
• Sicherheit als Nachgedanke
• Upgrade-Schulden
• Kein Plattform-Team

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Überblick über Private-Cloud-Anbieter und -Plattformen im Jahr 2026 — was verfügbar ist, wer was bietet, welche architektonischen Trade-offs. Mehr dazu auf unserer Seite Private Cloud.

Die Private-Cloud-Landschaft hat sich in den letzten 3 Jahren erheblich verändert. Broadcom-induzierte VMware-Migrationen, Souveränitätsmandate, KI-Workload-Ökonomie und FinOps-Druck haben alle die Bedeutung von „Private Cloud“ und ihre Anbieter neu geformt.

Zwei verschiedene Begriffe für „Private Cloud“

• Private-Cloud-Plattform — Software, die Sie auf Ihrer eigenen Infrastruktur deployieren. Beispiele: VMware VCF, Cozystack, OpenStack, OpenShift Virtualization, Proxmox VE.
• Private-Cloud-Anbieter — ein Anbieter, der dedizierte Infrastruktur (single-tenant) bereitstellt, die Sie konsumieren. Beispiele: IBM Cloud Private, Oracle dedizierte Regionen, Hyperscaler „souveräne“ Regionen, regionale Cloud-Anbieter.

Open-Source-Plattformen

Cozystack

Apache-2.0-Lizenz, CNCF-Projekt. KubeVirt + Cilium + Kube-OVN + LINSTOR/DRBD + Tenant CRD + Cozystack Dashboard. Beste Wahl für Service Provider, regulierte Mandantenfähigkeit, AI/GPU-Betreiber. Stärken: Single-Stack für VMs + Container + DBs + S3 + GPU. Mandantenfähigkeit strukturell.

OpenStack

Apache-2.0-Lizenz, OpenInfra Foundation. Nova + Neutron + Cinder + Swift + Keystone. Beste Wahl für große Telekommunikations-Cluster, behördliche Clouds, OpenStack-erfahrene Teams. Stärken: Reif, breite Community, viele Vendor-Distributionen.

Proxmox VE

AGPLv3 + kommerzielle Subscription. KVM + LXC + ZFS + Ceph (Community). Beste Wahl für SMB-Virtualisierung, Labs, single-tenant. Stärken: Reif, einfach zu installieren, starke Community.

Kommerzielle Plattformen

VMware (VMware Cloud Foundation)

Subscription-only nach Broadcom. Wann sinnvoll: bestehende VMware-Bestände, die noch nicht durch Ökonomie aus dem Markt gedrängt sind. Limits: Subscription-Preisanstiege (2-5× beobachtet), Vendor-Lock-in, Souveränitätsbedenken.

Nutanix

Subscription, mehrere Tarife. AHV (proprietär KVM-basiert). Wann sinnvoll: bestehende Nutanix-HCI-Kunden. Limits: Closed source, Appliance-Lock-in.

OpenShift Virtualization (Red Hat)

Red Hat kommerzielle Subscription. Wann sinnvoll: bestehende Red Hat / OpenShift-Kunden.

Souveräne Hyperscaler-Regionen und regionale Anbieter

• AWS Sovereign Cloud, Azure Sovereign, GCP — Hyperscaler-souveräne Angebote
• Hetzner (Deutschland) — Bare Metal + Cloud, beliebt in DACH
• OVHcloud (Frankreich) — starke EU-souveräne Positionierung
• Regionale Anbieter mit der Ænix Public Cloud Platform — Hosting-Anbieter, die ein souveränes Cloud-Produkt auf Basis von Cozystack verkaufen

Trade-off: vom Anbieter verwalteter Komfort gegen direkte Kontrolle über die Hardware.

Wie wählen

1. Multi-Tenant + Open Source + Kubernetes-nativ + Souveränität? → Cozystack
2. Bestehender VMware-Bestand mit Renewal-Druck? → VMware-Ausstieg planen, Ziel meist Cozystack oder OpenShift
3. OpenStack-Expertise + große Telco/Behörden-Skala? → OpenStack bleibt valide
4. Bestehende Red Hat / OpenShift-Verpflichtungen? → OpenShift Virtualization
5. SMB / single-tenant? → Proxmox VE
6. Plattform nicht selbst betreiben wollen? → Regionaler souveräner Cloud-Anbieter (Hetzner, OVHcloud oder ein regionaler Anbieter mit der Ænix Public Cloud Platform)
7. KI/GPU im großen Maßstab, sustained utilization? → Cozystack oder OpenShift auf dediziertem GPU
8. Souveränität + EU + niedriger operativer Footprint? → Cozystack mit Ænix-Support

Migrationspfade

• VMware → Cozystack/OpenStack/OpenShift — KubeVirt-basierte Migration, Image-Konvertierung, Multi-Mandanten-Redesign
• Public Cloud → Private Cloud (Repatriation) — Workload-Klassifikation, ehrliche TCO, Zielarchitektur

Nächste Schritte

Wenn Cozystack zu Ihrer Situation passt — siehe unsere Seite Private Cloud oder besuchen Sie cozystack.io.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite Sovereign AI.

Drei Trigger-Profile für Private LLM

1. Regulierte Datenklasse — Daten unterliegen Jurisdiktions-Bindung
2. Inferenz-Wirtschaftlichkeit — sustained Workloads bei stetiger Auslastung
3. Auditbereitschaft und Reproduzierbarkeit — Aufsichtsdialoge erfordern dies

Sechs Schichten eines Private-LLM-Stacks

1. Hardware (GPUs, CPU, Netzwerk, Storage)
2. Plattform (Kubernetes + KubeVirt + Cilium + LINSTOR)
3. Serving (vLLM, Triton)
4. Modellschicht (Llama, Mistral, Qwen, DeepSeek, Phi, Gemma)
5. Anwendungsschicht (RAG, Agent-Frameworks, LLM-Gateway)
6. Operations (Observability, Audit, Cost Management)

Architektonische Muster

• Single-Tenant-Inferenz-Cluster
• Multi-Tenant-Inferenz-Flotte
• Inferenz + Fine-Tuning + RAG (vollständige KI-Plattform)
• Air-gapped souveräne Bereitstellung

Wie geht es weiter?

Strukturierte Bewertung → Platform Readiness Assessment.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite Platform Engineering. Wo überlappen sich die drei Begriffe, wo nicht, was tut jede Funktion tatsächlich.

Drei Definitionen

DevOps ist eine kulturelle und operative Praxis innerhalb von Produkt-Teams. Das gleiche Team baut und betreibt die Software in Produktion.

SRE (Site Reliability Engineering) ist eine Disziplin, die Software-Engineering auf Operations anwendet — mit SLOs, Error Budgets und Toil-Begrenzung.

Platform Engineering ist die Praxis, interne Plattformen zu bauen, die Produkt-Teams konsumieren. Eine separate Funktion, deren Kunden andere Engineering-Teams sind.

Wo sie sich überlappen

Alle drei kümmern sich um:

• Zuverlässigkeit (SLOs, Error Budgets)
• Tooling (CI/CD, IaC, Observability, Identity)
• Geschwindigkeit
• Operative Exzellenz

Wo sie sich unterscheiden

Wann jedes passt

• DevOps allein: kleine Organisationen, 1-3 Produkt-Teams
• DevOps + SRE: mittelgroße Organisationen mit Reliability-Bedenken
• DevOps + Platform Engineering: mittlere bis große Organisationen mit Self-Service-Bedarf
• Alle drei: große Organisationen

Was Platform Engineering tatsächlich baut

1. Internal Developer Platform (IDP)
2. Golden Paths
3. Operatives Modell
4. Internes Produktmanagement

Wie geht es weiter?

Platform Readiness Assessment für eine strukturierte Bewertung.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite NIS2.

Artikel 21 — Risikomanagement-Maßnahmen

10 erforderliche Bereiche, die jede betroffene Einrichtung abdecken muss:

1. Risikoanalyse und Informationssystem-Sicherheit
2. Vorfall-Handhabung
3. Geschäftskontinuität (Backup, DR, Krisenmanagement)
4. Lieferkette-Sicherheit
5. Sicherheit in Acquisition / Development / Maintenance
6. Effektivitäts-Bewertung
7. Cyber-Hygiene und Cybersicherheits-Training
8. Kryptographie (Verschlüsselung)
9. Personalsicherheit, Zugriffskontrolle, Asset-Management
10. MFA, sichere Kommunikation, sichere Notfall-Kommunikation

Artikel 23 — Vorfall-Reporting-Zeitfenster

• 24 Stunden — Frühwarnung an CSIRT
• 72 Stunden — vollständige Vorfall-Meldung
• 1 Monat — Abschlussbericht

Die Architektur muss Erkennung und Reporting innerhalb dieser Zeitfenster unterstützen.

Architektonische Anforderungen

• Multi-Schicht-Datenresidenz
• Customer-controlled Verschlüsselungsschlüssel
• Lieferantenketten-Transparenz bis zum zweiten Hop
• Audit-Logs in Standardformaten
• Aufsichtszugang dokumentiert und getestet

Wie geht es weiter?

Platform Readiness Assessment mit NIS2-Schwerpunkt.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.

Dieser Beitrag vertieft das Thema unserer Seite MSPs.

Architektur-Muster

• Multi-Tier Tenant CRD (Root-Tenant → MSP → MSP-Kunden)
• Pro-Tier-Isolation
• Gebrandetes kundenorientiertes Portal
• Abrechnung über die WHMCS-Integration (proprietäres Ænix-Modul)
• Service-Katalog (MSP kuratiert)

Reseller-Wirtschaftlichkeit

Mittelgroßer MSP (50-500 Kunden):

• Plattform-Kosten + Hardware + Operations
• Pro-Kunde-Inkrementelle Kosten
• MSP-Kunden-Pricing typisch 30-50% über Plattform-Rohkosten
• Break-even: 30-50 zahlende Kunden

Engagement-Sequenz

1. Platform Readiness Assessment (14 oder 28 Tage)
2. Plattform live über den produktisierten Installer (wenige Wochen nach Bereitstellung der Hardware), danach Pilot
3. Initiale Kunden-Kohorte (5-10 Kunden)
4. Operations-Workflow
5. Skalierung

Gesamtzeit: 6-12 Monate.

Ænix hat Cozystack entwickelt und gehört zu den Maintainern des CNCF-Projekts.