Fourth Cloud — On-prem control plane assessment

Function-by-function scoring of on-prem control planes against the Fourth Cloud operational model: VMware Cloud Foundation, IBM / Red Hat OpenShift, Nutanix Cloud Platform, and Oxide Cloud Computer. Each vendor is scored on FC-0 through FC-4 layers plus identity plane continuity.

Enterprise on-prem control planes, scored against the Fourth Cloud operational model.

On-prem control planes assessed against the Fourth Cloud operational model. Function-by-function scoring (0–4), gap ownership classification, and a top-level identity plane continuity finding for each vendor — calibrated against the AWS hyperscaler benchmark.

Assessed control planes

Read the operating responsibility behind each assessment. Scores apply to individual functions. Layer summaries use their average; there’s no overall vendor score. Scoring and gap definitions →

9 of 9 assessments

Complete assessment · v2.8 ·

VMware Cloud Foundation (VCF)

Fourth Cloud Control Plane Assessment — Substrate-Agnostic

Identity plane continuity Siloed · 1/4

No. You cannot use FC-0 substrate identity to control FC-2B application runtime execution natively in VCF. A SOX-tagged hardware node does not automatically restrict which application runtimes execute on it. Enforcing that constraint requires the operator to write vSphere DRS rules, NSX micro-segmentation policy, and Kubernetes admission controller rules independently — three separate policy instruments, each requiring maintenance when the SOX tagging changes. The cost is not theoretical: every cross-layer identity enforcement requirement in VCF is a Closeable gap with Townsend's full Section 2.6 lifecycle burden. For an enterprise with significant compliance requirements spanning multiple layers, this is the most expensive gap in the VCF Fourth Cloud profile.

In plane: FC-2A · FC-2B virtual machines / containers

Siloed: FC-0 · FC-1 · FC-2B inference · FC-2C · FC-3 · FC-4

Function scores 26 assessed functions

0 · Absent
4
1 · Weak
1
2 · Moderate
7
3 · Strong
14
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
8
Opinion
10
Vendor roadmap
0
Structural
6
Mixed
2

Layer findings Open a layer to read the evidence

FC-0 SubstrateStrong
FC-1 ContextGap
FC-2A OrchestrationModerate
FC-2B RuntimeModerate
FC-2C ReasoningAbsent
FC-3 CatalogModerate
FC-4 IntegrationGap
Complete assessment · v2.6 ·

Red Hat OpenShift

Fourth Cloud Control Plane Assessment — Red Hat Vendor Boundary

Identity plane continuity Federated · 3/4

Yes for orchestration, execution, application distribution, and integration layers within the Red Hat product family. An enterprise developer Keycloak-federated identity controls what they deploy in OpenShift (FC-2A), what executes in their namespace (FC-2B), what they can access from OperatorHub and the Developer Console (FC-3), and — with Red Hat Integration — what API calls carry their identity to backend services (FC-4). The identity plane spans these layers without the enterprise building point-to-point identity bridges. Substrate identity control — ensuring a compliance-tagged physical node automatically restricts application runtime execution — requires operator-configured node affinity rules using included OpenShift primitives, an Opinion gap requiring no new capability acquisition. Data governance identity and agent identity require additional IBM licensing.

In plane: FC-2A · FC-2B · FC-3 · FC-4

Siloed: FC-0 · FC-1 · FC-2C

Function scores 26 assessed functions

0 · Absent
1
1 · Weak
1
2 · Moderate
6
3 · Strong
18
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
4
Opinion
14
Vendor roadmap
1
Structural
6
Mixed
1

Layer findings Open a layer to read the evidence

FC-0 SubstrateModerate
FC-1 ContextModerate
FC-2A OrchestrationModerate
FC-2B RuntimeStrong
FC-2C ReasoningAbsent
FC-3 CatalogStrong
FC-4 IntegrationModerate
Complete assessment · v1.5 ·

Nutanix Cloud Platform

Fourth Cloud Control Plane Assessment — Nutanix Vendor Boundary

Identity plane continuity Partial federation · 2/4

Yes for VM infrastructure layers. An operator's Prism-federated enterprise identity controls what they can deploy (FC-2A), what VMs execute in their project with what network security policies (FC-2B), what marketplace items they can request (FC-3), and what NUS file/object data they can access (FC-1 NUS) — without building separate identity bridges. No for Kubernetes workload identity: NKP workloads require separately configured Kubernetes RBAC. No for integration fabric identity: no Nutanix integration fabric exists. No for data governance identity beyond NUS: external databases, mainframe data, and SaaS systems require additional tooling.

In plane: FC-2A · FC-2B virtual machines · FC-3 · FC-1 Nutanix Unified Storage

Siloed: FC-0 substrate · FC-2B Kubernetes · FC-2C · FC-4

