We’ve been talking about “private cloud” for, what, over a decade? It’s a term that meant a lot of different things. For a long time, it just meant running vSphere in your own data center. You had VMs, you had vMotion. And that was great. But it wasn’t really a “cloud” experience. Not in the way developers and platform operators think of it now. A real cloud experience is about services. It’s about a self-service, API-driven way to get the resources you need, right now. You don’t file a ticket and wait three weeks for a VM. You ask for it, and it appears. And it’s not just VMs. It’s Kubernetes clusters. It’s storage. It’s networking. It’s a whole ecosystem of services.

This is the gap that VMware by Broadcom addressed during Tech Field Day at KubeCon North America 2025. Enterprises have all this infrastructure, but their internal users, the developers… they just want the public cloud experience. They want to move fast. How do you give them that, but in your own, controlled, private data center? This is the problem VMware Cloud Foundation (VCF) is set up to solve. It’s not just about managing virtual machines anymore. It’s about building a platform. A platform that offers a complete ecosystem of services. It’s not just one thing. Out of the box, VCF provides three core runtime services. 

1. vSphere Kubernetes Service, VKS. This is for running your modern, containerized applications. 
2. VM Service. This is the cloud-like, self-service way to consume vSphere VMs. 
3. Container Service, for those times you just want to run a container without needing a full-blown Kubernetes cluster.

This isn’t about forcing everyone onto one runtime. It’s about providing choice. Because the reality is, applications are not homogeneous. You have new cloud-native applications and old client-server applications. You have a database that needs to run on a VM, such as MySQL. And you have a front-end and a back-end app that are perfect for Kubernetes. A real platform has to handle all of them, together.

This is all about Cloud consumers: platform operators and app developers. They are the customers of the private cloud. And what do they want? They want to deploy their workloads quickly. They want to use the tools they already know. They don’t want to learn a whole new proprietary way of doing things. They just want to build their app. So, how do you do it? How do you make all these different resources (VMs, Kubernetes, storage) feel like one, single, consumable platform?

This is the clever part. VCF provides a declarative API surface. It’s called the vSphere supervisor, and it lets you consume all of these resources through the Kubernetes API. It means that platform engineers and developers can use the tools they are already completely familiar with. They can use kubectl.

Want a VM? You can apply a YAML file that defines a VM using kubectl.

Want a Kubernetes cluster? Same thing. kubectl apply.

It completely changes the game for infrastructure consumption. This also means you can plug this entire private cloud platform right into your existing GitOps workflows.

There was a demo of this in the Broadcom Tech Field Day presentation at KubeCon 2025. A three-tiered application. It had a MySQL database in a traditional VM. It had a VKS cluster running the front-end and back-end applications. And the whole thing was deployed, end-to-end, with Argo CD. A developer just pasted the application YAML. And Argo did its magic, figuring out the VM and the Kubernetes cluster, then the secrets and volumes needed. Then the platform just built it.

This is possible because all the resources are treated like Lego blocks. They are all sitting in the same bucket, all accessible through the same API. It’s not just the runtimes. It’s also the Secrets, Volume, Network, and VM Image services. When you add a new service to the VCF ecosystem, it automatically becomes discoverable through that same API. This is what public cloud CLIs have done so well. You have one command-line tool with plugins for S3, EC2, and Lambda. VCF is doing the same thing. There’s a new VCF CLI with plugins,  with a consistent, discoverable experience.

Now, you might look at that three-tiered application demo and think “Hey, that looks complex.” You’re deploying VMs and Kubernetes clusters, and services all from one YAML file. But that’s the point. The intent isn’t to force that complexity on everyone. Most developers will just consume a namespace in a VKS cluster. The point is that the flexibility is there. The platform can handle these complex, hybrid applications through a unified API. This is what makes it a private cloud, and not just a virtualized data center. The namespace provides isolation and a unified API that provides self-service and discoverability. You’re giving developers the boundaries and a namespace in which they can build what they need using the services the platform provides.

This is the advantage. It’s not just about having VKS. It’s about having VKS as a service inside a larger platform. A platform that also understands VMs, storage, and networking. And a platform that presents all of this to the user in a single, consistent, API-driven way. It’s about turning your data center into a true, self-service cloud that can finally, actually, compete with the public cloud experience. It’s about giving your teams the tools they want, in the way they want to use them. That’s the real end goal.

Watch the full VMware by Broadcom presentation or catch up with all the events on the Tech Field Day website.