Future Proof Tech Briefing · September 2026
Der Vermittler zwischen den Welten
In eigener Sache: Warum ich zu Portworx gegangen bin und was das für diesen Newsletter bedeutet.
KI-generiert (Gemini)
In eigener Sache vorweg: Seit dem 16. September arbeite ich als Cloud Native Architect bei Everpure, im Team rund um Portworx. Wer diesen Newsletter liest, soll das wissen, bevor der nächste RAMmageddon-Teil erscheint. Die Analysen bleiben, was sie waren. Wo künftig ein Bezug zu meinem Arbeitgeber besteht, kennzeichne ich ihn.
Heute geht es um die Frage, warum ich diesen Schritt gemacht habe. Die kurze Antwort: weil ich meine eigene These ernst nehme.
Vier offene Flanken
Seit Monaten schreibe ich hier über Knappheit. DRAM, NAND, Server, alles wird teurer und schwerer planbar. Parallel stellen viele Unternehmen ihre Plattformentscheidungen infrage: den Hypervisor nach den Broadcom-Änderungen, die Kubernetes-Distribution, den Hyperscaler. Das sind vier offene Flanken gleichzeitig: Hardware, Virtualisierung, Container-Plattform, Cloud. Und kaum jemand kann heute seriös sagen, wo er in drei Jahren stehen wird.
In dieser Lage ist die entscheidende Frage nicht, welche Plattform die richtige ist. Sie lautet: Was muss ich jetzt tun, damit ich mich später noch umentscheiden kann? Wer darauf keine Antwort sucht und die vier Flanken einfach liegen lässt, landet dort, wo ich es in Teil 10 beschrieben habe: im DigitalWasteland, das nicht durch Entscheidungen entsteht, sondern durch deren Ausbleiben.
Anwendungen sind portabel, Daten nicht
Seit Containern lassen sich Anwendungen verschieben. Daten nicht. Genau dort entstehen die Migrationsprojekte, die Budgets und Nerven kosten. Portworx setzt an dieser Stelle an, und deshalb sehe ich es als Vermittler zwischen den Welten.
Nach unten ist Portworx Enterprise unabhängig von der Infrastruktur. Es läuft als Software auf den Worker Nodes eines Kubernetes-Clusters und fasst zusammen, was darunter liegt: lokale NVMe-Laufwerke, LUNs eines beliebigen Storage-Arrays oder Block-Storage eines Hyperscalers. Daraus wird ein gemeinsamer Pool.
Nach oben spricht es reines Kubernetes. Anwendungen fordern Speicher über StorageClasses und Persistent Volume Claims an, angebunden über den CSI-Standard. Replikation, Snapshots, Verschlüsselung, Backup und Disaster Recovery hängen an der Datenebene, nicht an der Hardware und nicht an der Distribution. Ob darüber OpenShift, SUSE Rancher, ein Upstream-Kubernetes oder ein Managed Service wie EKS, AKS oder GKE läuft, ändert am Umgang mit den Daten nichts. Anwendungen lassen sich samt Daten von einem Cluster in einen anderen verschieben, auch über Distributions- und Cloud-Grenzen hinweg.
Auch für virtuelle Maschinen
Mit KubeVirt, ob als OpenShift Virtualization oder SUSE Virtualization, laufen VMs neben Containern auf Kubernetes. Wer seinen Hypervisor ablösen will, muss dafür nicht erst jede Anwendung containerisieren. Und er bekommt auf der Datenebene die Funktionen, die er aus der alten Welt kennt, etwa Live Migration.
Und in der Public Cloud
Cloud-Block-Storage wird klassisch pro Anwendung und auf Vorrat gebucht. Mit Thin Provisioning, einem gemeinsamen Pool und automatischer Erweiterung zahlt man näher an dem, was tatsächlich belegt ist. Wie groß der Effekt im Einzelfall ist, hängt von Workload, Replikation und Lizenz ab. Ich bin in der ersten Woche und werde hier keine Prozentzahlen versprechen, die ich nicht selbst nachgerechnet habe.
Die Einschränkung gehört dazu
Das alles setzt voraus, dass Kubernetes die Betriebsschicht wird. Und man bindet sich damit an eine Datenebene. Ich halte das für den richtigen Tausch: Man geht eine Abhängigkeit ein, um sich von vier anderen zu lösen.
Deshalb mein Gedanke für alle, die gerade vor der Plattformfrage stehen und sie noch nicht beantworten können: Man muss sie nicht zuerst beantworten. Wer die Datenebene früh klärt, erspart sich einen großen Teil der Migrations- und Portierungsschmerzen, egal wie die Entscheidung später ausfällt, und auch dann, wenn sie ein zweites Mal fällt.
Meine RAMmageddon-Teile enden seit einiger Zeit mit demselben Gedanken: aus einer Position der Kontrolle heraus handeln, nicht aus Druck. Das ist der Grund für meinen Wechsel. Ich will an der Schicht arbeiten, die diese Kontrolle zurückgibt.
Die Details, von KubeVirt bis zur Cloud-Kostenrechnung, folgen in eigenen Deep Dives. Heute ging es nur um das Warum.
Jens Klasen schreibt im Future Proof Tech Briefing über den Umbruch in der Enterprise-IT. Alle bisherigen Teile findet ihr in meinem Newsletter und auf klasen.ai.