Modern Virtualization: One Platform for VMs, Containers and AI

Hey everyone, I'm Alan Shimel, and welcome to the "Open Current" podcast. I am your co-host, and I'm joined by my co-host for the podcast, the one and only Margaret Dawson, CMO of SUSE, and I'm happy to say, my friend. Margaret, welcome home.

I know you were traveling around the world. I was. Yeah.

I was in Mumbai, India, for five whole days. It was a whirlwind via Amsterdam. But great travels.

Kudos to KLM and Delta for being on a plane for 22 hours. It was pretty good. And I will also give a shout-out, I don't do this very frequently at all, but the JW and Marriott near the Mumbai airport, I would literally go to Bombay again just to stay in that hotel.

Just to stay. It was that nice. And I never say that.

Everything. The service, the fitness center, the food- Right ... the bed, the pillows, the water.

I feel like I need to write a blog post about this because it was just five-star excellence all the way around. I will tell you, I've stayed at JW's around the world. And I know Marriott has the Ritz and- Yeah ...

other luxury brands, but from a business, as a business traveler, I agree, JW does a great job. Yeah. Great job.

So there you go. Maybe we can get a sponsorship. Well, I don't think they'll give us any free nights or anything.

That's okay. I've got so many, not miles. What do you call it?

Points. Points. Yeah, I know too.

It's like if you've got miles in a hotel, that's something completely different. Well, except my children and my wife's family think I'm the bank for points and airline miles, right? It's the new ATM.

It's so true. Yeah, it is. Yeah, your adult's new ATM.

" I have experience with that. " There you go. Anyway, Margaret, we could talk on our travel podcast- We could ...

we could talk about travel and hotels. Here, we talk about things affecting the open current, open source, AI, but also things, sovereignty. Yeah.

We talk about Linux, obviously, and hosting, and all of these things. In episode one, we talked about do you really control your technology stack? Here in episode two, we're going to talk about, I think, something that a lot of people- Mm-hmm ...

are talking about, and that is VMs. One platform for VMs, containers, AI. " Mm-hmm.

Not that I'm necessarily going to not use VMware. Not that I'm necessarily going to move from a private data center to a cloud. Not that I'm necessarily changing just because of price.

Right. " Well, I think it goes back to that age-old problem that IT leaders have had to reduce cost, optimize what they have, and go to the future. It's become a much accelerated path with AI, right?

Right. The pressure that they are under right now to accelerate that innovation and implement AI, I think is also putting intense pressure on not just VMs and the virtualized environment from a price perspective, but also from a modernization. Yeah.

Because, and you know I've said this to you a million times, so I'm sorry, but AI workloads are containerized workloads. So we could almost put those together. So when you're looking at that modernization, they're starting to say, "Okay, can I, as part of the journey I'm already having to go on, look at modernizing some of the workloads or data sets or components that I have in a virtualized environment, a legacy," I'll just say the real thing, it's been in that for some time- Mm-hmm ...

" Or does that just become something that stays on VMs, and I know it may have a dependency for those applications, but it's not worth moving. Yeah. And there's a whole lot around it.

I will bring up one thing quickly, and I'm wondering if you've heard this, is we just came out with some new data from a survey that we do every six months. And the top five challenges from IT leaders, and this is global, the number one challenge was skill set. It always comes in the top five.

It went to number one. Now, the number one investment is still AI. So we asked them, like, "What's your top challenges?

" There's a mismatch. Skill set falls off the map almost. It's still in the top five-ish.

Yeah. But I think something changed too. I'll tell you why.

I don't know if you knew this, but I was a co-founder of a company called the DevOps Institute. I helped when I- Mm-hmm ... com.

And we became the largest provider of DevOps certification training in the world. It's a very weird upskilling, as we called it, is a very weird market globally. Right?

Mm-hmm. In Europe, usually a company will pay to upskill their employees. Right?

You want to go get a certification in DevOps- Right ... or whatever, company pays it. In the US, the prevailing attitude is, look, you want to upskill yourself, you want to get new skills?

Oh, I'm so happy for you. Go do it. I'm not paying for it, but go do it.

