Future Proof Tech Briefing · September 2026

The Mediator Between Worlds

Reading time: 4 minutes

A personal note: why I joined Portworx and what it means for this newsletter.

A person stands at a crossroads in a wasteland; glowing lines connect server racks, a cloud, a container port and virtual cubes on the horizon.

AI-generated (Gemini)

A personal note up front: since September 16 I have been working as a Cloud Native Architect at Everpure, on the team around Portworx. Anyone reading this newsletter should know that before the next RAMmageddon part appears. The analyses will remain what they have been. Wherever there is a connection to my employer in future, I will flag it.

Today is about why I made this move. The short answer: because I take my own thesis seriously.

Four open flanks

For months I have been writing here about scarcity. DRAM, NAND, servers: everything is getting more expensive and harder to plan. At the same time, many organizations are questioning their platform decisions: the hypervisor after the Broadcom changes, the Kubernetes distribution, the hyperscaler. That makes four open flanks at once: hardware, virtualization, container platform, cloud. And hardly anyone can credibly say today where they will stand in three years.

In this situation, the decisive question is not which platform is the right one. It is: what do I have to do now so that I can still change my mind later? Those who look for no answer and simply leave the four flanks open end up where I described it in Part 10: in the DigitalWasteland, which is not created by decisions but by their absence.

Applications are portable, data is not

Since containers, applications can be moved. Data cannot. That is exactly where the migration projects arise that burn budgets and nerves. Portworx starts at this point, and that is why I see it as a mediator between worlds.

Downward, Portworx Enterprise is independent of the infrastructure. It runs as software on the worker nodes of a Kubernetes cluster and pools whatever lies beneath: local NVMe drives, LUNs from any storage array, or block storage from a hyperscaler. The result is one shared pool.

Upward, it speaks pure Kubernetes. Applications request storage through StorageClasses and Persistent Volume Claims, connected via the CSI standard. Replication, snapshots, encryption, backup and disaster recovery are tied to the data layer, not to the hardware and not to the distribution. Whether OpenShift, SUSE Rancher, upstream Kubernetes or a managed service such as EKS, AKS or GKE runs on top makes no difference to how the data is handled. Applications can be moved together with their data from one cluster to another, across distribution and cloud boundaries.

For virtual machines, too

With KubeVirt, whether as OpenShift Virtualization or SUSE Virtualization, VMs run alongside containers on Kubernetes. Anyone who wants to replace their hypervisor does not have to containerize every application first. And on the data layer they get the capabilities they know from the old world, such as live migration.

And in the public cloud

Cloud block storage is traditionally booked per application and in advance. With thin provisioning, a shared pool and automatic expansion, you pay closer to what is actually used. How large the effect is in each case depends on workload, replication and licensing. I am in my first week and will not promise percentages here that I have not calculated myself.

The caveat belongs here

All of this assumes that Kubernetes becomes the operating layer. And it means committing to a data layer. I consider that the right trade: you accept one dependency in order to free yourself from four others.

So here is my thought for everyone currently facing the platform question without being able to answer it yet: you do not have to answer it first. Those who settle the data layer early spare themselves a large share of the migration and porting pain, no matter how the decision turns out later, and even if it has to be made a second time.

My RAMmageddon parts have been ending on the same thought for a while: act from a position of control, not under pressure. That is the reason for my move. I want to work on the layer that gives that control back.

The details, from KubeVirt to the cloud cost calculation, will follow in dedicated deep dives. Today was only about the why.

Jens Klasen writes in the Future Proof Tech Briefing about the upheaval in enterprise IT. You can find all previous installments in my newsletter and at klasen.ai.