The Fourth Cloud Vendor Map Is Live

I keep getting pulled into the same conversation with enterprise infrastructure teams, and it is no longer the conversation we were having three years ago. Nobody is short on places to run workloads. They have public cloud, private cloud, SaaS, Kubernetes, virtualization, edge sites, data platforms, identity systems, and a fast-growing layer of AI services threaded across all of it.

The question that actually matters now is not whether the enterprise has infrastructure. It is whether the enterprise has a control model. Where should a given workload run? Which data is it allowed to touch? Which policies apply? What context can cross a boundary? And when cost, latency, compliance, and capacity all point in different directions — who, or what, has the authority to decide?

That last word is the one I care about most. Authority. Not capability. Authority is the question I have spent years trying to make legible, and it is the reason I built cloud.layer2c.com.

What the map actually measures

The new site is a companion to layer2c.com. The parent site explains the 4+1 AI Infrastructure Model and the role of Layer 2C, the reasoning plane. The companion applies that model to real platforms against a different test: the Fourth Cloud operating model.

Fourth Cloud is not a product category any vendor sells today. It is an operating pattern — a uniform, AI-native infrastructure model spanning cloud, on-prem, and edge, with governance and control integrated across the environment. The first public map scores VMware Cloud Foundation, Red Hat OpenShift, Nutanix Cloud Platform, and Oxide Computer. It will grow.

It is not a magic quadrant and not a vendor ranking. Every platform is scored on two axes that most evaluations collapse into one. The first is capability: function by function, on a 0–4 gradient, with AWS as the benchmark 4. The second is the one I built this whole body of work around — the Decision Authority Placement Model, or DAPM. For each function, the question is not “how good is it” but “can I take the opinions I have accumulated here and operate them somewhere else?” Three answers: Retained (yes — commodity or open-source, I can leave without rebuilding), Delegated (partly — a substitutable partner or swappable open-source tool), and Ceded (no — a closed system, and leaving means rebuilding).

Completeness and authority are independent. A platform can be the most complete thing in the assessment and the most captive at the same time. Hold that thought, because it is the headline finding.

The authority finding

Here is the DAPM profile across all four platforms, counting the twenty-six scored functions each:

Read that table next to the capability scores and the tension jumps out. The two platforms with the broadest coverage of the Fourth Cloud function set — VCF and Nutanix — are also the two most captive. Roughly two-thirds of what you build on either platform is Ceded: the configurations, the policies, the operational model are the vendor’s, and you cannot lift them to a competitor without rebuilding. That is not a criticism. It is the trade you are actually signing for, and it is usually invisible at purchase time because the demo is about capability, not authority.

A note on what “broadest coverage” means here, because it is narrow. This assessment measures completeness against the Fourth Cloud function set — how many of the FC-0 through FC-4 functions a platform addresses and how well. It is not a claim about general platform maturity, engineering quality, or enterprise track record. OpenShift, for one, would reasonably argue it is the more mature platform by most general measures, and that argument is not in scope here. What the table shows is coverage shape against one specific model, scored on two axes — nothing more.

OpenShift sits in the middle, and the reason is structural. Its open-source heritage shows up directly in the authority column — Kubernetes, Keycloak, the operator ecosystem, the GitOps tooling are Retained or Delegated, not Ceded. You pay for that portability with a higher assembly and operations burden, but the opinions are more yours to keep.

Oxide is the surprise only if you were reading the capability column alone. It is the most authority-preserving platform in the map — 85% Retained — because it is built on a co-designed, largely open substrate and does not try to capture the layers above it. Which brings me to the assessment I think matters most.

Each platform tells a different part of the story

VMware Cloud Foundation has the broadest coverage of the Fourth Cloud function set in this group. It is strong at the substrate and at orchestration, with genuine VM, container, and AI workload management through one console — and VCF 9.1 now manages AMD, NVIDIA, and Intel accelerators, which makes it the broadest multi-accelerator platform in the set. The weaknesses are equally clear: the distributed data fabric is thin, the integration fabric is effectively absent, and the reasoning plane does not exist. The authority profile says the rest — the widest coverage here, and one of the two most Ceded.

Red Hat OpenShift has a different shape. Its strength sits higher in the stack — execution, application distribution, integration, and a genuinely federated identity plane through Keycloak that spans more layers than any other platform here. It is also the clearest illustration of the line between rule dispatch and reasoning. ACM placement policies, node affinity, taints and tolerations, OPA/Gatekeeper — these are powerful primitives. They do not become a reasoning plane until the platform can derive a placement decision from live governance metadata without an operator translating every new constraint into a rule by hand.

Nutanix Cloud Platform brings a strong HCI operating model and the broadest workload management of the on-prem group — VMs, Kubernetes, databases, AI inference, and cloud burst through NC2 — under one Prism Central surface. It is a serious answer for enterprises looking to leave VMware. And its authority profile is nearly identical to VMware’s: a complete control plane that is mostly Ceded. The integration fabric is absent and the reasoning plane is absent.