India, you were just there. India is a market obsessed with upskilling and training and certifications. And you've got people who, if the company don't pay for it, I will because it's that important to me.

Right. And- But I think you can- ... you see that Yeah.

And I think you can actually analogize this a little bit to the DevOps movement, in that we weren't asking developers to become operators. Yeah. And I think that was a misnomer of that whole DevOps vernacular.

Yeah. It's like the last thing I want to do is all my devs all of a sudden trying to be administrators and operators. But- Well, that ultimately, yeah, the whole shift- Right.

It was more about understanding how the two fit together, and did both sides need some upskilling so we weren't just throwing stuff over the wall back and forth, which is what created DevOps, right? Because that was the reality of the way we were working together. Yeah.

And I- And you see this manifest in platform engineering now. 100%. Yeah.

We have the same silos. You've got the VM silo, the container silo, or infrastructure silos, whatever you want to call them, because I think actually, we talked about this before, you have silos of stacks all over the place. So- Yep ...

could this somehow bring those different silos together? Is there a common control plane, as we like to say? Yeah.

Well, and that's a load. I was in Vegas last week at Black Hat. Mm.

And I'm magenta control plane'd out right now. I bet. I've heard a lot of that.

But here's the other thing, Margaret, is the world doesn't fit into neat packages. You ever see those cubes you get where you could pack your suitcase in those cubes that supposedly- I have them ... give you more room?

Yes, I love them. Does it work for you? Do they work for you?

I love them. Yeah. It depends.

Well- Back to our travel podcast. Now we're going to go back to travel. Now we're going to go back to travel.

Okay. Anyway, travel cubes. Yeah.

But the world doesn't fit into those cubes so easily. And my experience in talking to a lot of people, a lot of vendors, a lot of end users, is that when you look at the people who are looking, what should I do, right? Mm-hmm.

There are some people who say, "Look, I like what I got now, and I'm not really looking to transform. I'm not really looking to adopt a cloud native stack. I'm not really looking to move to a public cloud.

I've got my stuff in a private situation. " Right. "I like VMware's offering.

I like their feature set. I just don't want to pay more money. And even if I pay- Uh-huh ...

" Right. And so those to me are the lowest on the ladder, the lowest rung on the ladder, right? Right.

They're real price sensitive people who are quite happy where they are, and where they are may not be cutting edge, but it's good enough for them. " Right. "We want that cloud native stack.

We want Kubernetes. We want containerization. " Mm-hmm.

"Yes, I could do it with VMware, Tanzu and all that, but it's kind of clunky. And moving it to a public cloud provider could be prohibitively expensive compared to- Mm-hmm ... " Those are the people who, they're looking, they're out there saying, "What's the right-" Well, and there's a new term that I'm hearing a lot.

In fact, I just heard it from one of our biggest partners last week in India, which is this modern virtualization. So there's this, all of a sudden, this separation of legacy virtualization and modern virtualization. I love it.

And it is assumed, yeah. Modern virtualization is where VMs and containers are living side by side, so to speak, or nestled into the cloud native world. And you're able to share some of that management control, unification of policy, and you are moving on that cloud native path, but it's not quite the rip and replace.

You're still- Yeah ... kind of benefiting. And this is using KubeVirt mostly, right?

Which is kind of the natural Kubernetes virtualization components. And it allows you to kind of best of both worlds a little bit, right? It doesn't solve the skillset situation, right?

No. You're still living in a hypervisor world. But, so I think that more and more companies are looking at that as a little bit of a stepping stone.

It doesn't feel as scary. It puts them on the path, and they do get the benefit of also then thinking about AI, right? It's like, wow, I can actually start to think about this in a more unified way if I'm thinking about virtualization and containerized applications or workloads sitting side by side, and then can I just train everybody on that?

And so that architecture, and how that works, and unfortunately that whole open source ecosystem makes that fairly digestible. There's all the components to do that. Assuming skillset.

Yeah. So assuming skillset. And I still believe that it would be worth your time and money, especially if you're trying to reduce cost and you want to move to that, spend some of that money on upskilling your workforce, right?

