Horizontal scale and control planes are reshaping data infrastructure

At a glance

What this is: This is an analysis of how Commvault reworked its platform for horizontal scale, microservices, and centralized management, with the key finding that read-optimized services and a global control plane were needed to keep large environments usable.

Why it matters: It matters because identity, admin access, and operational governance must keep pace when platforms move from single-instance administration to distributed service models and shared control planes.

By the numbers:

• Some API calls were taking 30 seconds or more to respond.

👉 Read Commvault's analysis of horizontal scaling and the Global Command Center

Context

Modern data platforms fail when they assume scale is only a capacity problem. In practice, scale is also an access, governance, and operability problem, because the control plane, service boundaries, and administrative model all change as environments spread across regions and workloads.

Commvault’s article is about that shift: moving from vertically scaled, single-machine services to horizontally scalable, microservice-based components and a global command center. For IAM and platform teams, the relevant question is not just how systems store more data, but how they preserve trustworthy administration, monitoring, and service accountability as the architecture fragments.

In identity terms, the issue is that centralized oversight can no longer depend on a single server or a single administrative path. Distributed services, regional deployments, and shared management interfaces change how access is granted, how actions are audited, and how operational responsibility is segmented.

Key questions

Q: How should teams govern identity and access in horizontally scaled platforms?

A: Teams should treat horizontal scaling as a governance redesign, not a capacity upgrade. The first step is to identify which administration functions remain centralized, then decide where authentication, logging, and approval boundaries must be shared across services. That keeps distributed systems manageable without creating uncontrolled privilege concentration. The key is to preserve a consistent control plane as the platform expands.

Q: Why do microservices change the way IAM teams think about platform risk?

A: Microservices change risk because they distribute responsibility across more services, more interfaces, and more execution paths. IAM teams must then govern the shared identity and logging layers, not just the application entry points. If those shared services drift, each microservice can become a policy exception, and the platform becomes harder to audit, operate, and recover.

Q: What breaks when a control plane becomes the only way to manage the environment?

A: What breaks is resilience and governance at the same time. A single management surface may be efficient, but it also concentrates administrative privilege, makes outages more disruptive, and increases the impact of any control-plane compromise or misconfiguration. Teams should treat that concentration as a design risk, not just an operational convenience.

Q: How do security teams decide whether a central command center is helping or hurting governance?

A: Security teams should measure whether the central command center improves visibility without creating a single point of privilege or failure. If it is the only practical route for monitoring, job control, and response, then it may be simplifying operations while increasing governance dependency. The test is whether oversight remains available, timely, and attributable at scale.

Technical breakdown

Why vertically scaled platforms hit an identity and operations ceiling

Vertical scaling increases the resources of one machine, but it does not change the fundamental architecture. Once a platform depends on a single instance for core services, performance, resilience, and administration all become coupled to one failure domain. In Commvault’s case, services such as MediaAgents and the CommServe model reached limits that more memory and faster processors could only postpone. For identity teams, the same pattern appears when one administrative plane carries too much trust, too many duties, or too many workflows. That creates operational bottlenecks and concentrates privilege in ways that become harder to govern as the platform grows.

Practical implication: map single-instance administrative dependencies before they become privilege and resilience bottlenecks.

How read-optimised services reduce command plane contention

A read-optimised service separates query performance from write-heavy transactional workloads. Commvault describes an Entity Lookup Service that maintains a denormalized copy of relational data in a document store so frequent reads do not contend with ingestion, auditing, and job tracking. This is an architectural pattern, not just a performance trick. It lets the platform answer operational queries quickly without forcing every request through the same relational path. For identity and access governance, the lesson is that control-plane visibility must remain responsive at scale, otherwise administrators lose the ability to verify state, investigate activity, and act on it in time.

Practical implication: isolate high-volume read paths so administrative visibility does not degrade under platform load.

Why microservices need shared platform services to stay governable

Microservices improve modularity by splitting large functions into smaller services that can be deployed and scaled independently. That flexibility only works when common concerns such as authentication, logging, error handling, and lifecycle management are handled consistently. Commvault’s CVDotnetContainer is presented as the hosting layer that standardizes those concerns for multiple services on a single instance. The identity lesson is straightforward: distributed services do not reduce governance needs, they multiply the number of places where authentication, access, and operational telemetry must remain consistent. Without that shared layer, every service becomes its own policy exception.

Practical implication: standardise shared identity and logging services before expanding microservice sprawl.

NHI Mgmt Group analysis

Horizontal scale is now an identity governance problem, not just an infrastructure problem. Once platforms move beyond a single machine, the administrative model changes as much as the compute model. Access paths, oversight points, and service boundaries all multiply, which means governance has to address how trust is distributed across the platform, not just how workloads are hosted. Practitioners should treat scaling decisions as control-plane decisions.

Single-instance control planes create a hidden concentration of privilege. The more functions that depend on one administrative surface, the more that surface becomes a governance choke point. That pattern is familiar in IAM and PAM: shared control is efficient until it becomes the only way to manage the environment. The practical implication is that resilience and privilege design need to be evaluated together, because operational centralization can become a security single point of failure.

Read latency is an access-control issue when it blocks timely verification. The article’s under-3-second target for read-heavy responses shows that administrative usability is part of governance. If operators cannot quickly see state, confirm entitlement, or inspect activity, the platform can become governable in theory but not in practice. That means performance engineering and identity assurance are now linked disciplines for large distributed systems.

Named concept: control-plane sprawl. As enterprises add regions, services, and platform layers, the number of management surfaces expands faster than the governance model. Control-plane sprawl creates inconsistent administration, duplicated oversight, and fragmented accountability unless the organisation deliberately standardises service orchestration and identity enforcement. Practitioners should assume that every new management surface adds governance debt until proven otherwise.

Microservices only improve control when the shared service layer is treated as part of the identity model. Authentication, logging, request handling, and error management are not just engineering conveniences. They are the mechanisms that keep distributed services auditable and manageable. For IAM and platform teams, the implication is that platform architecture and identity architecture now need to be designed together from the start.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• That shift is already visible in the way teams rethink shared control planes and lifecycle governance, as described in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Control-plane sprawl is the operational side of identity sprawl. As environments spread across regions and services, the management surface expands faster than many governance models do. Teams that still rely on a single administrative path will find that visibility, attribution, and change control become harder to sustain, especially when platform ownership is fragmented.

The broader pattern is that platform architecture and identity architecture are converging. If the control plane is slow or overloaded, governance degrades with it, so performance targets like our research on NHI and secrets exposure show why operational responsiveness now belongs in identity discussions as much as access design does.

For practitioners, the next step is to evaluate whether shared services are being designed as part of the identity fabric or as afterthoughts. That distinction will determine whether the platform remains auditable as it scales or simply becomes harder to govern.

For practitioners

• Map single-instance governance dependencies Identify where one server, one console, or one admin workflow still carries multiple operational responsibilities. Use that map to spot where scaling will also amplify privilege concentration and failure impact.
• Separate read-heavy administrative queries Move high-volume visibility requests onto a read-optimised path so operational teams can inspect state without fighting transactional workloads. This helps preserve timely verification as environments grow.
• Standardise shared services across microservices Make authentication, logging, error handling, and request lifecycle management common services rather than per-team reinventions. That reduces policy drift and keeps governance consistent across independently deployed components.
• Review control-plane concentration risks Test whether your central management interface has become the only practical route for monitoring, configuration, and response. If it has, treat that interface as both an operational asset and a high-value governance target.

Key takeaways

• Horizontal scale changes governance requirements because the control plane becomes as important as the workload plane.
• Read-heavy administrative performance matters because slow visibility weakens timely verification and operational accountability.
• Shared identity, logging, and authentication services are the difference between modular architecture and policy drift.

Key terms

• Control plane: The control plane is the management layer that administrators use to configure, monitor, and operate a platform. In distributed environments it becomes a governance boundary, because access, visibility, and accountability all depend on how that layer is secured and segmented.
• Horizontal scaling: Horizontal scaling increases capacity by adding more machines or instances instead of making one machine larger. It changes governance because responsibility, telemetry, and access paths are no longer concentrated in a single system, which forces teams to standardise how distributed components are managed.
• Microservices: Microservices are small, independently deployable services that each handle a specific function. They improve modularity, but they also increase the number of components that need consistent authentication, logging, and lifecycle management, so identity governance must extend across the full service mesh.
• Read-optimised service: A read-optimised service is designed to answer queries quickly without competing with write-heavy transactional workloads. In large platforms, it helps keep administrative visibility responsive, which is essential when teams need to verify state, investigate activity, or maintain auditability at scale.

What's in the full article

Commvault's full article covers the architectural detail this post intentionally leaves for the source:

• The evolution from vertical to horizontal scaling across MediaAgents and core platform services.
• How the Entity Lookup Service uses a denormalized data model to improve command-center read performance.
• How the CVDotnetContainer standardizes authentication, logging, error handling, and service hosting.
• Why the Global Command Center changes administration across distributed CommCell environments.

👉 The full Commvault article covers the MediaAgent shift, Entity Lookup Service design, and multi-CommCell management model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.