Who this is forIT directors and infrastructure managers who have been offered a private cloud, or been asked by the business for “cloud-like” infrastructure, and need to separate what the term means from what a virtualised cluster with a new name already does.
“Private cloud” is applied to almost everything with a hypervisor in it. That makes the term useless for comparing proposals, and expensive when it hides the difference between a virtualised cluster and a platform that someone has to build and run. This guide gives you a definition you can test against, an honest account of what elasticity means on fixed hardware, and the decisions that actually distinguish the options.
A definition you can test
The most widely cited definition comes from the US National Institute of Standards and Technology, in its Special Publication 800-145. It describes five essential characteristics of cloud computing. A private cloud, in its terms, is that same service model provisioned for exclusive use by a single organisation, which may be owned and run by that organisation or by a third party, and may sit on its premises or off them. Exclusive use is what makes it private; the five characteristics are what make it a cloud.
Those characteristics turn into questions you can put to any proposal, including your own estate.
| Characteristic | The question to ask | What failing looks like |
|---|---|---|
| On-demand self-service | Can a team provision what it needs without raising a ticket and waiting for a person? | Requests still queue behind an administrator |
| Broad network access | Are services reachable through standard interfaces, from the clients that need them? | Access depends on bespoke tools or specific client software |
| Resource pooling | Is capacity drawn from a shared pool and assigned dynamically, rather than pinned to named hosts? | Workloads are tied to particular servers by hand |
| Rapid elasticity | Can capacity be added and released quickly, within the limits of the pool? | Growth means a hardware project |
| Measured service | Is usage metered, so consumption can be reported and, if you wish, charged back? | Nobody can say what a team consumes |
Run your own estate through the table. A well-run virtualised cluster usually passes the pooling question, partly passes the elasticity question, and fails self-service and metering. That gap, which is automation, a service catalogue, quotas and reporting, is the real content of “private cloud”. It is software and process, not hardware.
Where it runs, and who runs it
The same label covers three quite different arrangements, and a proposal should say which it is.
- On your premises or in your colocation space, run by you. Maximum control, maximum responsibility. You operate the platform and the hardware.
- Hosted, single-tenant, run by you. A supplier provides dedicated hardware in their facility, and your team operates the platform on it. You hold the platform skills; they hold the hardware and facility.
- Hosted and managed by the supplier. The supplier operates the platform as well, and you consume it. The line of responsibility moves up the stack, and with it your dependence on their processes and their change calendar.
Which one fits depends mostly on whether you have, and want to keep, platform engineering skills. The questions in managed infrastructure apply directly to the second and third.
Elasticity on a fixed pool
Public cloud advertises effectively unlimited elasticity because the pool belongs to someone with far more capacity than any one customer. A private cloud’s elasticity is bounded by the pool you provisioned, and the arithmetic is unforgiving.
Worked example. A pool of 6 hosts with 96 hardware threads each has 576 threads. Reserving one host for failure leaves 480 usable. If 400 are committed, headroom is 80 threads, which is 16.7% of the usable pool. A team that now asks for 120 more threads cannot be served by a click. The answer is a purchase and a delivery lead time, exactly as before, but now with a self-service portal on the front that makes the request look instant.
None of this is a flaw, and it is why capacity planning does not disappear. What changes is the shape: you plan the pool and its headroom centrally, forecast demand from metering data, and order hardware ahead of need. Where demand is steady and predictable, that is cheap and calm. Where it is spiky and unpredictable, a private pool sized for the peak sits idle in between, and the economics favour renting someone else’s capacity for the peaks.
Bursting to a public cloud
Hybrid designs that overflow into public cloud resolve the peak problem on paper. In practice they depend on data placement. Applications that need large amounts of data near them cannot burst cheaply, because moving the data takes time, as the arithmetic in server migration shows, and public cloud providers commonly charge for data leaving their networks. Check the provider’s current data transfer terms before assuming a burst is affordable. Bursting works best for stateless tiers that can be started from an image in minutes, and poorly for databases.
What you now have to run
A platform is a product with an owner. The work that was not there before includes the following.
- The control plane. The software that schedules and provisions has its own upgrades, its own database, its own failure modes. Ask what happens to running workloads when the control plane is down. In most designs they keep running but nothing can be changed. Test it, and write the procedure for restoring the control plane itself, including its configuration and database backups.
- Automation and images. Self-service is only as good as the templates behind it. Someone must build, patch and retire the images and the infrastructure-as-code modules teams will consume. Unpatched templates replicate vulnerabilities at self-service speed.
- Identity and quotas. Who may provision what, in how much quantity, and who approves exceptions. Without quotas, a self-service platform is a sprawl accelerator.
- Metering and reporting. Usage data underpins both chargeback or showback and capacity forecasting. If you cannot see consumption by team, you cannot plan the pool.
- Upgrades. Platform upgrades must be rehearsed and rolled across hosts without taking workloads down. A platform that cannot be upgraded safely becomes a liability within a couple of years.
Failure domains, redrawn
Virtualisation concentrated risk into hosts and shared storage. A private cloud adds a layer, and the design must name the new failure domains.
- The control plane as above.
- The network overlay, if the platform virtualises networking: an overlay fault can isolate every workload whose hosts are healthy.
- Shared services the platform needs at start-up, such as identity, name resolution and time. A platform that depends on a directory running inside itself has a bootstrap loop, so keep at least one of each outside it.
- The pool boundary. Put the pool across racks, power feeds and, if you can afford it, sites, and write down which failure it survives.
A useful discipline is to draw one diagram per failure, from a single host to the whole control plane, and mark which workloads survive. Gaps in the diagram are decisions you have not yet made.
Cost shape
A private cloud is a fixed cost with a variable benefit. You pay for hardware and for the people and tooling to run a platform whether the pool is busy or idle. It pays back through utilisation, through speed of delivery, and through consistency, none of which a price list captures. The honest comparison with plain virtualisation is therefore operating effort against delivery speed, and a proposal that gives only hardware prices has left out the larger half of the sum.
Signals that point each way
| Signal | Points towards |
|---|---|
| A small, stable set of workloads and a small team | Virtualised cluster, or dedicated servers |
| Many teams provisioning frequently, with a platform engineering function | Private cloud |
| Large, unpredictable peaks | Public cloud, or hybrid with stateless bursting |
| Strict locality or isolation requirements | Private cloud or dedicated, depending on the requirement |
| No platform skills and no appetite to hire them | Managed offering, with eyes open about dependence |
How this goes wrong
- A label, not a platform. A virtualised cluster was renamed. Nobody could provision anything without a ticket, and the extra cost bought nothing.
- Self-service nobody used. The catalogue was built without asking what teams needed, and teams carried on asking administrators.
- Elasticity assumed. The pool had no headroom, and the first large request exposed a three-month lead time.
- The platform became a single point of failure. A control-plane upgrade went wrong with no tested restore.
- No exit. Workloads depended on proprietary platform features, so moving off the platform meant rebuilding, not migrating.
What to do next
Score your own estate against the five questions above. Then compare the architecture classes in the architecture comparison matrix, and read virtualisation if the honest answer is that a well-run virtualised cluster would meet your requirements with less to operate.