Because you're going to have the loyalty of those people. And I hope, and I've said this a couple of times the last couple of weeks, that we are over this hype cycle of 30,000 agents equals 30,000 engineers, or 30,000 agents equals 60,000 engineers, or whatever the math is. One to two, one to five, one to 10.

I think we've learned that it's not a It's not a simple algorithm like that, right? No. They are doing different things, and they are compatible.

And yes, you may get some efficiencies, but it's not a replacement strategy. Agreed with you. Now, in that modern virtual- Mm-hmm ...

is that strictly public cloud? Is it hybrid? No, it could be totally hybrid.

Yeah, you could still do that on-prem or private cloud. I think that is the beauty of the promise of Kubernetes and containers, remember, is that portability, right? Where do you want to go?

Now, we do know it's not so easy as you're saying, that it's like, here's the container in a simple little box, and you can just move it over. There's a lot of things that go on around that. And I think that also speaks to this overall plan, which is, what are the dependencies?

What are those interdependencies? Where is the data? Where are the other applications that touch the workload that you're trying to modernize or that you're building new?

And nothing is ever on an island, as I like to say, and completely separate from the rest of your IT environment. So we've got to start with the application or the workload or the experience that we're trying to create, and then back into the infrastructure and all the dependencies. And data obviously is a huge part of that.

And now, of course, it's like talking to the GPUs and everything else. So there's other- Well, that's what I was going to ask you. If you're going to have a grand unification theory today, you got to have AI in there.

And- Grand unification theory? That sounds like we're talking about Einstein or something. Einsteinian physics, yeah.

But seriously, AI, I'm not saying it's a complication, but as you said, it may not be the number one need, but it's the number one spend. And- Correct. But that's where things like-- It is so amazing how quickly we've gone from an agent to an agentic ecosystem to now MCP, not just servers, but gateways and proxies and also an ecosystem.

And so I'm actually trying to wrap my head around, even for marketing, because our agentic ecosystem has become so complicated, and I'm trying to understand, are we going to be using MCP for this? And then obviously within that infrastructure, how you're using MCP to kind of be the control, I don't want to say plane because that's not right, but it's almost like the air traffic controller, if I was to come up with a- It becomes a nexus point, right? Right.

Yeah Where things come in and out, but they all go flow through that nexus. You still have APIs. If you look at the Kubernetes infrastructure or architecture, you've got APIs bringing things and going.

Now we've got agentics coming and going. We've got MCPs sending things back and forth. So I'm trying to kind of wrap my head around what kind of is the connectivity, and I don't mean that like lower layers of the OSI stack literally, but- No ...

the connectivity of this architecture to allow that freedom of motion, that freedom of modernization, the old with the new, which everything's going to have. There's going to be some data that an AI workload needs to go after. So I think that is the bigger challenge, which touches this VM phenomenon or modernization or modern vert or whatever we want to call it, but it doesn't solve it.

And everyone's environment's different, right? Nothing's going to be exactly the same. And that's what I was saying earlier.

But here's the ace in the hole for this. That AI stack, for lack of a better word, or that AI, I can't think of a better word than stack. Yeah, stack's good.

That AI stack is the cloud native stack. Correct. So they share that commonality.

And at some level, that's got to make that communication, that back and forth easier because- Yes ... underneath, when you do get into those lower layers, there's a common stack there. And I- Yeah, the difference is just the GPU infrastructure below, and then we've got different tooling, libraries, and binaries for AI specific above, but it's not a fundamental change in how we were architecting workloads before.

So I think you're right. Right. Yeah.

And actually, I was positively moved to see NVIDIA actually put a bunch of money into Linux Foundation and Cloud Native because their stack they're building is actually- Right ... built on this as well. So I think that is going to become a standard.

Well, this is what I'm saying. When people say that AI is eating software as lunch, they ain't talking about infrastructure software because every data center on the planet is going to have infrastructure software to run all of that hardware and GPU power. And Linux is still foundational to all of that, right?

Linux is still running every modern stack that we can think of. So, when you think about things that haven't changed, Linux, Kubernetes, I think we're still going to need some level of orchestration above that and automation and stuff. " Yeah, you could roll that your own pretty quick.