Function scores 26 assessed functions

0 · Absent
4
1 · Weak
2
2 · Moderate
8
3 · Strong
12
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
9
Opinion
5
Vendor roadmap
3
Structural
7
Mixed
2

Layer findings Open a layer to read the evidence

FC-0 SubstrateModerate
FC-1 ContextGap
FC-2A OrchestrationModerate
FC-2B RuntimeStrong
FC-2C ReasoningAbsent
FC-3 CatalogModerate
FC-4 IntegrationAbsent
Complete assessment · v1.4 ·

Oxide Computer

Fourth Cloud Control Plane Assessment — Rack-Scale IaaS

Identity plane continuity Partial federation · 2/4

Partially yes, within the VM infrastructure scope. A project identity in Oxide controls who can provision VMs, what storage those VMs can access, and what network topology they join — three-layer identity consistency from one source without enterprise-built bridges. What it does not provide: identity propagation into guest OS or application runtimes inside VMs, data governance identity across enterprise data stores, application distribution identity governance, or integration boundary identity enforcement. The partial plane covers Oxide-managed infrastructure; everything above the VM boundary is the enterprise's identity responsibility.

In plane: FC-0 · FC-2A · FC-2B

Siloed: FC-1 · FC-2C · FC-3 · FC-4

Function scores 26 assessed functions

0 · Absent
13
1 · Weak
6
2 · Moderate
5
3 · Strong
2
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
0
Opinion
0
Vendor roadmap
0
Structural
26
Mixed
0

Layer findings Open a layer to read the evidence

FC-0 SubstrateGap
FC-1 ContextAbsent
FC-2A OrchestrationGap
FC-2B RuntimeGap
FC-2C ReasoningAbsent
FC-3 CatalogGap
FC-4 IntegrationAbsent
Complete assessment · v1.0 ·

Canonical OpenStack

Fourth Cloud Control Plane Assessment — Self-Managed at the Ubuntu Pro Boundary

Identity plane continuity Partial federation · 2/4

Within the OpenStack estate: yes — FC-0-adjacent substrate identity (Ironic) natively controls FC-2B execution (Nova) with no bridge and no cost. Across the full Canonical stack: no — the buyer operates four identity systems (Keystone, MAAS, Juju, Canonical Identity Platform), and the seams between them belong to the enterprise. Two seams close with configuration of shipped primitives; the MAAS and Juju seams are built, at Section 2.6 gap lifecycle cost per bridge.

In plane: FC-2A · FC-2B · FC-3

Siloed: FC-0 · FC-1 · FC-2C · FC-4

Function scores 26 assessed functions

0 · Absent
4
1 · Weak
6
2 · Moderate
15
3 · Strong
1
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
11
Opinion
3
Vendor roadmap
0
Structural
10
Mixed
2

Layer findings Open a layer to read the evidence

FC-0 SubstrateGap
FC-1 ContextGap
FC-2A OrchestrationModerate
FC-2B RuntimeModerate
FC-2C ReasoningAbsent
FC-3 CatalogGap
FC-4 IntegrationGap
Complete assessment · v1.1 ·

Bounded Kubernetes (k3s on NVIDIA DGX Spark)

Fourth Cloud Control Plane Assessment - Kubernetes, bounded by a workload

Identity plane continuity Partial federation · 2/4

Can FC-0 identity control FC-2B runtime execution? Partially. The workload authenticates against the self-hosted Keycloak plane, but identity is not yet enforced across orchestration, catalog, and integration. The enterprise owns extending it, and the cost is configuration of additional clients and single sign-on across services it already runs, not a new acquisition.

In plane: FC-2B

Siloed: FC-0 · FC-1 · FC-2A · FC-2C · FC-3 · FC-4

Function scores 26 assessed functions

0 · Absent
1
1 · Weak
14
2 · Moderate
6
3 · Strong
5
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
19
Opinion
1
Vendor roadmap
0
Structural
5
Mixed
1

Layer findings Open a layer to read the evidence

FC-0 SubstrateGap
FC-1 ContextGap
FC-2A OrchestrationModerate
FC-2B RuntimeModerate
FC-2C ReasoningAbsent
FC-3 CatalogGap
FC-4 IntegrationGap
Complete assessment · v1.2 ·

HPE Private Cloud

Fourth Cloud Control Plane Assessment — HPE Morpheus + VM Essentials on HPE Private Cloud

Identity plane continuity Partial federation · 2/4

No, not natively. FC-0 substrate identity cannot control what application runtimes execute at FC-2B without operator-configured policy bridges. The GreenLake spine federates administrator and operator sign-on across the operational layers, but workload-identity enforcement from substrate to runtime, and reconciling Morpheus's own role model with per-runtime identity, is the enterprise's configuration and bridge burden. The federation is real and reduces the number of identity islands; it does not yet make one identity context enforceable at every layer.

In plane: FC-2A · FC-2B · FC-3

Siloed: FC-0 · FC-1 · FC-2C · FC-4

Function scores 26 assessed functions

0 · Absent
3
1 · Weak
4
2 · Moderate
7
3 · Strong
12
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
6
Opinion
6
Vendor roadmap
2
Structural
10
Mixed
2

Layer findings Open a layer to read the evidence

FC-0 SubstrateModerate
FC-1 ContextModerate
FC-2A OrchestrationModerate
FC-2B RuntimeStrong
FC-2C ReasoningAbsent
FC-3 CatalogModerate
FC-4 IntegrationAbsent
Complete assessment · v1.1 ·

SUSE Rancher Prime

Fourth Cloud Control Plane Assessment — SUSE Vendor Boundary

Identity plane continuity Federated · 3/4

Can FC-0 identity control FC-2B runtime execution? Not natively — substrate identity influences what runs where only through operator-configured node labels, affinity rules, and admission policies, built from included primitives. What the enterprise does get: one federated identity governs what a person can orchestrate (FC-2A), what executes in their namespaces across both VMs and containers (FC-2B), and what they consume from the catalog (FC-3) — uniformly across on-premises, hosted-cloud, and edge clusters, including managed cloud Kubernetes the enterprise already runs — without building identity bridges between the layers the plane covers. The cost of the siloed layers: substrate-to-runtime enforcement is operator-maintained configuration, and data governance identity requires acquiring a data governance platform first.

In plane: FC-2A · FC-2B · FC-3

Siloed: FC-0 · FC-1 · FC-2C · FC-4

Function scores 26 assessed functions

0 · Absent
3
1 · Weak
2
2 · Moderate
9
3 · Strong
12
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
9
Opinion
10
Vendor roadmap
1
Structural
6
Mixed
0

Layer findings Open a layer to read the evidence

FC-0 SubstrateModerate
FC-1 ContextModerate
FC-2A OrchestrationModerate
FC-2B RuntimeStrong
FC-2C ReasoningAbsent
FC-3 CatalogModerate
FC-4 IntegrationGap
Complete assessment · v2.3 ·

Dell Private Cloud

Fourth Cloud Control Plane Assessment — Dell Automation Platform on Dell Infrastructure

Identity plane continuity Siloed · 1/4

No — categorically, not just practically. A compliance tag on a Dell node cannot restrict what executes on that node, because Dell identity governs who may lifecycle the infrastructure while what runs on it answers to the deployed stack's identity plane. The enterprise federates the Dell portal to its identity provider, then builds and maintains every workload-identity control inside the stack vendor's plane — policy expressed twice, in two vendors' instruments, kept in sync by hand.

In plane: FC-0 · FC-2A

Siloed: FC-1 · FC-2B · FC-2C · FC-3 · FC-4

Function scores 26 assessed functions

0 · Absent
10
1 · Weak
10
2 · Moderate
5
3 · Strong
1
4 · Hyperscaler
0

Gap ownership 26 functions below 4

Closeable
12
Opinion
0
Vendor roadmap
0
Structural
14
Mixed
0

Layer findings Open a layer to read the evidence

FC-0 SubstrateGap
FC-1 ContextAbsent
FC-2A OrchestrationGap
FC-2B RuntimeGap
FC-2C ReasoningAbsent
FC-3 CatalogGap
FC-4 IntegrationAbsent
For two audiences
Compact layer comparison

Status is the average of function scores within each layer. Open the comparison page for the full identity plane and FC-2C reasoning detail.

LayerVMwareRed HatNutanixOxideCanonicalBounded K8sHPESUSEDell
FC-0 · Substrate Physical & Virtual SubstrateStrongModerateModerateGapGapGapModerateModerateGap
FC-1 · Context Distributed Data & Context FabricGapModerateGapAbsentGapGapModerateModerateAbsent
FC-2A · Orchestration Infrastructure OrchestrationModerateModerateModerateGapModerateModerateModerateModerateGap
FC-2B · Runtime Execution & RuntimeModerateStrongStrongGapModerateModerateStrongStrongGap
FC-2C · Reasoning The Reasoning PlaneAbsentAbsentAbsentAbsentAbsentAbsentAbsentAbsentAbsent
FC-3 · Catalog Application Distribution and GovernanceModerateStrongModerateGapGapGapModerateModerateGap
FC-4 · Integration Integration FabricGapModerateAbsentAbsentGapGapAbsentGapAbsent
Open full comparison →
Part of the Layer2C research system

Fourth Cloud is the readiness instrument in a four-part system. It scores on-prem control-plane readiness, not vendor authority, and its scores don't map one to one onto the 4+1 layers. System map →