Why Kubernetes Still Needs VM Infrastructure
The narrative that Kubernetes would eventually kill the virtual machine has officially been debunked, as the industry wakes up to the reality that managing bare-metal clusters at scale is a complex and costly nightmare. Weigue He, Sr. Director of Product Marketing at Broadcom, explains how VMware Cloud Foundation is leaning into its decades of infrastructure experience by seamlessly integrating dynamic GPU resource allocation to make AI workloads more accessible. As organizations grapple with out-of-control hardware costs and the need for rock-solid security, the smartest move isn’t ripping and replacing your CI/CD pipeline—it’s running those modern containers on the proven, resilient foundation of VMs.
Transcript
Hey everybody, we're back in Amsterdam at the KubeCon + CloudNativeCon Europe event, and we're talking to my friend Weigu from Broadcom about what they're doing in the open source community and all the good things that are going on there. Starting with, there's this new project that you guys have donated to the CNCF, Valero. What exactly is that, and where does it fit kind of in the spectrum of things you guys are working on?
Of course. So Valero is a software that allows you to do backup, recovery, disaster recovery as well, and also do migration. So with this tool, it allows the enterprises to plan for their data and configuration to be consistent and to be able to recover it as well, right?
And if you look at Valero, it's really placed in this enterprise space where we focus on operations. And as we always do at VMware, operations for enterprise scale is very important. You look at all the other projects we contribute to, for example, etcd, Cluster API, et cetera.
So we bring our decades and decades of experience in running and managing private cloud, and bring those operational experience into this new Kubernetes space for our customers as well. Nice. Now, historically, VMware had kind of a Kubernetes approach where you could run it natively on the VMware Cloud Foundation.
Mm-hmm. And then there was Tanzu as well as kind of a project. Are those two still kind of the main Kubernetes engagement paths for you guys?
Or what's the relationship there? So that's a great question. The only engagement in terms of VKS, that includes VKS runtime or Kubernetes runtime, as well as all the cloud services that you need to run Kubernetes, are all based on VCF and in VCF actually.
It's part of the VCF software stack. Now, Tanzu as a separate product division, and they have their own product portfolio, is going to focus more and more on this PaSS platform where they use the technologies from Cloud Foundry, et cetera, to focus on this developer experience. But when all things come to Kubernetes, it's VCF.
Got you. All right. Is there something right now that you perceive that is...
If you have a wish list of things you wish the community would prioritize a little bit as it relates to Kubernetes from your perspective, what comes to mind? Well, again, going back to our heritage, in terms of infrastructure and operations, right? So we will very much like the community to continue in that space to bring all this cloud experience to the customers.
I'll give you one example. If you think about, let's say, dynamic resource allocation, DRA. It's all about GPU resource allocation and everything, and surface that up to the Kubernetes clusters.
And guess what? We have been doing this for many years at the VM level already, right? In terms of presenting the GPUs as assignable hardware, and if you look at Kubernetes constructs, the device group, the device class, and the resource claim, et cetera.
We have very similar concepts in the VM space already. So it was so great to see the emergence of DRA since last year, and we think there's a great opportunity that we can marry that technology and use the constructs that we have in our stack and make the GPU and AI workloads more accessible to our customers. Of course, at the show, AI workloads has been one of the main topics, and specifically AI inference.
Yes. Are there things that organizations need to do to optimize those workloads for Kubernetes types environments and open source? And it seems to me there's a lot of projects we're walking around here that are related to that.
What are you guys looking at or thinking about? So we are taking two approaches, but they are very much related. The goal is to meet customers where they are, right?
So by that I mean, number one, in our VCF stack with VKS, we still provide a bunch of packages and services that developers and the platform engineers will need to build their applications, the workloads to run in Kubernetes. So they have that option if they just want to simply consume out of the box that customer experience. On the other hand, we also, again, meeting customers where they are, we understand, and many of the enterprise customers also tell us that, "Hey, over the last few years, we have built up our own CI/CD pipeline," for example.
"We have our own tooling and everything. " Right? So in that case, we are working with the broad ecosystem and a lot of the partners who are at the show as well.
You probably saw the announcement earlier this week, in terms of partnership with Kong, et cetera. So we work with all these partners and CNCF projects to validate how to make those same tooling and the platform work with VCF. So we will not only provide, let's say, reference architectures or technical validation.
In certain cases, we may even provide a Git repo, for example, so that customers can sample those repo code and just basically deploy the same exact tooling that they have and make the workloads run in VKS naturally, right? So with both approaches-Again, coming back, meeting the customers where they are and make sure the best outcome for them based on what they prefer. Is there more convergence now between the VMware world and the Kubernetes world?
Because historically, I can remember when Kubernetes first came out, there was this general feeling that Kubernetes would compete head-to-head with VMware. But now, in hindsight, it looks like most of these Kubernetes clusters are running on virtual machines anyway, and maybe we're starting to see some convergence. Yes, I think that's exactly what we see as well.
Essentially, regardless of whether it's a modern workload that runs in containers or running in VMs, first of all, they all need infrastructure, right? Whether that's compute, storage, networking. And there are certain characteristics that developers would expect.
For example, performance, security, very important. You don't want your application to be the landing spot for security vulnerability or ransomware attack, right? And you definitely don't want your applications to go down.
So the reliability and all those aspects are very important. And vSphere has been at the center of the data centers, if you will, in the last more than two decades now. That's what we do best.
Now, there's also when you run Kubernetes and containers, I think there is a trend, and many analysts are pointing out already, for example, IDC predicts by 2028, 85%-ish of the containers will continue running in VMs. And that's what the hyperscalers do as well, right? So what that provides is really the level of resource isolation, security, and we like to say that we provide six layers of security all the way from the hypervisors to the containers and the namespace, right?
All that provided in VM and resource consolidation and the utilization. Think of today, the hardware cost is out of control. And vSphere, what we do at best is this resource utilization and consolidation that makes sure that we can save you tremendous amount of cost by running this architecture, and that remains to be true.
And more and more customers, I think I even see some solutions on the expo today that actually gets to what we have been doing for more than two decades. So that's definitely happening, and I think that will continue. Now, it seems there's more nuance in the sense that the applications are becoming more distributed.
Yes. And there's elements in the cloud, there's elements on-premise, and there's elements at the network edge. So is that changing the way we think about this infrastructure conversation because the workloads need the...
There's just a higher degree of interoperability required. Yes. So in my view, two points, right?
Number one, going back to meeting customers where they are, our infrastructure doesn't have to be in your own data center. So our software stack can be deployed on the cloud, in the data center, or on the edge. So that gives you that level of consistent infrastructure wherever you want to run your workloads.
But secondly, I think it comes back to this VKS. It's a conformant Kubernetes distribution, right? So what we do is we was, again as I said, we may have some opinionated offerings or packages, services that goes with the solution, but by and large, it's open source, it's very conformant with Kubernetes.
So that allows the customers to move workloads to any Kubernetes conformant clusters if they choose to do so. And that's tremendous benefit to our customers, as you can see. And there's a benefit, obviously, being conformant that gives us agility or time to speed us to production for our customers.
By that, I mean whenever a new Kubernetes release comes out, typically within two months, we will be able to validate and certify that our VKS cluster will be able to allow customers to consume the latest and greatest Kubernetes release, right? Mm-hmm. That's on par with all the hyperscalers out there.
That level of agility allows our customers to consume the latest and greatest features. But again, if the customers so choose, they can move those workloads to another conformant certified Kubernetes distribution as well. So it's an open ecosystem out there.
Right. I have yet to meet anybody who's standardized on one particular type of distribution- Exactly ... of Kubernetes or much less the version number, right?
Exactly. And I would also add, in addition to the agility and speed, we also support multiple Kubernetes releases for our customers. So architecturally, we allow customers to deploy multiple VKS clusters.
It's not just one single cluster. So with this, it comes the benefit of isolation, security, et cetera, but also different teams may want to consume different features that's offered by different releases. That level of flexibility is there.
And on top of that, with 24 months enterprise support of all those releases gives the customers a great level of confidence with us. Now, we live in a world where there's greater sensitivity about cost, but if I look at the architecture and as I understand what you guys are trying to do, is the total cost of your approach going to be ultimately less because more of the components are integrated? No, I think ultimately what determines that is the value that customers get out of the solution.
So not only from the compute storage networking perspective, what we put together in terms of cloud operations and cloud automation, it's very important and essential to our customers operating their private cloud. So, and listen, we didn't invent some new infrastructure or things in that nature for Kubernetes world. We basically put a control plane on top of the same exact infrastructure as the same stack.
This integration creates the value not only in that sense, but also, the single unified APIs for customers to run and manage both their container workloads and VM workloads. That's tremendous value. So I think over time, that value will make the solution more resonate with our customers.
So does anybody at Broadcom keep track of how big the contributions are to the open source community? Because I think everybody thinks of a lot of other companies out there, but it's not clear to me that anybody knows what Broadcom's doing. That's a great point.
We don't talk about enough. We are starting to. org website that tracks the contributions.
If you look at the dashboard, VMware actually has been a top five contributor to CNCF over the last decade. Wow. And there are a lot of projects that we have contributed to.
In addition to the Valero we announced earlier this week, there were projects like Contour. There were projects like Harbor Registry. Of course, we contribute heavily to etcd, Cluster API, and all these different projects.
So a top five, and we should talk about more. And obviously, at this conference, we are starting to make a lot more communication to our customers about where we are and the future that we intend to go in contribution to CNCF. Is there any particular thing you have at the top of your wish list for the open source community that you just wish as a group we would all focus on a little bit more?
That's a great question. AI is top of mind for everyone, obviously. I saw some announcements about open sourcing some of the GPO drivers, things in that nature.
I think we can benefit from those as well. And then from the whole platform engineering landscape, if you look at it, there are a lot of things that's happening. org.
If you look at that reference architecture, what's interesting is, in addition to the developer side and obviously the CI/CD side, there are more planes that are being added to that reference architecture, including observability, security, and of course, infrastructure and the resources. So I think we play very well in those planes, in terms of security, observability. We have our own solutions.
But again, going back to the open ecosystem point of view, we would welcome CNCF contributions and projects that can benefit customers in those spaces, and we would love to integrate and validate some of those solutions. Give customers the choice. So as we see more and more of those projects mature, we will try to give customers more guidance and, at some point, as integration is needed, we'll try to do that as well.
All right. " I still see a lot of things managed in isolation on my side, but what are you seeing? Yes.
So at enterprise scale, cluster management, for example, is a big thing in terms of life cycle. From deployment to update, upgrade, patching, and all that. So at that scale, you need multi-cluster management and the multi-cluster life cycle management capabilities to go with it, operationally, to be excellent at it.
So I think some of the customers may see Kubernetes as a simple platform, which it's not. It's very complex. So I think customers will realize, in addition to the broad ecosystem and all the projects they have to stitch together just to run Kubernetes, they will need to start thinking about the scale that Kubernetes needs to be run and the scale the Kubernetes clusters need to be managed, et cetera, et cetera.
And more and more of that will need enterprise level features and capabilities, not only coming from vendors, but also from the CNCF projects. So I think customers will realize over time. All right.
Folks, you heard it here. Hey, no matter how complicated things get, at the end of the day, when it comes to IT infrastructure, there's a good rule. It's called keep it simple.
Hey, Wingu, thanks for being on the show. Thank you, Michael. All right.
My pleasure. And we'll be back in a minute.