And even observability. I'm really curious. I came out of that space, as you know, but- Mm-hmm ...

I have a theory, so we'll see if this is true. So I'll make this public, and then somebody can yell at me if I'm wrong. But I really believe that observability is going to get more and more consumed in the platform as opposed to being a separate stack, because it just- It doesn't make sense.

No, it hasn't. Right, and it's genetics. You know what?

Mitch Ashley- Right. Genetics and tagging. Right.

Yeah. Mitch Ashley's written a ton about this, about observability- Oh, has he? Oh, I didn't read that.

So sorry, Mitch. I'll get you some of the stuff. Okay.

Observability and power. Oh, I didn't make this up? This isn't...

No. Well, no. You know what?

Parallel evolution. It's your original product. I was kidding.

But this whole thing is, absolutely, it's in there. I wanted to bring up another issue, and we touched on it a little off camera. As part of this modern VM- Yeah ...

I think it's almost like any old hypervisor will do. Do you know what I mean? I don't need a Rolls Royce hypervisor.

I don't even need a Cadillac hypervisor. I could use a Chevy or a Ford because what I use the hypervisor for- Yeah. I think this is a really interesting question because I didn't see this coming, to be honest, and we have a lot of customers who are looking at everything they have in their virtualized environment, all the applications they have virtualized, and saying, "Okay, some of these I do want to move to modern virt or just containers.

" And they're looking at just Linux, Vanilla KVM, and they know it's not feature to feature. Right? We're seeing this a lot even with SAP workloads, right?

And so I think there is going to be a little bit of a, I don't know what to call it, like a decision grid around, okay, what is the life of this workload? Am I going to end life it in two, three, four years anyway? Is it really worth it?

But I do need to reduce cost because I can't keep paying this amount of money. I already have Linux contracted. It already has KVM in it.

Obviously KVM is embedded into Kubert as well, but I think that it's a little bit different implementation, obviously. So, I think there's different ways that people are looking to solve the overall, as you're saying, virtualization conundrum, depending on what their biggest pressure point is. If it's just pure cost, but they also have to look at that workload itself and what's happening with it.

But I think you're absolutely right. I think they are starting to say that, which is a very different strategy. Yeah.

And it kind of goes against 25 years of hypervisor product development and feature development, right? Well, yes. That is very true.

But again, I think it always goes back to what do I need to do with this specific workload? Don't start with the infrastructure, start with the application or the workload, and then back into the infrastructure. And if you have a set of criteria, and this is something I've done workshops with customers for s- many years around this, and it's really fun to do because some companies just don't have this, which is do you have a consistent criteria to judge an application and what should happen to it?

Everything from security to data, to dependencies, to access. Is it external? Is it internal?

Is it mission critical? Is it revenue generating? I mean, I know you could have 30 different criteria, but the key is using that same criteria consistently against all workloads so that you can really adjust in a consistent way and say, "Okay, anything that fits this profile, it is ripe to go straight to Kubernetes.

Do not pass GO. " Right. This one, eh, maybe we leave it where it is.

Maybe this one we move backwards, we reduce cost, whatever it is, right? Just keep it alive. Which is, we're seeing that with a lot of older versions of software that they're trying to figure out it's not broken, but obviously I need to keep it patched for all the reasons, I think we talked about security ad nauseam last time.

But how do I minimize my risk while keeping my cost to a minimum for this group of workloads? And they may decide, I'm just going to pay minimum support. I'm going to keep it patched, but I'm going to move as much as I can off.

Right? I think that's one way. So, my point though is...

Well, let me tell you something else that really confuses the heck out of me, and I don't mean to put you in a bad spot, but I'd like your opinion. Okay. Public cloud providers.

Mm-hmm. Their stance on this particular issue confuses the heck out of me because I think, and look, we're talking about three of them really, right? For the most part.

Four. But their stance is whatever you want to use is good enough, right? We'll support whatever you want.

But if you don't want anything or you're not sure, here's ours. Here's the home brew. Right?

