One of the things I’ve found is that people either over-explain VCF’s architecture as if it’s completely alien, or they gloss over it entirely with a “it’s just vSphere + vSAN + NSX” summary that misses the point. Neither helps if you’re the person who has to design or justify the thing. So let me try to walk through it in a way that’s actually useful.
The first time I looked at a VCF 9.0 architecture diagram, I kept trying to map it to the old VCF 5.x model. That’s the wrong instinct. It’s a genuinely different thing. Once that clicked, the rest made sense quickly.
The Five-Layer Model
VCF 9.0 organizes into five logical layers. They’re not rigid tiers in a classic three-tier sense (they interact constantly) but thinking about them as layers helps when you’re designing capacity, planning upgrades, or explaining the platform to someone who signs the budget.
Layer 1: Compute, vSphere 8 / ESXi 8
This is the foundation, and it’s where most people are already comfortable. ESXi 8 introduces a reworked kernel I/O path that cuts CPU overhead significantly, particularly for east-west storage traffic within the cluster. GPU vMotion is the headline compute feature: live-migrating a GPU-backed VM now streams GPU memory rather than pausing it, which makes migrations 6x faster and keeps inference workloads running during host maintenance.
NUMA-aware scheduling has also been tightened. For large multi-socket hosts running memory-intensive workloads (databases, in-memory caches, ML model loading) the scheduler does a better job of keeping compute and memory access on the same NUMA node, which shows up as lower latency without any config changes.
Layer 2: Storage, vSAN ESA
I ran an ESA cluster in my lab for about three months before I noticed the difference in latency profiles vs. OSA. Noticeable. vSAN in VCF 9.0 defaults to the Express Storage Architecture for new deployments, and ESA is the recommended path where hardware supports it. That said, vSAN OSA (all-flash configurations) remains supported in VCF 9.0. It’s the older hybrid OSA configurations (spinning disk + cache flash) that are deprecated. If you’re upgrading from vSAN OSA all-flash, you can continue running OSA or migrate to ESA; migration is an option, not a requirement. The difference matters: ESA is a ground-up rewrite of the I/O stack that eliminated the disk group model entirely. Every drive participates in a single capacity and performance pool, which simplifies management and improves both throughput and fault tolerance.
Two notable storage capabilities arrive with the VCF 9.0 lifecycle. Global Deduplication extends the dedup domain from individual nodes to the entire cluster, meaning if your VMs share a common OS image or application binaries, those blocks are deduplicated once across the whole cluster. Note: Global Deduplication launched as a limited availability feature in VCF 9.0, initially requiring a Technical Qualification Request (TQR). It reached general availability in VCF 9.1. NVMe Memory Tiering lets ESXi treat NVMe-attached flash as a second memory tier below DRAM, working set pages that haven’t been touched recently migrate to NVMe, hot pages stay in DRAM.
Layer 3: Networking. NSX
NSX 4.x in VCF 9.0 is still NSX, but the operational model has changed. Instead of configuring NSX through its own dedicated console, networking is now consumed through VCF Operations as virtual private cloud (VPC) constructs. A workload team declares a VPC, and NSX spins up the routing, load balancing, and micro-segmentation rules automatically based on policy templates the infra team pre-defined. vDefend integrates as well, lateral security policies travel with the workload, not the network segment.
Layer 4: Workload Services
VMware vSphere Kubernetes Service (VKS) is fully integrated and managed through VCF Operations. You can run a Kubernetes cluster on the same ESXi hosts as traditional VMs, under the same storage policy, patched through the same lifecycle workflow. Argo CD is bundled for GitOps-driven deployments. For AI workloads, VCF Private AI Foundation with NVIDIA is an advanced service that handles GPU cluster provisioning and model serving infrastructure within the VCF operational model.
Layer 5: Management Plane. VCF Operations and VCF Automation
The standalone SDDC Manager portal has been retired from day-to-day operations. Its functions, lifecycle management, certificate operations, password management, host commissioning, are now surfaced through VCF Operations, which is mandatory in every deployment. The SDDC Manager appliance continues to run as a backend orchestration engine; operators no longer interact with it directly, but it remains part of the platform. VCF Operations introduces a fleet concept: you can manage multiple VCF deployments across different sites from one console. VCF Automation handles the consumption layer, self-service catalog, Terraform providers, REST APIs, and GitOps integrations. The two tools share the same policy and cost model.
Single Installer, One Lifecycle
VCF 9.0 uses a single installer that brings the whole stack up together. There’s no “deploy vSphere first, then attach vSAN, then configure NSX” workflow anymore. The VCF Installer handles discovery, configuration, and validation of all five layers in one orchestrated process. The same principle applies to upgrades. VCF Operations coordinates the upgrade sequence across all components in the right order, with pre-checks that catch known incompatibilities before a maintenance window begins.
Where to Go From Here
If the architecture makes sense and you want to see how it maps to actual deployment scenarios, the next post in this series covers five real-world use cases. AI infrastructure, sovereign cloud, hybrid workloads, cloud repatriation, and multi-site management.