1:00:25 Webinar
The Containers Must Flow: Extending Kubernetes Principles to Your Data
For July 2026, your Kwisatz Haderach of hosts, Andrew Miller, invites mentat James McShane to explore these tectonic shifts—and why Portworx® is even more vital today than 5+ years ago when acquired by Everpure, formerly Pure Storage® to be the ultimate k8s data layer.
This webinar first aired on July 7, 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Hello and welcome to this month's Coffee Break, The Containers Must Flow: Extending Kubernetes Principles to Your Data. As always, I'm your host, Andrew Miller, Lead Principal Te- Technology Strategist, actually, here at Everpure, joined by James, Consulting Cloud Native Architect. Man, we all have long titles, but, you know, they, they all mean something, hopefully, kind of thing.
That's right. That's right. And we are And in case you were And for those of you who are Dune fans, hopefully you enjoyed the abstract, you'll enjoy some as we go along. If you're not Dune fans, we try not to totally overdo it, but we're gonna be talking about things, but some of James' background, changes in the technology landscape.
Man, they keep coming. Data loss is something that we need to protect against, the litany against data loss, and the voice of Portworx. So diving right in this month, as always, this is a series, the Coffee Break series. We are roughly about five and a half years in, give or take, something like that. You can find all of the previous episodes online at p- actually, this link, as well as
everpuredata.com/events, which makes me realize I really need to update where it says here, purestorage.com/events, but you can find all the previous ones. We, you know, sort of staged transition from Pure Storage to Everpure for those, the folks that join us know. Next month, we'll be joined by, if you remember Anthony Nocentino, one of his peers, Andy Yoon, will be joining us for, and I'm not
even gonna try and say the song, but Ch-Ch-Changes: Navigating the Tsunami Reshaping the Data Industry. This is gonna be kind of a database and data-focused Coffee Break, but also of Andy's history with key mentoring lessons, value of soft skills in a very technical role, as well as keeping up with business as usual from a database and DBA landscape.
Some of it, I think, frankly, chatting with him, some DBAs were hoping the AI tsunami would kind of crest and wash over them, but you can't really do that, as well as his top tips at, at Everpure for DBAs and databases, and then what's new in the database landscape. If you joined us last month at Pure Accelerate, thank you. Charles, I know out there did.
Maybe some other folks too. But you can actually find at our website all of the, a, a huge amount of information as well as the keynote videos from day one and day two. And actually, later this month, it's gonna be on July 17th, I think Tatiana's gonna drink, drop the link in chat there, JD and myself will be actually reprising a session that we
did at Accelerate about all the different announcements, but in a really short version. Instead of 45 minutes, we'll do as, like, 10, and then it'll be in the ask us everything format, where it is literally ask us about anything. It's meant to be more a Q&A-focused webinar, than it is. We're more presentation or podcast, like this is today.
And of course, make sure to join the Everpure community, purecommunity.purestorage.com. And maybe you're here for the drawing. Yes, there is still a drawing. It is a Everp- it's a coffee lover set with a mug as well as a charging pad, 'cause you charge and drink coffee at the same time, or something like that. I don't know.
Either way, but there's a drawing at the end. Hopefully, you're around for more than that. As always, I am your host, Andrew Miller. I usually don't introduce myself very much, just because you see me every month. But I think about Kubernetes specifically, and this is when we were preparing. I think I pulled one out that James, you were like, "Ooh, I didn't know he was gonna go all
the way back to Solaris zones." But thinking about that- Yeah and even some early isolation things that you would do on Linux kind of thing, back when I was, actually part owner of a web hosting company, it was, like, 15, 20 years ago, you know, kind of thing. But more importantly, I'm joined by James. Well, we're gonna talk about some of James' background.
So he's a, he's a human too. So James, if you don't mind introducing yourself, please. Yeah. Thanks, Andrew. My, as, as you said, my name is James McShane. I'm a consulting cloud native architect here with the Portworx team.
I come from a background where I, I'll say I got a little lucky and my, my career led me into the Kubernetes domain, over a decade ago at this point, and started working with organizations that needed to deploy software in that model, and, have kind of traversed that landscape ever since, and through a number of different organizations, from consulting, building platforms, and now being a part of a number of organizations that are,
building platforms with Portworx. So it's been, you know, from a human perspective, I live outside of- Cincinnati, Ohio, and, I got three, three great kids. Been married for about, 14 years, last week. So that's been, we got a- Good for you a great little place out here. Yeah.
And, yeah, just, really enjoy, the people here at Pure, and I love talking about, about Kubernetes. I gotta ask, you say teaching your kids board games. This is putting you on the spot. What would be the most recent, the most popular, whichever one? Just pick one. You know, what's out there?
We're, you know, we're playing chess with my 10 and 7-year-old right now, and, trying to, trying to get them up to speed a little bit more. My, my older one w- really So, my, my older one is, we got really obsessed with the, the game What Do You Meme?, which is an apples to apples variant, with memes. So I, I think that tells you enough about how much internet I use on a daily basis.
Love it. Okay. So diving in, this month, we are gonna be talking about, like it stop, says, the containers must flow, extending Kubernetes principles for, to your data. As always, it's a little bit of the same agenda format, not too much, but a little bit of a tagline. You know, we went from, in some cases,
scarcity to abundance, at least as far as containers go. There's scarcity in lots of other regions. We're gonna go through four sections. First, a little bit of James background, your background from when a large scale virtualization to huge Kubernetes clusters, even some cool drone stuff in there.
The path of the Mentat. If you're wondering, is that a typo? No. Mentat is a human computer in Dune, because actually artificial intelligence was banned. Go read the first book. Maybe watch the movie. Read the book better. Okay.
Read, read the first book. A second book. Yeah. Like, they, they maybe go downhill after the first book, but the first book is great. That, that's maybe all you need, I think. The weirding way of modern tech, so virtualization and application explosion. Third, the litany against data loss.
This is that fear is the mind killer, that's the reference there, the litany against data loss. Kubernetes design principles, and of course, that's, as always, we do the first half is gonna be more agnostic, more educational, hopefully kind of entertaining, get some stories in there. And then we'll start to wander to both how we
think about Kubernetes design as it relates to data especially, and how our port work fits in there, to be very upfront. And then we're not standing still, so the voice support work's not standing still. There's some new developments, maybe one thing in there you might not expect as it relates to KubeVirt and key capabilities that you need if you're gonna be doing, you know, KubeVirt.
But also new items that we just put out on Accelerate last month, actually. Actually, yes, it is last month. The days and months blur. But before we dive in, Tatiana, you mind tossing up poll number one, if that's all right? So, two questions here.
A little bit of, you know, having more fun, and it's always sad 'cause I There's a setting here where hosts and panelists can't vote. So, you know, d- if you're, if you're wondering if, if we're stacking the vote, we can't. So which company started Kubernetes in 2014? Borg, Cluster Manager.
Feels like, hey, that's a tip, a clue. And, and where did even K8s come from? K-8-S. There's a little bit of a fun trick in that. But we'll just leave the poll sitting up here, as we go. Because wanna dive in first to, James, a little bit of your background.
And thinking about, you know, you started, as you mentioned, with, you know, kind of, in large scale virtualization environments. And, and when we were chatting, there was even a story that we just wanted to kick it off with about automation to do upgrade life cycles, and even a little bit of unintended lessons learned there, if you don't mind taking us back to, to younger, younger James,
who was about to learn something critical. You know, I, I think this is, you know, very early on, right when we started, started our first Kubernetes platform and you start to build automation on top of a virtualization platform, right? We, we used the VMware APIs. We used the, you know, we built, you know, scripted with Ansible around that, to start to,
to scale the platform that we were building with Kubernetes, early on. And, you know, I, I think we, we've seen outages publicly for some of this and, you know, I, I got to make my own mistake with, with this one time where we were, we were going through this kind of upgrade automation, starting with our, you know, we had our, our Kubernetes cluster, we had our control plane nodes, we had our worker nodes.
And, and the automation was supposed to do one segment where it first upgraded the, you know, the master API server and then, you know, rotated over, did all the worker nodes one at a time. Triggered the workflow that we had built. Everything looked good, except that then, instead of processing this serially, right, upgrade one node at a time, the script ended up processing all three master nodes all
at the same instant. Looking on in horror as the Ansible script reported that all three hosts had been successfully deleted from the cluster. And so had to go back and, uh- So efficient. You did it in parallel. Yeah, it was- Good for you, right? It was very ef It was very effective at deleting the VMs.
And so, you know, fortunately had a recovery plan. Had just, you know, as a part of this process, had spun up some additional clusters and were able to move workloads around. Learned a little bit about failure modes, as I think we all do when, when things go wrong, right?
You, you have a plan when, for when things might go wrong- Very quickly but the reality of that was, was very different. Exactly. So, no, but it was, it was good. It w- it's a good lesson learned about, you know, the power of, of the automation that, that you can build around your, your platform.
And I think, I think AWS learned one of those lessons at a larger scale one time when someone ran a command th- to delete 3,000 instances instead of 300. Caused a, a pretty significant outage over there. Yeah. You, you, you, I mean, what you did doesn't, I mean, it doesn't even, it doesn't even register compared to that, right?
So yeah. Exactly. I didn't ta- I didn't take down half the internet. But, you know, I think, you know, as we talk about this pathway, right? Virtualization was the default for all of us in terms of, you know, when it comes to thinking about how an enterprise operates, you know, its suite of applications, right?
From, you know, whether it's, I was in healthcare, health, health insurance organization, right? Had a number of, you know, vendor provided, you know, VMDKs that ran kind of the baseline platform, and then, you know, the custom applications that were dealing with the data on top of it, right? These- Running on Tomcat and JBoss.
I remember JBoss just now. Oh, y- you know- Yeah. That was the environment WebLogic, WebLogic, WebSphere, right? The, these kind of enterprise- Yeah platforms, right? Where, you know, the, there, the Java application development layer, there was your
virtualization team layer, and then, you know, storage and physical hardware below that, right? That was, that was how, you know, organizations were structured. And, whether, you know, we, we, you know, I, I worked in kind of these enterprise Java shops, C, you know, C Sharp, you know, for, in a Windows organization for a while.
But in the end, it was still all kind of that kind of baseline virtualization layer that was managing your, managing the data center, managing the physical infrastructure. And, you know, Kubernetes had a, like, it, from the beginning, there, there was kind of this vision of like, hey, Kubernetes is gonna get to this point of, like, operationalizing your data center, be an API there.
But I think as it matured, right, we see, you know, whether it's a cloud Kubernetes or even just, like, Kubernetes in the data center, it was, it still sat on top of the virtualization layer. For me, you know, 2020, 2021, even in the cloud providers, right? And, you know, as, as we started to scale Kubernetes, that was, that, that was aligned
to a scaling of virtualization, right? And, and I think that shift happened, you know, obviously there was a big transition in the market in 2023. A- and, and I think we start to see some of that change as, you know, KubeVirt I, I actually wrote a, a post in early 2024, as- as KubeVirt was evolving, still in
a, in a consulting role at that point. But it was, it was very clear that- Kubernetes wanted to try to solve some of those core challenges that were now- Lower down the stack. Yeah. Take, take away some of the layers instead of living on top of them. Yeah. Exactly. Exactly. So, for me, it, you know, that, that
time in my career was, you know, working with a number, like, kind of a variety of Kubernetes providers. I was working at a con- at a consultancy that focused on this kind of class of problems. So yeah, we, like, you know, Andrew, you and I kind of talked about the different, like, different ways of scale, right?
Whether it's, you know, we, we talk about drones, right? I worked on a system where we would, where we would package Kubernetes up in micro k8s and push it off into drones to then do some processing- Sure on those edge environments, bring it back to regional centers, right? And, like, that's, that's kind of one model of Kubernetes that, that solves a different
challenge than, like, a, you know, a public cloud Kubernetes domain or than, you know, a, a data center domain. W- and, and I think working across all three of those, Kubernetes kind of takes on its own shape there, but with a common language, right? A common way to express how applications operate, a common way to a- you know, to
deploy and push things out because you have this standard API. There's even one thing we were talking about. We, we, we even wondered, it would be farther back than Solaris Zones, but even talking about mainframes, and I, I think we were b- well, sharing, like, you know, I was in a- a c- a customer. I started out of college actually, 2001.
We had a small mainframe with, but lots of business logic on it. And when I It was supposed to be retired within five years, and then when I left in 2008, it was still supposed to be within, retired within five years. I think you had something similar, but even as we went off mainframes in general, but the, the core of the business logic and then what's required for application rebuild versus
re-platforming and, you know, I'll just say KubeVirt now. But so, maybe just kind of explore a little of the history of the business logic there, and, and then we'll jump to scale, but keep going. Well, I, I think, I think, these organizations, there's this kind of dual dimension of, like, yes, there's, the business logic component, right?
Whether that's im- implemented in a mainframe layer, and for many financial institutions that I've worked with, it's, you know, that's, that's kind of the historical business layer that exists. And whether it's the Fortran code, you know, it's in that Z system, out there. Or then, you know, re-platforming, modernizing that into kind of a new modern application
approach that, where the data then moves into these, you know, modern systems. And, and it's, it's like the, the push and pull is, hey, how do I enable my developers to do developer things, right? Mm-hmm. Work in closely with the business, accelerate those, you know, business needs, while at the same time driving efficiency, driving the utilization and, you know, that effective This
whole story is one of time sharing. It goes back to the story of, you know, physical machine management, right? Hey, we put an application on physical boxes and, and bought that, right? And then we, we did this virtualization transition in the early 2000s, and as VMware evolved and explored, right?
It, we're This history is rhyming. Yeah. Go ahead. I couldn't help myself. It felt like the right spot to put it. And you didn't even, you didn't even flinch when, when the graphic came up, so good for you. Keep going. Yeah.
No, I mean, you're, you're, you're exactly right. That this, this, this kind of transition is about, like, hey, how do we effectively utilize the compute storage network that's available to my organization, whether that's in the cloud and we're talking about utilization there, or it's in the data center and we're talking about, you know There, there's kind of two different problems, right?
In the data center it's, I have bounded capacity, a bounded network a- a- availability, and how do I structure scale to utilize that effectively and give myself capacity management visualization so I understand, hey, when is compute, you know, hitting these limits? When is my storage hitting these limits? What, how do, how do I manage the data center life cycle and the dimensionality there?
Versus then in the cloud, it's about, hey, how do I manage the scaling, manage the services that I'm consuming, ensuring that's effective? So i- it- it's, it's two different problems- Mm-hmm but in the same, it, it's in the same class. And Kubernetes, I think, gives us, you know I've seen both sides of, like, hey, how do we
I, I think that auto-scaling problem was the first one it solved, right? Yeah. Hey, I want to scale up in the cloud, right? That's a very Kubernetes shaped sort of problem, where, where we were working on and, you know, I was working on this kind of scaled Kubernetes platform, hundreds of clusters, kind of each cluster per tenant at a financial institution.
And so the question was, how do we ensure that we aren't wasting resources per tenant, right? This is a, you know, the, the margin of the service was j- you know, delivered based off of how well we could tune the resource consumption out there. And versus now when we look at, like, virtualization transformations, it's more of, you know, I have fixed capacity, especially when you think about the hardware challenges
of today, right? What I can get. Yep. What Yeah. What can I get? What can I use? What life cycle can I extend, and how can I extend that and express it in a common language? And that's where, that's where it kind of rhymes with the previous kind of cycle of, you
know, VMware and virtualization used to be the, kind of that lingua franca, the underlying language that allowed us to express that. Mm-hmm. And I think Kubernetes is at that point where we're starting to, to express things in that manner as well. Do you know what? And, and we're b- gonna borrow time from a
little later, but there, there is one last thing that we, as, as everyone knows, we, we don't have a script. We do prepare what to talk about ahead of time, just be respectful of you all joining us. There is one, from your large scale environment, you already hit a little bit on drones and, you know, that you're actually, you know, pushing things out to the edge a
little bit. But also, you meant, we talked a little bit about scale, that you were working both, I think, with a, an, an, an air- airline which we'll remain nameless. There's enough of them that, you know, we're not giving anything away here, I think. But what are the dividing lines of scale that you've seen?
'Cause it's, it's always a push and pull between, I think, standardization, but also centralization and speed there. So just play that out, 'cause I thought that would be a helpful architectural concept for folks. Yeah, it's, it's interesting.
You know, I, I've, I've mentioned a couple examples where we, where we go, like, a ten- you know, tenant per cluster. And, and we scale by, you know, s- instantiating new instances that then, you know, stamps out whether it's the same application or, or at least the same baseline, right?
That, that kind of tenantized model is, is one approach. And, where you have the central team that manages those tenants. That's, like, one approach to scale, but this is, as you said, kind of a, It's a spectrum. I've seen on the, on, you know, kind of the least, service-heavy offering that's maybe more adaptive is, hey, you know, do Each team gets the ability to do what they wanna do, and
we give you, you know, baseline even templates to say, "Okay, yeah, go ahead and stamp out your own things out here and manage it yourself." Versus then on the far other side, right, this airline that I was talking about had a multi-tenant Kubernetes environment, and the challenges there were different, right? It, it puts more demand on, on upgrades, on life cycle because you now have these, these
sh- you know, cross-business concerns, cross-LOB concerns that all shared under one control plane, right? And I think- Yeah. Yeah, ex- ex- exactly. And so with the airline, their, their goal was, "Hey, I wanna put everything, I wanna put everything together to give myself more efficiency," right?
You, you can get more efficiency when you pack in a multi-tenant environment. We're talking I'm, I'm working right now with another organization who has You, you first deployed, you know, VMs for this. They had VMs in the data center. They shifted some of the application to the cloud, now they have a mix out there.
But it was all tenantized. You know, each tenant had their own five or six VMs. Then each tenant got their own cluster, and now they're looking at how that's structured, and now they're, they're trying to say, "Are, are there common services that I can bring together and provide appropriate security boundaries," right?
So to get to scale, it's, "Hey, what are the dividing lines of the, of, you know, what are the dimensionalities of growth that I have, and what dividing lines are critical between each of those dimensions?" Well, it's Gonna kind of tie off. Just is the, the contrast that I mean, there is a challenge all the way up and there's cost to every boundary that you draw. Yeah.
And even if you're running some of this stuff in the cloud, there may not just be a cost or a, You can't be nimble around the boundary. A- and that's fine, like, that was intentional, but there may be actually be a, a meter, like a, a price tag running against each of those, especially if it's un- unintentional, un- unintended consequence kind of thing.
We're into systems theory here a little bit. So just fun aspects. Exactly. Right. I mean, it's- For you sewors. Yeah it, it, what you're saying is, is absolutely true, right? It's not just architectural, right? This decision has Yes, it has a cost from a, "Hey, what does it take to get that growth?
What does it take to get that scale and maintain it?" But then, you know, hey, what if you have a, you know, transit gateway or NAT gateway between something that, that requires data to be transferred across that wire, right? And, and those are things that are hard to- Money, money necess- Oh, absolute, right. Like, we're, we're talking about cents per gig that, that are going through there, and that's
where I, I think that when it comes to scale, these, these unintended consequences can, can definitely balloon and you, you get to a point where you need to be able to measure each one of those things and, and understand where the data is flowing. And I think that's where, that's where we're headed here as well. So that, done section one.
And we might have borrowed a little bit from other sections. You know, we'll see. We'll keep it on time. Always, as folks know, we try and keep this relatively loose. So, let me actually share back here. I was gonna I thought I could share back poll one, the results.
Let me see if I can get to the right spot there. Or help me out, Tatiana, if you're faster than I am on this, if we just wanna share back the results from poll one, and then we'll launch poll two. But I think I lost that window. There we go. Thank you. so just for those who were
wondering, Google did start, Kubernetes in 2014. Of course, you can literally Google the answer to find that Google started Kubernetes. Okay, cool. And there was even a fun origin story I heard there at one point about, you know, that K- Google actually wanted to work more with Docker Foundation and they didn't wanna do some of the stuff Google wanted.
And then Google went away for a year or two and kind of came back and said, "Hey, look what we made." So, you know, maybe pour one out for Docker. Shed a tear if you will, or not. Where do K8s come from? Yes, it is a numeronym. Numeronym? You help me- Numeronym with the pronunciation?
Yeah. It's, it's a num- it's a numeronym, yeah. Which I think, you know, the, the I think the first time I heard an, a numeronym was, like, you know, accessibility is als- is often, like, shortened to A11Y. And I thought- you know, we talk about, like, allyship and things like that, and I read it as A-L-L-Y and, you know, it's like, I guess sometimes numer- numeronyms can also have, you
know, some sort of s- semantic structure in there as well. Internationalization, when it comes to product development, is i18n. A6, Andreessen Horowitz, the VC, is a16z. Anyway, okay. Yeah. Tatiana, if you don't mind launching poll number two, and we'll let that, set that up here.
Curious 'cause of course we're gonna be ta- we are already talking about containers. Are you running them in production? I'm guessing the answer's yes, but it felt like a good thing to make sure of. So part number two, thinking about two big trends here recently, so you know, the weirding way, yes, that is back to a Dune reference of, you know So how, actually I w-
I'll, I'll be good and not play it out. Go, go Google on that or read the first book. But there were two big aspects here that I think we wanna talk about from a landscape explosion or reshuffling. First, around virtualization, and secondly, of course, continuing around applications, but
even really specifically the impact of AI. So James, you don't mind, I'll, I'll toss it back to you. Let, let's, let's start off, if you don't mind, on the, we could call it modern virtualization side, but really actually kind of dialing in on KubeVirt and things that people might not realize or know as far as what that means in a virtualization environment.
So please. Yeah. You know, I think one of the first things that you come to when it, when we get to this discussion around, you know, KubeVirt in, you know, as a virtualization, solution, as a virtualization architecture, is there's this concern around, like, h- why is this container running my VM? And, and in the end, I, I think it, it goes
back to there, there's a little bit of simplicity that Kubernetes decided that- Maybe from a, a, you know, core virtualization perspective feels a little bit off. But when, I, I think it's, it's a matter of lens, you know, the lens of this, is that, like, KubeVirt the project made a choice very, very early on that it would do virtualization in a Kubernetes fashion, not necessarily in a fashion aligned to, you know, some of the
other open source virtualization platforms that existed at the time, right? The, the goal was to make an open source Kubernetes virtualization solution, but at the same time make it operate and integrate deeply with the Kubernetes fundamentals. So they chose to, you know, be a, you know, wrap KVM, which is what many of the platforms of today are doing, right? The core. Yeah.
The core, that core virtualization technology is still, you know, KVM XML, right, i- is really what's generated and launched in, you know, in the back end. It, it creates, you know, i- it's real lovely once you get down to some of the internals. But, you know, what, what- It works. It works. Exactly. Exactly.
You know, you, you need what you need. And, and we have to be able to express that, right? The, the goal of virtualization is to be able to, you know, appropriately share the hardware that you've b- you're, you're giving the platform access to, share the resources of that hardware, and express what's available to the virtual machine to run.
You know, whether that's over commitment, whether that's operating against, you know, devices that are available, network interfaces on the host, passing through those things. You know, that, that's, that's critical in a virtualization platform, and we, we now express that in a Kubernetes fashion, which means we express it in YAML because everything is YAML these days.
But, but in the end, it's like when, when it comes to virtualization with Kubernetes, you could do I've, I've got a friend who's done a vCenter skin for, for KubeVirt, and you can do things in that way, right? There's, there's all the same- You could vibe code that essentially at this point, or the pieces of it that you care about. Yeah. Exactly. Exactly. So, so, like, that's there, but
that's not the core, because the core fundamental of KubeVirt was to, you know, express the, you know, desires and structures of virtualization in a Kubernetes fashion, right? So there's a virtual machine, you know, Kubernetes resource that then gets operated into a virtual machine instance, that then gets deployed as a pod, right?
Which is, you know, a pod remains the fundamental unit of compute and, we get The, the, the thing that that gets us is all the other, you know, expansions of the Kubernetes domain, especially working with, you know, whether it's storage or PCIE or other, you know, interfaces that exist on the host. Everything now extends across between containers and virtualization without having
to create specific bridge capabilities because it's operating at the pod level, right? The pod does the translation into the KVM, you know, launcher, basically. And, and so we, we get all those things naturally extending from what Kub- with the work that Kubernetes has already done. And some of it is that you actually get some of the, I'll say gaps to be negative, but,
like, the things Kubernetes wasn't designed to do certain things, so therefore by definition KubeVirt won't do some of those things unless you add things onto it. But keep going. Yeah, no, I mean, you're, you're exactly right, right? There's, there's, you know, virtualization, you know, especially VMware has had, you know, 30 years to develop an enterprise-based, you
know, virtualization platform. And I think, you know, we see the enterprise, you know, you know, Kubernetes platforms, whether it's Red Hat, Spectro, SUSE. You know, they developed an enterprise grade, you know, Kubernetes orchestration solution, and now we need to extend that to, I think, the, the key places.
And, and it's, like, it really does It, it almost kind of gets expressed simply on the virtualization side. When we get to AI, I, I think there's, there's some different types of challenges that you have over there. But in the end, virtualization is like, "Hey, how do I get access to a shared pool, pool of compute, a, you know, the network, the
appropriate network with the appropriate segmentation on it, and the appropriate, you know, data s- you know, storage with the appropriate data services on top of it to ensure the business continuity?" yeah. And understanding that there's some things you don't get, which is gonna be a hard cut 'cause we're gonna follow up on that later.
Yeah. And it's all right. Let me, let me shift gears over to the AI side. So as it relates to a applications in an AI landscape, something that I, I, I mean, I don't wanna say I didn't realize this a couple years ago. It's been a while. But often folks don't realize is that
Kubernetes and containers underpins, I'll make the bold statement, I want to say all a- AI type applications, whether they're internal or stuff that you're creating. So i- if you don't mind, continue just commenting a little bit on AI applications as it relates to containers and Kubernetes and the top things that you, you share with people or that you've even learned as you talk with customers.
Yeah. I, I think what, what I see within, you know, the suite of AI applications, right, is, is there, this is a journey as well, right? This is kind of a, a modernization journey on a significantly faster acceleration pathway than we've seen of any modernization journey in the past. You know, these AI applications, right, you start with interacting locally.
You start, you know, organizations generally start with that model. Yes. But as you start to think about, yeah, exactly, everyone's got their own AI agent. Everyone's got, you know, whether it's ChatGPT or Claude. But then when you start to think about, like, the AI value chain, how do I, how do I make
that work in my environment, you start to get into, you know, data pipelines, whether it's with Airflow or Kubeflow or, you know, the, these other projects, Ray, that exist out in the environment to start- Mm-hmm operationalizing your data. And then on top of that, then building, you know, deploying agentic applications, this is where you get projects like, you know, Agent Gateway.
You get projects where it's like, hey, we're, you, you have a agent-to-agent protocols. You start to use Kubernetes to be the way to, you know- Build central services where agents are running and operating your business processes. Mm-hmm. And, and there's a transition point there, I think, that happens between an, you know, a, a human interacting with an agent, internally to an organization to do things like developing
code, to then, like, using your data more effectively in business processes, right? And this isn't just like, this isn't about a chat, you know, some chatbot going and interacting with the user, right? That's just, that's just taking a, an, you know, open a AI API and throwing your user at it, right? This is about getting really good data at the
right time at the point of execution, and using these capabilities that we have from whether it's the frontier models or local, you know, local AI, which I think we're seeing emerge, now signif- you know, especially as token costs become more and more real. And, and layers are really being developed to help virtualize and manage the life cycle, the, that GPU memory layer, which is the s- the key constraint in, in these AI applications.
So we're constrained by memory, first of all because of its expense, right? The, the compute costs- Expensive, yeah. Mm-hmm continued. Yeah, absolutely. And then you're constrained by getting good data into the system at the right time, whether it's model management, right?
In these models, you know, some organizations are talking about, like, models as OCI images, models as, you know, these tensor- you know, CoreWeave Tensorizer project, right? Models as data are really important, too, right? They have their own life cycle that you have to manage, whether it's, you know, retraining, whether it's versioning and understanding, you know, or whether it's compliance, right?
How do I know what model made X decision, and how that then feeds into my observability and my retraining system as well? So these, these AI applications naturally interface with Kubernetes because they- y- you build these, these layers of communication between your applications and these underlying, these underlying AI models, whether they are on, you know, on your infrastructure or
someone else's. And, and so we, you know, this, I think we've started to see, large, large institutions, you know, using these AI agent models as a, as a key part of that interface to their applications and their data. So they can- so that these things can make decisions and become smarter about the decisions they are making, and whether, and that's deployed in a lot of different ways,
whether that's at, you know, Neocloud's offering Kubernetes services. You know, and I'll say, you know, the public cloud providers will say that they have their own, you know, Kubernetes AI enablement. You know, the, the development of projects like Kueue and, you know, extended scheduling capabilities allow you to start requesting those GPUs more effectively
and, for AI workloads. And all these, all these abstractions live in the Kubernetes domain. It's, again, a problem of effective resource utilization and, and ac- and, you know, access to that resources, those resources. And I think we, we're talking about that from a compute perspective, but that also ma-
matters for storage. When I was, one of the large Kubernetes platforms I worked on was a, you know, a data governance tool that allowed you to gather data from a source and go through a couple transformation pipelines with then a governance layer on top of it that then stored an output with the metadata about that governance process that it went through, right?
Who has access to the data? How did that data Where, where's the lineage of that data? And, and, you know, all of this stuff today can live inside, you know, this was with the Trino project, but all of this stuff today can live inside of a Kubernetes framework. I think to summarize and highlight a couple things, so it's about
optimizing for constraints. You mentioned compute constraints. So this, this continues to be a game of move the bottleneck, but there's so much there, and, like, man, each of these sections, I wanna g- let them go longer, but, like, for instance, you have some of the Neoclouds, like CoreWeave is an example.
Like, there are companies that are making whole and huge businesses out of there's enough challenge and depth and knowledge needed to optimize around the current constraints. You can build a multi-billion, trillion, however big their market cap is, business around these areas. It, it's that big. Which is wh- which is why I went on to
highlight it, 'cause it is at its core still a game of moving the bottleneck or sometimes if I'm more controversial, it's like, what resource do you waste? I see a final thought there, or should I keep bringing, going to bring- No, no. I mean, I, I think that's exactly right. And I think with AI applications, the challenge goes deeper to, like, that, like,
the constraint and the bottleneck and the, you know, the uptime and the resource utilization of, like, GPU compute is, is really demanded. Mm-hmm. And that, that becomes a significant challenge. So you may be thinking, "Hey, this company used to be called Pure Storage. It's now called EverPure, and we're focused on data." We always were.
You know, it was more the name shift was acknowledging where the company's been going. But so that means even with all the stuff we've talked about, you still need a degree of storage automation. You still need a degree of resilience and security a- and even unify all these things that focus around data, right?
'Cause there's still data, whether it's in a mainframe or whether it's in Kubernetes or VMware. Which, of course, brings us up to section three. But before that, Tatiana, if you don't mind, sharing back the results from poll two, just so folks can see, and then we'll go into poll number three, which is actually gonna be a
little bit of a quiz. So yes, the majority running containers in production, although not a majority. Majority of the poll, but not, you know, over 50%, you know, kind of thing. Thank you, everyone, as we like to share this back so folks can see. And, if you could launch poll number three, Tatiana.
Thank you. So are you running stateful applications? Is the data being stored inside the Kubernetes, in- inside the container? And then even, we decided to do a little bit of a, ho- hopefully this isn't too annoying, but, you know, the k- Portworx cube data store capability. If you had to guess, and hopefully this won't distract you too much, thinking about, you
know, what, what that actually is, what it does. So- Getting into more of what we do from a Everpure standpoint and a Portworx standpoint, data loss, if we lose data, like do not pass go, do not collect 200, we do not even start there. So there was actually some stuff that we wanted to talk about and, and frame this while
we're gonna wander into what Portworx does, but more frame it as what are the core storage needs in Kubernetes environments, or even kind of call them the, the foundational Portworx design principles that are built to survive data loss, and if I can't help myself, and why they matter when the sandworms of downtime strike. At least it made James smile, so hopefully someone else there smiled.
You gotta walk carefully across that sand, right? And, and I think, you know- Double step we call, we call this back to the history that we started with, right? Borg, Cluster Manager, Google had other ways of managing state in their environment, and so they didn't design Kubernetes. Like, persistent volume claims weren't there in 0.1.
They were there in 1.0, because it was clear that they needed a way to express that. But, you know, this, this ecosystem wasn't always just Kubernetes, right? There was Nomad from HashiCorp, there was, you know, Docker, Docker Swarm, right, which each had their own way of managing state. Mesos was probably the one, you know, the, you know, another one to pour one out for.
They had a very opinionated design of storage integration, but didn't win the landscape for, I think, a critical reason, right? Kubernetes made things easy for developers, and that's why they won out in the landscape, right? It became an easy way to express and build platforms on top, right?
They, the open source community embraced the model that Kubernetes provided, so now we have all these layered capabilities on top. And so now, when we think about building and scaling our platform, the question is, where does the data go as we, you know, go through this large scale investment in Kubernetes? I'll say, the thing I've seen early in my career is that the, the lack of data services,
the lack of data management became a real challenge for these platforms that were growing and scaling because we get to this question about, where is the data gonna come from, where is it gonna live in this environment? And teams are reticent to want to bring that in because it's chall- you know, the data itself has gravity, right?
And I think, of anyone to understand this well, right, is people that work with Pure, because we, you know, we, we understand that. We op- we give you a platform that operates that really effectively. And in the end, right, compute and network are easy to get wherever you want. But like five- Stateless.
Yeah, exactly. Right? Compute is stateless. You can take your compute from one side to the other. Five terabytes of data, you know, there's, there's core, like, limitations there about how fast that data can move and how, how you secure it as you move workloads around, right?
You, you, you need runtime security in your Kubernetes platform, but you need, you need to secure at, at the end, right, the crown jewels of your organization, the data layer of your applications, right? And so when we think about the challenges that we need to work with, right, it's, hey, how do we have a storage layer that we can run and we can ensure is secured across all these systems that we're working on, right?
As, as we think about, you know, Kubernetes inside of the enterprise, it becomes a challenge of the dimensionality, a little bit of shadow IT that's come up with the Kubernetes domain, right? Hey, I, I was just talking to another team that's like, "Yeah, we, we found out there's this other whole team of 10 that's running, you know, this- this secondary Kubernetes
platform." That, and, and that doesn't- Shadow IT lives. It always does. Exactly. When there's need. It always does. It always does, right? But, but it's like, how do we create a storage layer that, that provides those kind of business continuity, disaster recovery capabilities that our organization requires?
How do we meet the data security and segmentation needs that we have, right? Do you have, like, you know, in some really secure environments there's, there's a, a requirement of a double encryption where the top layer is isolated at either a tenant or application layer, right? Or even just how do we, how do we create cryptographic boundaries
between systems, right? And, and Pure's, extending this multi-tenancy and back in the array as well, but how do we create an integrated end-to-end flow where we have encryption from, you know, the workload itself, from its data, all the way to the back end, right? And so we have The, the kind of fun- fundamental principles is, the first is we
express the data, you know, of Kubernetes management for Portworx in a consistent way across any storage system, right? This is the bottom layer of how we operate, right? And- Even non-Everpure systems, even with the cloud- where of course there's gonna be an internal incumbent storage option, so keeping it intentionally agnostic but better together.
More on that later. Keep going. Yeah. Well, and, and I think with, with those, it's like operate the systems, you know, as we talk about. You know, I kind of mentioned the Kube datastore capability went within, you know, the poll that we've done, and I, I think it's really critical because where Portworx is
going in this direction, we'll talk more about this later, but it's, it's treating each one of these systems effectively, right? Hey, how do I, how do I integrate and operate with my hyperconverged systems? How do I integrate effectively with the Pure Storage arrays that I have? How do I inter- integrate with the public cloud systems or the edge,
the edge storage, right? Each one of those has its own dimension of a- of availability, its own dimensions of, that we need to satisfy for failover, right? Failover is gonna look very different in a data center environment with an array that has mobility between hosts versus, you know, edge nodes, where I've got, you know, h- local SSDs that themselves could fail, and I need to solve those problems in a unified way to
address the dimensions of scale that I have for my organization, right? What, which one of those dimensions do I need to tackle, and how do I solve, you know, the different concerns that exist, whether it's, you know, edge, cloud, or the data center itself? There's some pieces there and I think I'll, I'll tag in and then toss it back to you for citing 'cause we'll, we, if we took more time
in the front then, you know. So there's some foundational design principles to create a storage layer that can run anywhere, any environment. This is what I call sometimes the any, any, any slide, or maybe it's three any's. I think I had too many any's there. But about making the lower layers actually better.
And even in some cases, while we're not gonna dive hard into this now, about running Portworx on top of Everpure, FlashArray, et cetera, making it better and actually leveraging the underlying strengths. 'Cause, like, FlashArray does some amazing things around performance and reliability. But where that's not the case, we're still gonna be able to support, 'cause especially, I
don't know, let's just pick on GKE. We wanna be able to integrate with that as well for all the different, all the different applications. Yeah. I think the, the, the, the one M- I think my, my closing thought here is that, often when I hear, I've heard stateless versus stateful.
Stateless just means data is somebody else's problem, or the state is somebody else's problem, until it's not, and that often happens when things go into production, and then something goes wrong, and then it's everybody's problem 'cause it broke when it's not done well. So we have to plan for this ahead of time. It's not to make this overly complex, but we have to get ahead of these things.
And data has challenges around protecting it and you, and how you move it around, et cetera. So I see a final thought there. No, I mean- Before this section. You're, you're exactly right. And I think there's data at different layers, right? There's, there's metadata, there's how the system describes itself that we need to
understand and operate effectively, and then there's the, you know, the data for each one of those applications, right? And, and I wanna think about, you know, I wanna think about protecting that from the perspective of, you know, actually, actually going through and recovering applications, right? Mm-hmm. If I can get my data somewhere but I
can't get my application up and running effectively, like, th- this goes back to that original, you know, "Hey, I, I took out the cluster," and we had to figure out how to piece some things together to get, get things back together, right? I, I don't wanna be doing that with my critical business applications where I, I need to understand how to get from applications all the way to data and get that recovery executed
effectively when, you know, the fire is live, when, when things are going wrong. So if you're thinking, "There must be a lot more depth here," you're right. There's actually a version of that slide. This is, like, the, the version if we came in and, like, whiteboarded it for you, you know, kind of thing, or sometimes we use it for Q&A.
We're not actually gonna present this, but just to give you a sense that there's this level of depth that we're happy to go to, 'cause, like, even how does stuff work around snapshots or implication or block versus shared NFS, or sometimes play it out from a standpoint of, you know, storage automation, protection resilience. And a deeper slide for each one of those that looks at what different personas care about
and they get. There's a customer case study here. You can find these in some cases, other Portworx webinars we've done, or just, you know, just go and browse around the website. But there's a level of depth here and we gotta keep this higher level and aligning to some of the challenge that we were talking about in the first part.
Tatiana, if you could go and share back poll number three and we'll see how everyone voted, and we'll do poll four, and then we'll bring it home with some new, new and interesting stuff. So poll three, stateful applications in Kubernetes. It's a little less than just running containers.
That, that makes sense, I think, logically. But it's pretty evenly split, as I think everybody can see here. Even the, "I'm just here 'cause I don't know, you know, and I'm looking to learn about this." That's cool, too. And, James, so, what is the right answer here for number two?
I'll, I'll let you be the professor. So. Yeah. No, we, we've got over 50% correct. Great job, everyone. Yeah, so, so Portworx cube data storage is grouping our This is, is about grouping storage into systemic, you know, thinking about a systemic level rather than as a individual connection from workload to a
storage system. So we think about a logical unit similar to a VM datastore of how my storage system is interacting with my Ku- Kubernetes cluster. So that last, result is correct. Kudos to everybody. Hopefully this wasn't annoying, but I was like, "Well, we'll put this in," 'cause it kind of follows.
And if nothing else, you'll remember, "Hey, Portworx cube datastore," now, 'cause you're like, "Oh, I got it right," or, "I got it wrong." Either way. Okay, last section here. This is now, as always, a coffee break. We wanna u Al- almost always, almost always pull in some new pieces.
And there's a classic one and then some brand-new stuff from Accelerate. And if you're thinking, "Hey, it's 46 minutes past the hour," you're right. We're probably gonna do about five to seven minutes here. We'll do the drawing, stay around for that, and we'll, we'll still make sure to end on time. And if you have any questions, please, as it
says there, you know, Q&A throughout, feel, please feel free to either use the Q&A function in Zoom or just toss it in the chat. I'm watching that over here on the side, you know, when I'm It doesn't look like I'm looking at you, I'm looking at the chat to make sure over there on the side. So there's two big c- there's two big categories here.
The first is, as it relates to cube vert, we've said that multiple times. And there's even one, I'm, I'm usually here as kind of host, although I do a good bit of stuff inside of it here, so I can talk about things, but I'm here, here, m- more here because we have amazing guests. But there was one piece here that I wanted to share.
When I first saw this slide is where it really clicked with me with Portworx in a modern virtualization or a cube vert. 'Cause I come from vExpert 3456 at six Or sorry, VCP 3456, inspired vExpert for 14 years. And, like, all these terms here are very familiar things that I
worked with over the years. And you just kind of assume they're there, whether or not you use that feature in any given cluster or environment. But you just assume it's all part of the package. And then you realize, oh, cube vert, like James, you were walking through, well, it was designed within a Kubernetes construct, even though it uses KVM, you know, internally.
So some of the stuff that you might just assume is there may not be there, or you may need to go decide, "Do I need it? Do I care about it?" 'Cause you may not care, frankly, about storage DRS. And if so, fine. That's great. But you probably care about thin provisioning, or maybe not.
So there's a kudos to folks in our, marketing and design teams who make the more professional, polished version of this slide, where, you know, you can still see there the pieces here that are provided. But James, before we go into the accelerate updates, any- anything else that you wanna riff on here as far as it relates to how Portworx specifically enables cube vert?
Yeah, I think that's where, like, we see a lot of the teams and, and work that's developing today. When, you know, back at Accelerate we talked about these kind of core enterprise data cloud capabilities, and, like, Portworx takes that unified data plane concept and extends it beyond just where FlashArray and FlashBlade live today, right?
And, and that means these things around, like, data portability for virtualization. I- I'm working with an organization today that, that's being, you know, asked to extend their vSAN environment while also, you know, coming into Pure and starting to, to deploy FlashArrays in their environment where they're able to. And the key thing that Portworx is doing here is we're giving them that, that ability to
extend the life cycle of what they have today, while also then shifting workloads as they can onto the FlashArray, all with zero downtime, a single API command, and now they're, now they've shifted their workloads over, and they can retire the systems effectively as they reach the now extended end of life date. So this, this mobility, I think, is You know, we think about systems not as static, right,
but these systems are, are really evolving very quickly and, and, we, you know, we keep mentioning it, right? But the demand of hardware means that we have to be able to integrate across the data center that we have today, and then the data center we wanna design in the future, and that's where, like, this isn't just portability for, like, day zero or, yeah, I'm gonna move it over tomorrow or some other day.
I wanna be able to rebalance and effectively utilize the systems and, you know, shift workloads over to my target system as I get there. And, and that's where, that's where I think we're really leaning in to develop these capabilities to make, you know, a virtualization platform that's going to work for not just the data center you have right now, and it, and it really should work for the
data center you have today, but also help you plan and, and evaluate, how am I gonna do those investments in the future? That's, that's really where we're headed. Love it. There's two other slides we'll include here just as reference, actually, of some nice builds around kind of mapping a little bit
more, because if you joined or even people who missed, we'll get this as a follow-up, so like to provide these sometimes. But final item, we were at Accelerate, man, it feels like forever ago, although it was, like, three or four weeks ago. As it, there were a lot of announcements there as it related to even kind of modern virtualization.
There was stuff with Nutanix. There, there were, there, there was stuff with VMware. We're continuing to work with VMware 'cause there are a lot of folks staying on VMware, you know, kind of thing, just being real. But as it relates to Portworx, there were three big items.
We decided not to be coy here and build the slide. We just put it all up and, hey, listen to James even as you can read what he's gonna kind of say at a high level. But James, do you mind kind of taking us through the, the three items here? Yeah. We, we talk about that virtualization journey, and the start of it is getting the data from,
you know, the VMware system into, you know, into a system that's running in your, in your v- you know, Kubernetes environment. And by using the array capabilities to copy data in the background on the FlashArray rather than copying data across the network, which is the default, you know, is the default kind of operational mode, right?
Organizations that migrated to, you know, largely, you know, any alternative hypervisor in the past, but, but even, you know, the Forklift project inside of the CNCF was driven initially by a network copy and moving that data over it. And that is, like, you would talk We, we kind of joked about how long it takes to move five terabytes of data, but let me tell you, anyone that's worked with a Kube virt, like,
transition project knows exactly the, the, the amount of, time and, and effort and, and intense, like, pressure that puts on both the network and storage systems you have. And then- It's, it's like possible versus not possible sometimes. Can I even do it at all? E- exactly. It's, it's about, the data gravity has, has significant weight when it comes to timing,
when it comes to downtime as we transition these systems over. With rapid VM migration, we do this in the background, and it really is an order of magnitude improvement, in terms of how fast these migrations can occur now from a VMware system to a, to a virtualization platform on Kubernetes. And actually, I just realized, James, for, what's crazy is that many times I looked at
this slide, what you just described for rapid VM migration is this bullet point down here. But hey, you know, it feels safe to figure it out. So, and a lot of people looked at this slide. So yeah, keep going into, tenant clusters and the edge. Yeah. So, you know, with tenant clusters, right,
this is where that, that model, we talk about that model of scale, that model of separation between workloads of, you know, what dimensions and what boundaries do I have to pay for? And this is a boundary that I think a lot of organizations have done, right? They, they've given a cluster per tenant, a cluster per BU, and as you transition that off
of, like, you're, you're not gonna run a physical cluster per business unit, right? You, you don't segment your physical hardware that way. I, I guess except for some, like, organizations that run really strict neighborhoods. Sometimes. Sometimes. Yeah. But not often. Yeah.
No, you're, you're right. I mean, you can never say never on these sorts of things, but, but a lot of teams have used, like, the Kubernetes virtualization boundary, right? Hey, running a Kubernetes cluster on VMs as the tenant boundary and, and you can grow, you can get greater density in that way, and that's what, you know, that's what, you know,
an OpenShift cluster on VMware in 2017 would've been. It's, you know, the, the Kubernetes nodes themselves are virtual machines. And so running Kube per tenant clusters and running now dynamic pools, right, with kube-datastores allows us to then utilize the FlashArray effectively, make it look more like a datastore from, from a VMware environment into, into the Kubernetes, platform.
And then finally, with, with Portworx Edge, we, we move into, you know, Kubernetes data management capabilities deployed at, you know, retail edge, factory edge, you know, telco, manufacturing. Like, we are s- talking to a oil and gas company, right, that, that does, processing in their factories for, you know, AI evaluation of these machines that are, that are working
at, at these edge sites. And so now as they look at modernizing these applications, you know, what I, what I find in these types of discussions is that, you know, they have to bring along these VMs that are their core business capabilities, but then wanna modern- build modern applications, especially modern AI applications that are gonna go and push out process data at the edge
and send back what they need, and that's where Portworx Edge really comes in to be able to extend those data capabilities to wherever you run, especially, you know, as we talk about, you know, detail environments, low network capability environments. Like, let's, let's run those capabilities at the edge and bring back only the data that we need. All of that from an accelerate standpoint was
in within our larger announcements where we talked about things from unified data plane, intelligent control plane, universal data management. This was in kind of our unified data plane for, you know, different types of applications but, but larger as well and, you know, in multiple environments kind of thing. I don't know if I can believe it, but it's been almost an hour.
Not quite, less than that. The time flies. It always does. Yep, it's 'cause we prepare some, but we know what we're gonna talk about, but, but then it wanders a little bit too. If folks wanna reach out, or actually I'm assuming, hopefully, the folks would love to reach out and learn more.
But we've done this enough that there is actually a level of structure here. Obviously there's more here than you can cover, but any kind of highlights of how we often engage with folks when they wanna reach out around this? Yeah. I, I think what, what you see laid out here is kind of the structure that the Portworx team has put together.
When we talk about, right, talk about understanding and evaluating this at a broad, from a broad view, right? Hey, your organization is looking to accelerate your workloads with, you know, Kubernetes and with, you know, bringing stateful data along with that and integrating that together.
This is where, like, our team has put together this kind of journey map of understanding, you know, the driving factors of this project to bring, you know, bring data, whether it's from a virtualization platform, an emerging application, understanding what the, the focus area and how, how are you gonna deliver these capabilities for your environment, and then structuring a delivery with our, with our services team to be able
to execute this, right? We've, we've, we're investing heavily now in professional services to be able to execute these projects effectively. And, and really not just, like, this isn't, like, project one at this point, right? Take the learnings that we've done from these initial, let's say, the initial implementations 18 months ago, the second wave that's already completing now of, of
organizations that started at the end of 2026. Now this is more formalized, so we can help you really accelerate that journey and, and effectively move into a Kubernetes environment. Love it. So with that, we are at the end, except there's a fourth poll.
Tatiana, if you mind sharing the results back, we'll leave that up as I jump into the, drawing and next time. Oh, I'm, I'm realizing here, shame on me. I missed I think I'm, I think I missed sh- launching poll four in the previous one, so I take that back. Go ahead and vote on poll four because
actually very curious which virtualization path you're looking at. We'll leave this up a little bit, and, and believe it or not, we can see the attendance, like everybody is basically still here with us, even though we're at the bottom of the hour. So we'll let you vote on that for a second. And then, but if you stayed around for, if you stayed around for the drawing, thank you,
Andrew I. Try and be good about, and not just 'cause first name is Andrew, but you know, I liked Andrew as well. But Andrew I, you were the winner. Thank you so much for, being here for the entire time and winning the coffee lover set. We will be back next month with Andy Yun, Ch- Ch- Changes: Navigating the Tsunami Reshaping
the Data Industry. And I'm gonna put it up here for on the kind of the questions. If you have questions, we have answers. And actually, Tatiana, if you don't mind just sharing back poll number four while we're doing this. I think we've covered, incorporated everything
we'd have had from a question standpoint here. But James, maybe bring us home with just, what is the most common question that you get, or maybe that's just a closet way for you to say the last thing you wanted to say that we ran out of time for. So, you know, either way. You know, it, it's really interesting and, and like sitting in this chair working with, the
Portworx team, working across storage and Kubernetes, I- I'll say that, like, going, looking back across this, you know, we, we kind of talked about the past, the present, and the future. It's like- Mm-hmm. I, I, when I started Kubernetes, I, I really had a, I didn't have a great relationship with my storage team. And, and I'll say, like, that's, that's my
call to action. It's like there, there's real significant value in terms of integrating those, Like, why, why bring, you know, why bring data into Kubernetes, right? It's al- My data's already somewhere else, right? And, and, and I think it's, it's really a matter of, like, there are, like, in this
industry and this platform has had such significant investment in building primitives that enable you to operate that effectively. And that's where it's like y- you, you know, as an organization that might be early in this journey, can gain so much out of drawing on those, drawing on that learning that other organizations have already ta- done, right?
They've already gone through these pains, and you can draw on that expertise and, and, you know, obviously reach out to your peer representatives, reach out to, you know, your Portworx team and, we'd love to share that with you and, share our expertise and try to make your, your Kubernetes investments even more effective. That felt like essentially history doesn't repeat itself, it's often rhymes, and if we
can learn lessons from what we've done in the past to help accelerate where we're going, that's absolutely worthwhile. So thank you, James, for being an amazing guest. Thank you for everyone joining us. Thank you from the entire Coffee Break team there, folks behind us.
Tatiana is here with us today, but so many other folks that make Coffee Break possible. We will look forward to seeing you next month. Have a great day.
Andrew Miller
Senior Principal Technologist, Everpure
James McShane
Consulting Cloud Native Architect, Everpure
Kubernetes (K8s) sits at the center of the known universe, steering the massive shift from legacy systems to next-generation applications and modern virtualization. In this vast desert of infrastructure, one truth remains absolute: they who control the data layer control the universe.
For July 2026, your Kwisatz Haderach of hosts, Andrew Miller, invites mentat James McShane to explore these tectonic shifts—and why Portworx® is even more vital today than 5+ years ago when acquired by Everpure, formerly Pure Storage® to be the ultimate k8s data layer.
Here’s what we'll traverse on our journey:
- The path of the mentat James: From large-scale virtualization to massive K8s clusters, and even piloting K8s on autonomous drones (the ultimate hunter-seekers).
- The weirding way of modern tech: the explosion of new K8s developments with a focus on KubeVirt and how it’s reshaping modern virtualization trends.
- The litany against data loss: Core storage needs in K8s environments, the foundational Portworx design principles built to survive them, and why they matter when the sandworms of downtime strike.
- The voice of Portworx: New capabilities designed to conquer KubeVirt/VMware migrations, establish unified control planes, and shift your focus from rigid mechanics to pure intent (Imperative vs. Declarative)--dare we say, bending the infrastructure to your will.
Whether you’re a "recovering" storage admin or a Platform Engineer architecting the future of your Imperium, grab your spice-brew and join the conversation.
Overview of Coffee Break by Everpure. Who knew that the best coffee break conversations would happen online? Each month for the last five years, the Everpure Coffee Break series invites experts in technology and business to chat about the themes driving today’s IT agenda—much more podcast than webinar. This is no training session, either; it’s a freewheeling conversation that’s as fun as it is informative and the perfect way to break up your day. While we’ll wander into Everpure technology, our goal is to educate and entertain rather than sell.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.