And I'm not a big home brew fan personally, but that's beer or whiskey, not stacks. But you have partnerships with all of these public cloud providers, and I get that. As do most infrastructure software companies, right?

Yeah. Well, you have to because there's three of them, or four of them, as you say, and you can't afford not to. But should they be a little bit more forceful, or should they just be I'm Easy Eddie, whatever you want is good?

So, I always say look at a business model, a revenue model, and it will tell you how people behave. Right? The same is true if you look at a Google.

They behave a certain way because how do they make money, right? So if you look at the public cloud providers, how are they making money? On how much capacity, how much consumption people are using of their cloud.

If that consumption is on their Kubernetes or someone else's Kubernetes, it doesn't matter because they still have the consumption, right? And the business model says, "Oh You have 100 credits with me. I don't care if you use that with SUSE or someone else or our own EKS or whatever it is.

So now, if their model only gave them revenue, if people used their flavor of things, you would see very different behavior. I agree. It's just a self-fulfilling prophecy.

As much as people are locked into a cloud because they have tended to sign contracts for a certain amount of money to save cost, to do reserved instances, et cetera, I think the clouds still want to be seen as this neutral, like you were saying, like, "Oh, you can use anybody's Linux. " Right? It's a little bit of a false promise because the reality is you're still locked into their infrastructure.

But, at least you have that choice. And I think that the question is, architecturally, do you need to make a bet on a certain flavor of Kubernetes and run that everywhere? Is there benefit to that?

If you remember the early promise of containers, that was it. Right? Right.

You can run it from bare metal to multi-cloud and it's just- On top of VMware or not, or- Right. On top or not ... cloud provided Yeah.

But the reality is I'm not seeing that portability, let's call it, or mobility of workloads in containers like we used to talk about it. No. I used to be at fault to doing that, too.

Well- One, because it's not that easy because of all those dependencies that I just talked about before. Well, but to me, that always stunk of Java. Right?

Because isn't that what they told us about Java? Oh, that hurts. Ow.

Wow. I'm sorry. No, but I'm a Java fan.

Java's great. The write it once, run it everywhere. Right.

Yeah. And you see that same language, how many times do you see that from cloud-native vendors, right? Yeah.

Build it once, run it anywhere, everywhere. Which is still true. It does run anywhere, but that's not wrong, but you're not going to be picking it up and moving it like you're going to go from San Diego to LA in your station wagon.

No. If there's even still station wagons. But, I think that your ability to decide where you want to run it is the power of that.

So there is benefit, you could say, in having a non-native Kubernetes using in a public cloud because you could move it to a different public cloud. You could move it back to on-prem. And we are seeing some repatriation.

Or you could run it on multiple public clouds. You could. You know what?

That used to be the promise. I'm going to be honest, architecturally, I love the concept. I'm not seeing a lot of workloads that run across different public clouds.

So it's siloed. So I might have this app running on AWS and my that app is running on Azure. The hybrid I'm seeing is you have something in, let's say, a public cloud, and you have dependencies or datasets one place or the other, right.

That may be true, but I am not seeing how we used to talk about that was literally an application that ran across different clouds at one time. Just because the connectivity, the latency and everything, I think it's just too complicated. Now, you may choose in one geo to have a workload in a different public cloud, but that's different.

Again, that's more of a, might be a sovereignty decision or something else. Yeah, that could be more of a sovereignty thing, or a compliance thing. And you've not even seen that with DR.

Even in disaster recovery, I'm not seeing two different public clouds to de-risk your business continuity. I'm seeing more two regions in the same public cloud. I've lived that life, actually, to tell you the truth.

Margaret, we only have about another minute or two. I wanted to return to AI, though. Okay.

Because, as I said, I just got back from Black Hat in Vegas, and I've never seen so many loud bells and whistles and lights and people screaming to get your attention. Oh, that sounds horrible. It's clearly all around, and Las Vegas is like that, but Black Hat's worse.

But it was all around agentics. It was all around AI. It was all around, do you know what's in your stack?

How are you securing your stack? How are you monitoring it? How are you observing it, right?

Observability. Yeah. Absolutely.

