Last week I promised to dig into the operational shift from classic vSphere to VCF — the moment teams stop thinking "I manage clusters" and start thinking "I consume workload domains." A lot of people read that and heard philosophy. The actual problem is operational, and it's concrete.

This is the issue I see blocking the second wave of VCF deployments right now.

If you're coming from a 15-year vSphere background, here's what your brain is wired to do:

You provision infrastructure. You size CPU, memory, storage. You build networking policies. Then you hand it to your applications team and manage it at the cluster level.

VCF inverts this.

In a VCF workload domain, you're not managing a cluster. You're defining a consumption surface. The workload domain tells you what goes in, what performance boundaries exist, and what failure domain isolation you get. The cluster underneath is an implementation detail that someone else (your VCF admin) owns.

This sounds academic. Here's why teams struggle: You can't think like a cluster operator in a workload domain environment. The tools are different. The validation questions are different. The failure modes are different.

When you request a workload domain, you're not asking for a 24-core cluster anymore. You're asking for a service level: "I need 200 vCPU allocation with 2x redundancy in this availability zone, dedicated network segments, and persistent volume capacity for stateful workloads."

The VCF admin then has to map that to actual hardware. If they can't, that's a real problem — but it's not your problem to solve with bigger servers. It's a workload domain sizing problem.

Most teams I see are still thinking cluster-first. They say "we need 256GB of RAM." What they mean is "we don't know what service level to ask for." That confusion will eat up your deployment timeline.

In vSphere, you're managing the infrastructure. Your CAB (Change Advisory Board) meeting is about validating infrastructure changes.

In VCF, your workload domain is immutable once provisioned. Requests for more capacity, different network segmentation, or additional storage tiers require workload domain reconfiguration. That's not a small change window — that's often a rebuild conversation.

Teams that don't adjust their governance model for this end up with a slow approval process for what should be a fast consumption request.

Your application is slow. Is it a workload domain resource constraint? A network policy issue? Underlying NSX misconfiguration? A supervisor cluster problem three layers down?

In vSphere, you own all the layers. In VCF, you own the workload domain surface, and everything below is abstracted. If you keep thinking like a cluster operator, you'll spend six hours digging through cluster logs looking for a workload domain-level problem that never existed.

The Real Validation Framework: 3 Questions Before You Deploy
Here's how I'm approaching this with customers right now:

Question 1: "What does success look like in your workload domain, not in your cluster?"

Write this down: latency bounds, availability tier, capacity runway. Don't write "24 vCPU." Write "sub-100ms response time at peak load for this application family." That forces the conversation into service-level thinking.

Question 2: "Where does your change management actually break?"

Map your existing CAB process to VCF governance. Where does the old model assume you're managing infrastructure? That's where your process breaks. Fix it before you deploy.

Question 3: "Who owns the layer below your workload domain, and how do you escalate?"

This is the one nobody asks. If you can't clearly define the boundary between your workload domain and the supervisor cluster, you'll be fighting finger-pointing escalations for months.

Stop thinking "cluster admin" and "application owner."

Start thinking about three layers:

Workload domain consumer (that's you for this workload domain)
VCF platform owner (cluster provisioning, supervisor scale, NSX policy at scale)
Infrastructure owner (hardware, cabling, power, physical topology)

Each layer has different failure modes, different change windows, and different escalation paths. If your org structure doesn't map to these three tiers, you're fighting friction by default.

When you request a new workload domain from your VCF admin, do you ask for infrastructure specifications or service level definitions? If you're asking for specs, you're still thinking like a cluster operator — and that's exactly where deployments start to slip.

Next week I'm diving into the one NSX configuration mistake that shows up in 80% of the VCF environments I audit. It's not a bug. It's a mental model error about micro-segmentation that makes sense at the cluster level but breaks at the platform scale. And it takes three weeks to fix if you find it in production.

That's what I'm seeing in the field right now. If you're wrestling with the jump from cluster management to workload domain consumption, or if you've already hit some of the friction points above, I want to hear about it. The best issues of this newsletter come from the problems you're actually running into.

See you next week.

— Adam