Oxide Computer is the most important assessment for a reason that has nothing to do with its scores. Oxide is not trying to be a complete Fourth Cloud control plane. It is a deeply integrated IaaS substrate, and the honest comparison is EC2 or GCP Compute Engine, not OpenShift or VCF. That is not a weakness — it is a clean layer boundary. Oxide may well be the substrate a Fourth Cloud control plane runs on. The instrument’s job is to make that boundary visible instead of letting a vendor’s marketing blur it, and the authority numbers confirm the architecture: Oxide leaves the enterprise holding the most of its own opinions.

The finding nobody closes

No platform in the assessment closes FC-2C, the reasoning plane.

That is not a cheap shot — it is the entire point of the exercise. FC-2C is the layer that decides where work runs based on policy, compliance, cost, latency, data gravity, and capacity, simultaneously, and derives that decision from live metadata rather than from a rule an operator wrote last quarter. It is not the model thinking harder. It is not a smarter dashboard. It is the enterprise control point that decides whether work is operating within authority.

When FC-2C is absent, the decision logic does not disappear. It lives somewhere else — in an architecture review board, in Terraform modules, in Kubernetes admission policy, in a ServiceNow workflow, in a platform engineer’s head. The danger is believing the platform has absorbed that responsibility when it has only automated pieces of the workflow around it. That gap — the capability you quietly inherit while assuming the vendor owns it — is where most private cloud programs have failed. The technology worked. The operating model did not.

What this map does not measure

There is a limitation worth stating plainly, because it is the first thing a practitioner will notice: the instrument scores each platform alone, and almost nobody deploys these platforms alone.

The pattern I see in the field is a pairing. A substrate and orchestration platform — Nutanix, VCF, or Oxide — mated to an application platform, almost always OpenShift, layered on top. That is not an accident, and the map’s own data predicts it. The substrate platforms are strong low in the stack and absent at the integration fabric. OpenShift is the inverse: weaker at the substrate, strong at execution, application distribution, and the only real FC-4 integration fabric in the set. They are complementary by construction. An enterprise stacking OpenShift on Nutanix or VCF or Oxide is assembling the coverage that no single platform delivers.

The instrument does not yet score that combination, and the reason is not laziness — it is that a combination cannot be scored by adding two rows. Three things break. The orchestration layer becomes contested, because both platforms have one and the combined score depends on how cleanly they federate at the seam rather than on either platform alone. The authority profile compounds rather than averages: running OpenShift on VCF means you are now Ceded to both vendors at different layers, and the real question becomes who owns the seam between them when it breaks. And the identity plane rarely survives the handoff — OpenShift’s federated identity, its strongest authority asset, sits on top of a substrate identity model that usually does not federate upward, so the combined identity continuity is often worse than OpenShift’s alone.

One finding is worth previewing, because it inverts the single-platform read. On capability scores alone, Oxide looks like the least complete platform in the map. But Oxide is 85% Retained — it preserves more enterprise authority than anything else here. Pair OpenShift’s higher-stack coverage with Oxide’s authority-preserving substrate and you get the lowest combined Ceded surface of any pairing: the most authority-preserving way to assemble a near-complete Fourth Cloud on-prem. Nobody is having that conversation, because Oxide gets dismissed on its single-platform capability column before anyone looks at the authority column. The combination view is where that changes, and it is what I am building next.

Why this is paired with a readiness framework

The map ships alongside the Fourth Cloud Readiness Assessment and Evaluation Framework, and that pairing is deliberate. Fourth Cloud is not only a vendor problem — it is an operating-model problem. Can your organization run infrastructure as a product? Can you sustain gap ownership across vendors, coordinating API changes, roadmaps, integration lifecycles, and compliance policy over a span of years? Can you tell the difference between a capability the vendor owns, a capability you configure, and a capability you quietly inherit?

That last category is the expensive one. The framework puts a number on it — a single owned gap runs to roughly $1.5–2M over five years once you account for the build, the maintenance through vendor upgrades, and the lifecycle coordination nobody staffs for. The map shows you where the gaps are and who holds the authority. The framework helps you decide whether you can afford to own them.

What it changes

When you stop asking “which vendor wins” and start asking the two-axis question — what can this platform do, and what authority do I keep — the conversation in the room changes. You stop buying a feature list and start mapping an operating model. You can see which decisions the platform makes for you, which ones you still own, where policy becomes enforcement, and where automation quietly becomes authority you didn’t realize you were ceding.

The Fourth Cloud is not something you buy whole today. It is something enterprises are trying to assemble. The only question worth asking before the purchase order is whether you understand what you are assembling, what you still own, and where authority actually lives.

cloud.layer2c.com is live. The map will grow, the assessments will evolve as vendors respond and buyers ask sharper questions, and the model will keep improving. But the two-axis view is the part I would not give up: capability tells you what a platform can do, and DAPM tells you who is in control when it does it.