How big a push for SUSE, for instance, how big an effect is this having on, wow, this is where we've got to maybe move our roadmap, or we've got to adopt or adapt to it? That's a big question. I think there's many things underneath that.

One is that just zero trust security model becomes even more important. The trying to get to whatever you want to call it, zero CBEs or just real-time patching. All of those things are happening, and I think everyone knows it's a reality.

I'm a little cynical of how far some people are going with saying we will keep any software safe no matter where it comes from in the ecosystem, because it feels like an unwinnable game. So, not to name names, because I'm too close to it. Right.

But I think that it is an absolute bar that security and observability and auditability and transparency is paramount. Which takes us right back where we always start, which is open source, that you cannot do any of those things if you cannot see it. Right.

So if you just trade your current virtualization black box for an AI black box You are not able to audit and observe and transform and keep it safe because someone else is doing it for you. And can you trust them? Yes or no?

I don't know. You need to be able to at least know it's happening even-- And it's not going to be most people's core competency. That work is really, really hard.

Yeah. Now, agentics, I think, are powerful here because agentics can absolutely, faster than any human, and it's been proven with everything we've talked about before, can find vulnerabilities that would take us years. That is wonderful.

The problem is we're treating all of those as the same. And what we used to do is say, "This is a critical vulnerability. " But now agentics are like, "Ah, there's a thousand vulnerabilities.

" So, like with everything, there needs to be a pragmatic and calm kind of like, okay, let's make sure that these are things we actually need to do. Because no software is ever going to be 100% bug-free, and I feel like people are talking about software like somehow we can get there. And it is just, I don't know how that's possible.

Maybe I'm cynical, but I just, it's never, I mean- No, so I spoke to a lot of people last week, and the quality of our software will improve as a result of this. 100%. Like it's going through the crucible, and you come out the other side of it- Yep ...

stronger and better. Yep. But it's going to be probably not in our lifetime that you can even- Well, I don't think you can depend just on humans, and you can't depend just on agentics.

No. And I feel like we're choosing sides, and that's not the answer, right? So I don't know if you're familiar with recursive AI, right?

Mm-hmm. And this is something people are afraid of now, where the AI builds its next version of itself. Right.

And if we got to an era of recursive software- Mm-hmm ... where every time the AI found another bug, it almost fixed itself, regenerated- Right ... a better version, and you could speed that up at AI scale, but this is like Star Trek kind of stuff.

Right. But again, yes, self-healing. We've talked about self-healing environments for a long time, but I think the thing that- The thing that's never real is it could be almost now ...

true, and I think you can see how we could get there, and I'll just leave with this last thought, is that my only hesitation is going back to what we've said. No piece of software is being healed in a vacuum, right? So the thing that's, and you've seen this a million times, how many times has somebody's pushed the button to put the latest version out or release patches and what happened?

The entire fricking system went down and all of a sudden, sites everywhere were compromised. " So it could map that out and still know it. But I think we have to be able to say it can do that within a safety realm that is not going to screw up everything else, because that is always the problem.

And we want to get to iterative releases. We absolutely do. That is the right thing to do.

Right? Yeah. It has to be seamless, it has to be painless, and it can't break everything else around it.

And that is the hard part. And maybe that's where this agentic ecosystem and MCP comes in and all of that because they can talk to each other, and that's already happening. It can say to one agent, "Hey, I'm going to do this.

" Yes, no. No. Okay, go to the other agent.

Do you have dependencies? And it can do it in milliseconds, right? Right.

And that's the promise, though, because it happens at AI scale. But- Right ... our time today is up, Margaret.

I just want to mention for people, we're going to try to do this every two weeks. So the last one came out. This one will, you're hearing this.

In our next episode three, is AI creating the mother of all lock-ins, is the subject. And this is, not to go Saddam Hussein on us, but this is going to be a great conversation. I'm looking forward to having it.

But Margaret, it's great. I'm happy, glad you're back home. Thank you.

I don't want to embarrass you, but you've gotten some awards. I'm going to leave it at that, and they were well-earned. People can look on LinkedIn.

But until next time, I'm Alan Alan Shimel, and she's Margaret Dawson. Margaret Dawson. "