KubeCon in Amsterdam. Again. And honestly? There are worse places to talk about Kubernetes, cloud-native architectures, and all the fun problems we keep creating for ourselves đ If you are into K8s, or wanting in… BE THERE! There is no excuse đ
From March 23â26, the cloud-native circus lands in Amsterdam, and Iâll be there for the full ride â hanging out at the Portworx booth, presenting, and always ready for conversations about Kubernetes, persistent storage, resilience, DR, and all the âbut what ifâŠâ scenarios that inevitably come up once things around persistency get real. Yes people, we HAVE a whiteboard at the booth đ€đ
If youâve ever built something in Kubernetes that looked great on a whiteboard but became⊠interesting in production, chances are weâll have something to talk about.
Cloud-Native is easy. Until it isn’t.
Spinning up Kubernetes clusters has never been easier. Managed services, installers, templates, GitOps â pick your poison. The hard part usually starts after day one, especially when persistent data gets in the game:
- Where does my data live?
- How do I move it?
- How do I protect it?
- And what happens when (yes, when… not if) something breaks?
Stateless workloads get all the love, it is what K8s was designed for. But “state” is becoming more and more “a thing”. Databases, message queues, AI pipelines, legacy apps that âjust need a PVCâ â they all show up eventually. And suddenly, storage isnât boring anymore. Things get even more intersting with people wanting to move their Virtual Machines into the realm of Kubernetes using KubeVirt… Where persistency for containers is a “probably”… persistency for VMs is a MUST!
Persistent Storage in K8s: Still not a solved problem. Or is it?
Kubernetes likes things in 3âs. Storage, data centers, regions⊠not so much. We still see people stretching clusters, bending quorum rules, or inventing creative failure domains that technically work â until they donât đ. Others run multiple clusters and then realize that moving data is very different from moving YAML.
This is exactly the space where solutions like Portworx come into play (yes, disclaimer: #Iwork4Portworx). Replication across clusters; async or sync, application-consistent snaps and backups, disaster recovery that doesnât involve crossing fingers or slaughtering goats. Huge savings when running in public cloud, and a million other tidbits worth discussing.
And no, this isnât just for greenfield, cloud-only, unicorn architectures. Portworx lives right inside Kubernetes, building out a software-defined storage (SDS) layer. It’s like a storage array, but in software!
Kubernetes, VMware and REALITY.
Despite what Twitter (no one seems to call it “X”) might tell you, many organizations are still running Active-Active metro setups, often on VMware. And guess what? Theyâre running containers there too.
Kubernetes doesnât magically erase years of operational reality. It has to coexist with it.
If youâre navigating:
- Persistent Kubernetes on-prem or in public cloud
- Persistent Kubernetes across sites / clouds
- Kubernetes alongside existing VMware investments
- Kubernetes slowly replacing VMware as a VM platform
- Or Kubernetes where âjust rebuild itâ is not an acceptable DR strategy
Then yes â those are exactly the kinds of conversations Iâll love to have at KubeCon!
Letâs Talk (Seriously)
KubeCon isnât just about sessions and keynotes. Itâs about the real conversations!
- What actually works
- What sounds good but hurts later
- And how people are really running stateful workloads at (sometimes huge) scale
So if youâre attending KubeCon EU 2026 in Amsterdam, swing by the Portworx booth. Whether you want to talk storage architectures, disaster recovery, multi-cluster Kubernetes, or just vent about quorum math â Iâm there.
No hard pitches (well maybe just the one đ ). Mostly just practical cloud-native conversations.
See you in Amsterdam đłđ± ??
BTW… You can register for KubeCon EU 2026 by clicking the image below:
