The Infrastructure Control Plane Is Consolidating

On Monday, Cisco unveiled Cloud Control at Cisco Live. One login. Networking, security, compute, observability, and collaboration unified into a single operational surface with a shared data layer and a shared automation model. Cisco called it the foundation for their AgenticOps operating model.

The interesting question is not whether Cloud Control succeeds. The interesting question is why every major infrastructure vendor is trying to build the same thing at the same time.

Cisco is not alone. AWS has Control Tower and the expanding IAM Authority model. Google just repositioned its entire enterprise portfolio around an agentic control layer at Google Cloud Next. Azure Arc is Microsoft’s explicit play to own the hybrid governance surface. Broadcom controls the virtualization policy layer for a significant portion of enterprise compute. Red Hat has been quietly consolidating the Kubernetes management and policy surface for years. Datadog and ServiceNow — companies that started in observability and workflow respectively — are both exhibiting the same expansion behavior.

The infrastructure control plane is becoming the most competed layer in enterprise technology. Understanding why requires a precise definition of what that layer actually is — and a framework for recognizing the progression that leads every major vendor to converge on it.

The Infrastructure Control Plane Is Becoming the Most Valuable Layer

The infrastructure control plane is not a product. It is a layer — specifically, the layer that determines how every other infrastructure layer is operated.

It owns six functions that no other layer owns:

Identity — who and what is allowed to act on infrastructure, including non-human agents and automated systems. Policy — what is permitted to run, where, under what conditions, and with what constraints. Observability — the authoritative view of system state that all operational decisions reference. Automation — the execution surface through which changes are applied, reconciled, and enforced. Governance — the audit record, the compliance model, and the change authority chain. Change execution — the final gate through which infrastructure modifications actually occur.

These six functions are not features. They are the substrate through which every workload decision, every cost decision, and every security decision flows. The shadow control plane problem exists precisely because when no explicit control plane is defined, operational authority migrates to wherever these six functions happen to be implemented — the console, the pipeline, the monitoring tool, the ticketing system.

The doctrine that emerges from this: the control plane is where infrastructure authority accumulates. Every other layer — compute, storage, networking, AI workloads — operates under the authority model the control plane defines. Change the workload and nothing structural changes. Change the control plane and everything downstream changes with it.

The Control Plane Used to Be Fragmented

For most of enterprise infrastructure history, the control plane layer did not exist as a unified concept. Authority was distributed across a collection of domain-specific tools, each owning a slice of the six functions without any of them owning the whole:

This fragmentation was not a failure of architecture. It reflected the reality that infrastructure was also fragmented — physical hardware, discrete network domains, on-premises compute managed by separate teams with separate toolchains. No single vendor had the surface area to own more than one or two of those functions credibly.

The fragmentation had a structural consequence: no single vendor held authority over the whole. Enterprises retained the operational seams between tools. Governance lived in process, not in platform.

That structural arrangement is now unwinding. The surface area required to own the entire control plane has become achievable — and the economic incentive to do so has become undeniable.

Framework #115 — Control Plane Capture

Control Plane Capture is not a deliberate strategy on the vendor’s part in Stage 1 or Stage 2. At Domain Entry, the vendor is solving a specific problem. At Surface Expansion, they are adding adjacent value. The strategic intent emerges in Stage 3, when governance integration begins creating the conditions for Stage 4.

The CI/CD pipeline as control plane is a well-documented instance of this pattern at the platform layer — a deployment tool that began at Domain Entry (code delivery) and expanded through automation into governance integration. The pattern is not new. What is new is the number of vendors running it simultaneously, from different origin points, converging on the same destination.

Everyone Is Running the Same Playbook

The convergence becomes undeniable when mapped across vendor categories. Every major infrastructure vendor class is executing a version of Control Plane Capture. The origin points differ. The destination is identical.

The moment Datadog and ServiceNow appear in the same convergence map as Cisco and AWS, the argument shifts. This is not vendors adding features. This is every infrastructure category simultaneously reaching for authority.

Why Vendors Want the Control Plane More Than the Workload

The workload is transient. The control plane is permanent.

A vendor that owns your workload earns consumption revenue for as long as you run that workload. When you migrate the workload, the revenue relationship ends. The vendor’s leverage is proportional to migration friction — which is real, but bounded. You can move a workload.

A vendor that owns your control plane earns something different: architectural permanence. The policy model, the identity model, the automation surface, the observability layer — these do not move when workloads move. They govern the movement. Every migration, every new platform deployment, every agentic workflow that executes in your environment flows through the control plane that vendor now owns.

Workloads move. Control planes remain.

The switching cost for a control plane is not measured in migration effort. It is measured in the depth to which the vendor’s authority model has penetrated the organization’s operational muscle memory, toolchain integrations, identity hierarchies, and automation dependencies. By the time Stage 4 (Authority Consolidation) completes, the enterprise cannot cleanly answer the question “what would it take to replace this?” — because the answer involves rebuilding governance, not replacing a workload.

This is why every vendor wants the control plane more than the workload. The workload earns revenue. The control plane earns permanence. For a vendor competing for long-term enterprise relevance, there is no comparison between the two.

The private cloud governance dynamic illustrates the same principle from the enterprise side — organizations returning to on-premises infrastructure not because cloud failed, but because they discovered they never controlled the governance model that sat above their workloads.

The Most Dangerous State Is Partial Consolidation

Most enterprises today are not operating with a single consolidated infrastructure control plane. They are operating with five — or more — partial ones, each owning a slice of the six control plane functions, with no intentional architecture governing the seams between them.

A representative example:

• AWS owns cloud governance — IAM policy model, Control Tower account structure, Organizations hierarchy
• Cisco owns network governance — routing policy, security enforcement, observability across the network fabric
• Datadog owns observability authority — the system-of-record for what is happening in production
• ServiceNow owns workflow and change authority — the gate through which operational changes are approved
• Microsoft owns identity — Active Directory, Entra ID, the identity model that underpins every access decision

Each of these vendors is at Stage 3 or Stage 4 of Control Plane Capture within their domain. None of them owns the complete control plane. All of them behave as though they do.

The result: nobody owns the authority model. Everyone owns a piece of it. When an automated agent executes a change — provisioning a resource, modifying a policy, triggering a failover — the authority chain that governs that action passes through multiple independent control plane fragments with different policy engines, different identity assumptions, different audit models, and different automation paths.

This is a more interesting architectural problem than vendor lock-in. Vendor lock-in is a single-vendor risk. Partial consolidation is a multi-vendor coordination failure with no clean owner and no obvious resolution path. The sovereignty failure pattern that emerges when enterprises attempt late-stage cloud exit is a direct consequence — the control plane was never designed, so there is no coherent authority model to migrate away from.

The diagnostic is not rhetorical. An enterprise that can answer it — that can name the authority boundaries, the policy ownership model, the identity hierarchy, and the automation governance surface in architecture terms rather than vendor terms — has made an intentional decision about control plane design. Most have not. Most have inherited a partial consolidation from the accumulated weight of procurement decisions made without a control plane architecture in view.

That gap is the real exposure. Not which vendor wins. Not which platform has the best features. Whether the enterprise has an architecture that governs the authority layer — or whether multiple vendors are quietly completing their own Stage 4 in parallel, with the enterprise unaware that the race is already underway.

The network layer is the most recent domain to enter this race, as AI workload placement decisions have pushed network architecture back into the governance conversation.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →