A few years ago, "private cloud" felt like a term we had finally worn out. Most new projects were framed around public cloud, SaaS, or getting out of the datacenter. That has changed. Some workloads are simply easier to control, price, and recover on infrastructure the organization owns or dedicates to itself.
At Recovery Point, customers aren't asking us to rebuild the datacenter they had ten years ago. The conversation now starts with workload placement, operational ownership, and recovery when the preferred platform is unavailable. That's a much better use of the private-cloud label.
I remember the first private-cloud wave pretty well. We virtualized nearly everything, added orchestration, built service catalogs, and tried to make the datacenter feel like a hyperscaler. Sometimes it worked. Sometimes the self-service portal did little more than open a ticket for an administrator.
We can make the same mistake with newer platforms.
I still use the NIST definition because it keeps the word "cloud" from turning into marketing mush. NIST lists five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.[1] If a platform does none of that, the cloud label is doing more work than the architecture.
NIST also treats private cloud as a deployment model, not a location. It may exist on or off premises. The organization may operate it, a third party may operate it, or both may share the job.[1] Owning the servers isn't the definition.
We already tried this once
The first wave grew naturally out of server virtualization. VMware had already separated compute from the physical server. Templates, policy, automated provisioning, and network abstraction looked like the next logical step.
The trouble started after deployment.
A user could request a VM through a portal, but the infrastructure team still built the network by hand. Storage was selected one project at a time. Security rules came through another queue. Monitoring and backup depended on somebody remembering the last two steps.
The interface changed. The work didn't.
The lesson is operational. Self-service matters only when the platform can support the service through Day 2. Patching, policy, capacity, identity, monitoring, recovery, and retirement need a repeatable path. Otherwise the portal creates manual work faster.
If every request still needs a person to assemble the network, assign storage, apply security, wire up monitoring, and remember backup, you have virtualization with a request form. You don't have a private cloud.
Why private cloud is back in the room
Public cloud didn't fail. It solved real problems and still does.
It remains hard to beat for global reach, temporary capacity, mature managed services, and projects that should not wait for a hardware purchase. I wouldn't drag a good workload out of public cloud just to make an architectural point.
The workloads changed.
A proof of concept can call an AI service with an API key and a credit card. Production brings steady inference, internal datasets, GPU utilization, model access, power, cooling, storage throughput, and network placement into the design. The right answer may still be public cloud. Dedicated infrastructure becomes easier to justify when demand is steady enough.
The same is true for workloads with predictable utilization, strict data-location requirements, tight latency budgets, or recovery plans that depend on local control. Those conditions don't automatically mean "bring it home." They do mean the placement decision deserves real math instead of habit.
The platform isn't the definition
These aren't the same private-cloud model with different logos. Each gives the operator a different amount of the stack and expects a different skill set.
| Platform | What it brings | What I'd still prove |
|---|---|---|
| VMware Cloud Foundation 9.1[2] | An integrated VCF stack with a unified, API-first consumption interface. | Commercial fit, brownfield path, network design, operational ownership, recovery architecture, and whether the full VCF model fits the organization. |
| Nutanix NCI 7.6 + NCM 2.1[3][4] | NCI handles core virtualization. NCM adds self-service, observability, approval policies, and cost governance through its Build, Operate, and Govern model. | Hardware and storage design, catalog scope, external integrations, automation ownership, DR, and which NCM capabilities the customer will actually operate. |
| Azure Local 2608[5][6] | Customer-owned infrastructure managed through Azure Arc and Azure tooling. Microsoft also offers disconnected operations for qualifying environments, using a local control plane.[7] | Validated hardware, connectivity model, identity, Azure dependencies, lifecycle, support boundaries, cost, and DR. |
| OpenShift Virtualization 4.22[8] | A Kubernetes application platform that also creates, deploys, migrates, and manages virtual machines. | Platform-team maturity, storage classes, network integration, migration design, application support, backup, and the impact of making Kubernetes the infrastructure control plane. |
| Proxmox VE 9.2[9][10] | A KVM and LXC virtualization platform with clustering, storage integration, dynamic load balancing, expanded SDN, and paid production support. | Who supplies self-service, policy, identity integration, service catalog, cost visibility, automation, backup, and DR around the platform. |
This isn't a scorecard. It shows where the operating model comes from and what remains the customer's responsibility.
The real trade-off is how much of the operating model you want already assembled. VCF and Nutanix package more of it. Azure Local carries Azure management onto customer-owned infrastructure. OpenShift makes Kubernetes the control plane. Proxmox gives you the virtualization foundation and leaves more of the service model to your team.
Any of them can be part of a private cloud. Installing one doesn't make it a cloud.
The hypervisor is usually the easy part
I care about the boring questions because operators have to live with the answers after the demo is over.
- The path an application team uses to request a service
- Where policy is applied and audited
- Who owns capacity and placement
- How administrative identities are separated
- Who patches and upgrades the platform
- Whether the team can see ownership and cost
- How the control plane is recovered
If the answers require five consoles, three spreadsheets, two people with tribal knowledge, and a ticket queue, I don't care how good the hypervisor benchmark is. The operating model isn't ready.
A private cloud has to survive Day 2. It also has to survive the day the person who built it isn't available.
AI makes the math harder to ignore
AI may begin as an API experiment. Production pushes the discussion into GPUs, power, cooling, data location, storage throughput, and network design.
That doesn't mean every company should buy a rack of accelerators. Plenty should not.
Public services can be the better answer for experiments, bursty demand, or teams that don't want to operate AI infrastructure. Owned or dedicated capacity becomes more interesting when inference is steady, utilization is predictable, or sensitive data needs tighter control.
Dedicated accelerators make financial sense only when the utilization is there. Idle GPUs are expensive. A private AI platform still needs scheduling, isolation, observability, model lifecycle, access control, and enough automation to keep every project from becoming a custom build.
If the platform can't share expensive resources safely, meter their use, and recover the service, the accelerators didn't solve the architecture problem. They made it more expensive.
Recovery belongs in the platform
A lot of private-cloud designs get lazy here.
Teams spend months on automation, networking, policy, and the service catalog. Recovery arrives near the end as a backup job. That falls apart when the control plane itself becomes a dependency for every service running on it.
At Recovery Point, we start with the failure case because a real incident takes away the normal path. Identity may be damaged. The management plane may be unavailable. Primary storage may not be trusted. The preferred hypervisor may not be usable. The design needs another way through.
A private-cloud recovery plan should cover more than workload data:
- Management and control-plane configuration
- Identity, DNS, certificates, and time dependencies
- Virtual networking and firewall state
- Storage configuration and metadata
- Backup infrastructure and credentials
- Automation, templates, images, and infrastructure code
- Application dependency order
- An alternate place to run critical services if the preferred platform is unavailable
We've dealt with the portability side directly. During an internal migration, we used Veeam v13 VMware backups from two corporate vCenter environments to restore the workloads cross-platform to Hyper-V. Veeam's current documentation lists VMware vSphere backups as a supported source for Instant Recovery to Microsoft Hyper-V.[11]
The VMs came back. The job wasn't finished.
VMware Tools wouldn't uninstall cleanly through Windows Add or Remove Programs after the move in our environment, so we scripted the cleanup. That was a small step, but it's exactly the kind of detail a portability slide leaves out.
A support matrix can show that a workload can move. I call it portable only after we've moved it, handled the guest and network differences, and proved the application on the other side.
If the control plane delivers the service, the control plane has to come back too.
Don't repatriate out of spite
I understand the reaction. A large hyperscaler invoice can make a rack of owned hardware look beautiful.
A high bill is evidence that placement needs review. It isn't proof that the organization should own the replacement platform.
Bringing workloads back means taking responsibility for capacity, lifecycle, security, support, refresh planning, spare headroom, and the people who run it. If those capabilities are weak, repatriation can trade one expensive problem for another.
With public cloud, the monthly invoice is visible. Owned infrastructure splits the bill across hardware, facilities, power, support contracts, network upgrades, refresh cycles, reserve capacity, and staff time. The cost is still there. It's just spread across more ledgers.
I'd rather see a company keep the right workload in public cloud than bring it home to prove a point.
What I need to see before I call it a private cloud
I don't need every platform to look like AWS in a rack. I still need the word "cloud" to mean something operationally.
Authorized users can request an approved service without waiting for an administrator to build every component by hand.
Provisioning, changes, retirement, and common Day 2 work follow documented workflows.
Compute, storage, networking, and accelerators are assigned from defined pools with quotas and placement rules.
Identity, security, and compliance controls are applied by the platform instead of relying on memory.
The team can see health, capacity, utilization, ownership, and enough cost data to make placement decisions.
Consumers know what they can request, what support they receive, and what recovery expectation applies.
Patching, upgrades, drift, images, and templates are managed as platform responsibilities.
The control plane and representative workloads have been recovered under conditions that resemble a real failure.
If most of this still depends on tickets and tribal knowledge, you may have good virtualization infrastructure. You don't have a mature private cloud yet.
Public cloud still has plenty of jobs
I'm not interested in declaring a winner.
Public cloud remains a strong fit for variable demand, global services, managed data platforms, quick experiments, temporary projects, and workloads where buying for peak capacity would be ridiculous.
Private infrastructure becomes more attractive when utilization is predictable, data location matters, latency matters, or the organization can run the platform well enough to make ownership worthwhile.
Most enterprises will use both. The workload should drive the placement decision.
What came back
Private cloud is back in the conversation because teams are doing the workload-placement math again. Public cloud still works. It just isn't the automatic answer for every workload.
Products vary in how much of the operating model they include. A building-block approach gives the team more control, but it also leaves more work to assemble. Either way, the missing pieces need named owners.
I don't care what logo is on the rack. The team has to deliver services repeatedly, enforce policy, manage lifecycle, and show where the money goes. It also has to recover the platform. Until it can do those things, it isn't a private cloud.
Key Takeaways
- Private cloud is an operating model, not a synonym for servers the organization owns.
- The NIST characteristics still hold up. Self-service, pooled resources, elasticity, network access, and measured use matter more than the logo.
- VCF, Nutanix, Azure Local, OpenShift, and Proxmox aren't interchangeable. Each hands the operating team a different amount of the stack.
- A strong virtualization platform is a foundation. Day 2 operations, policy, ownership, cost visibility, and recovery still have to work.
- AI makes utilization, power, data location, and platform economics harder to ignore.
- Public cloud remains the right answer for plenty of workloads. Architecture doesn't need one winner.
- Recovery belongs in the platform design. A control plane that delivers the service also needs a tested path back.
Sources
- NIST SP 800-145, The NIST Definition of Cloud Computing. Essential cloud characteristics, service models, and deployment models.
- Programmable Infrastructure with VMware Cloud Foundation 9.1. VCF 9.1 general availability and unified API-first consumption model.
- Nutanix Cloud Infrastructure 7.6. Topology-aware scheduling and predefined AI workload VM profiles.
- Introducing Nutanix Cloud Manager 2.1. General availability plus the Build, Operate, and Govern model.
- What is Azure Local?. Customer-owned infrastructure, Azure Arc control plane, local workloads, and connected or disconnected deployment models.
- What's new in Azure Local 2608. Current August 2026 hyperconverged release.
- Disconnected operations for Azure Local. Local control-plane deployment for qualifying environments that cannot connect to Azure public cloud.
- Red Hat OpenShift Virtualization 4.22. Current VM creation, deployment, management, migration, architecture, and scaling documentation.
- Proxmox Virtual Environment 9.2. Current release, dynamic load balancing, expanded SDN, KVM, and LXC platform scope.
- Proxmox VE production support subscriptions. Production support plans, enterprise repository access, and service levels.
- Veeam Instant Recovery to Microsoft Hyper-V. VMware vSphere backups are listed as a supported source for recovery to Hyper-V.
Sources were rechecked August 30, 2026. Product versions, licensing, support matrices, and feature availability should still be confirmed against the vendor documentation for the environment being designed.