Michael Schmidt 
There is a question that never gets asked out loud in a VMware® migration, and it is the one the whole project depends on.
Not “what replaces vMotion.” Not “what replaces the datastore.” Those are the questions that fill the migration spreadsheet, and they have answers. The unasked one sits underneath all of them: what are you building instead? Not which product you are buying, which is a procurement question, but what the finished thing is supposed to do that the old thing did.
Most infrastructure teams already have a word for it, and they use it in the budget request without defining it. They are building a private cloud. That phrase is doing an enormous amount of work in those documents, and almost none of it is written down.
Which matters, because “private cloud” is not a product category. It is a set of properties, and a platform can satisfy every one of them or none of them while looking identical on an architecture diagram. Worse, the properties are not evenly distributed across the stack. When you list what people actually miss after leaving vSphere, most of the list turns out to sit in the storage layer, which is the layer the migration plan treats as a checkbox.
Six properties, and which ones are storage properties
Strip the marketing off the term and a private cloud is six commitments to the people who consume it. Here they are, with an honest accounting of where each one is actually satisfied.
Elastic capacity. A cloud grows by adding capacity, not by re-planning. This is the property that fails first, and it fails quietly. If storage lives on the compute nodes, capacity growth is welded to compute growth: you need 40 TB more, so you buy servers, so you now have CPU you did not ask for and are paying to cool. The scale-up versus scale-out question is not academic here, it is the difference between a capacity plan and a hardware-purchase plan.
Self-service provisioning. A consumer requests storage and gets it, without a ticket and without an administrator carving something up. On vSphere, an admin sized a datastore and teams drew from it. In the destination, the equivalent is a StorageClass with real parameters, and whether that is genuinely self-service depends entirely on whether the driver behind it can honour a request without a human in the path.
Tenant isolation with teeth. Partitioning capacity between tenants is not isolation. Two tenants can hold entirely separate volumes and still ruin each other’s afternoon, because the thing they are actually sharing is IOPS and latency. Real isolation needs per-volume quality of service, which is a storage-layer property and cannot be retrofitted by the platform above it.
Snapshots and clones as an API. In a cloud, a point-in-time copy is a call. In vCenter it was a workflow someone clicked through. The gap between those two is most of what makes a platform feel cloud-like to a developer, and it is decided by whether the storage layer exposes CSI snapshot and clone primitives that actually work at scale.
Predictable unit economics. A private cloud that cannot publish an internal rate is not a cloud, it is a shared server room with a nicer portal. A storage licence that moves independently of the platform makes a tenant’s cost a function of tiers and renewal terms nobody planned, which is unbillable. Platform-aligned pricing makes it a fixed rate per platform unit, which is a number you can put on an invoice.
A capacity planning horizon. Someone has to be able to answer “when do we buy more” with a date rather than a shrug. That is only possible when capacity and compute can be forecast separately.
Table 1: Which private cloud properties your platform choice settles, and which the storage layer still decides.
| Cloud property | What vSphere and vSAN provided | What a rebuilt platform gives you by default | What the storage layer still has to supply |
|---|---|---|---|
| Elastic capacity | Datastore grown by adding disk groups, within cluster limits | Capacity tied to node count when volumes are node-local | Capacity that scales independently of compute |
| Self-service provisioning | Admin-carved datastore, teams drew from it | A StorageClass, whose usefulness depends on the driver | Provisioning that completes without an admin in the path |
| Tenant isolation | Resource pools and separate datastores | Namespaces and separate StorageClasses, capacity only | Per-volume QoS so noisy neighbours are contained |
| Snapshot and clone as API | vCenter workflow, hypervisor-coupled | CSI snapshot and clone, quality varies sharply by driver | Primitives that hold up at production volume counts |
| Unit economics | Bundle licensing, cost follows renewal terms | Depends entirely on the licensing model you inherit | Platform-aligned pricing you can publish as a rate |
Read that last column as the actual scope of the storage decision. Four of the six properties are only partly settled by which VMware replacement you pick, and the part that is left over is the part that decides whether the finished thing behaves like a cloud.
Private cloud, public cloud, hybrid: what actually differs
The three terms get used as though they describe three places to put servers. They describe three different answers to the question of who absorbs which risk.
Table 2: The three models, compared on the properties that change.
| Private cloud | Public cloud | Hybrid | |
|---|---|---|---|
| Capacity elasticity | Bounded by hardware you own; expansion has a lead time | Effectively unbounded, billed per hour | Bounded on premises, elastic in the burst target |
| Cost shape | Capital plus licensing, mostly fixed | Operating expense, variable with use | Both, and the boundary is where surprises live |
| Data location | Decided by you, in a facility you name | Decided by region selection and provider policy | Decided twice, which is the part teams underestimate |
| Storage performance | Deterministic; you chose the media and the fabric | A published tier, with a noisy-neighbour tail | Two different performance profiles for one application |
The row worth pausing on is the last one. A hybrid design that works on paper often fails because the same application meets two storage profiles with different latency characteristics, and nothing in the platform reconciles them. If a hybrid model is genuinely part of the plan, a hybrid cloud storage architecture has to decide up front which workloads are allowed to cross the boundary, and the answer is usually fewer than the architecture diagram implies.
The data-location row is where a private cloud earns its keep for regulated buyers, and it is a genuinely separate argument from cost. The data residency decisions your storage layer makes covers that ground and this post will not re-argue it.
Building a private cloud and not sure which properties your storage layer owes you? If your VMware replacement is chosen but the storage design underneath it is still an open question, that is the right moment to talk rather than after the first tenant is on it. Talk to a storage architect
On-premises does not mean private cloud
This is the single most expensive confusion in the category, and it is worth being blunt about it.
An on-premises private cloud is not defined by the building. It is defined by whether the six properties above hold. Plenty of estates that call themselves private clouds are virtualization estates with a self-service portal bolted to the front, and the difference shows up the first time a tenant asks for something the underlying storage cannot deliver on request. Capacity takes a purchase order. A performance guarantee takes a conversation. A snapshot takes a ticket. None of those are cloud behaviours, and no portal hides them for long.
The reverse confusion is just as common and more damaging on a VMware exit specifically. A team replaces the hypervisor, keeps every storage assumption it inherited, and is surprised that the new platform does not feel more cloud-like than the old one. It should not be surprising. The properties that were missing were never hypervisor properties.
Two structural points follow, and both cut against how these projects are usually sequenced.
The first is that the platform choice and the storage choice are separable, and should be made separately. Whether the VMs land on Red Hat® OpenShift® Virtualization, on KubeVirt, on a different commercial hypervisor, on Proxmox, or on bare-metal Kubernetes with no hypervisor at all, the six properties are the same six properties. Inheriting the storage layer from whichever platform vendor wins the bake-off means inheriting their answer to four questions you have not evaluated. Notably, this is now an argument platform vendors are making themselves: the composable pricing tiers appearing across VMware-replacement platforms, where the entry tier is explicitly compute-only and expects you to bring your own storage, concede the point in public.
The second is that hyperconverged and separated are deployment models, not opposing camps. A private cloud can be built either way, and the honest answer is that the right shape depends on the estate. Co-locating storage on the workload nodes, the classic hyperconverged model, keeps the node count down and the topology simple, which suits smaller and more uniform estates. Separating the storage tier and reaching it over a fabric decouples the two growth curves, which is what makes the elastic-capacity and planning-horizon properties achievable at scale. Simplyblock supports both from one control plane, and treating the choice as a deployment decision rather than a product decision is what stops it from becoming a re-platforming exercise later.
What simplyblock supplies, and what it does not
Here is the part where a post like this usually claims the whole list. It should not, so let us be exact.
Simplyblock is a storage layer. It supplies the four properties in the right-hand column of Table 1, and it supplies them the same way regardless of which platform sits above it.
Volumes live in a pool served over an NVMe fabric, either NVMe/TCP on the network you already own or NVMe/RoCE where the fabric justifies it. Because a volume is not a directory on a particular machine, capacity and compute stop being one purchase: you add capacity when you need capacity, and the planning horizon becomes a forecast rather than a guess. Provisioning is a PersistentVolumeClaim that completes without an administrator, which is what makes self-service real rather than nominal. Per-volume QoS gives tenant isolation the enforcement that namespace boundaries alone do not provide, which is the argument multi-tenant storage isolation develops in full. Snapshots and clones are CSI primitives that hold their behaviour at production volume counts. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price.
That last point deserves a caveat in the same breath, because comparison tables in this category are routinely dishonest about it. Simplyblock is a paid product. It is not free and there is no version of this argument in which it costs nothing. The claim is narrower and more useful: the bill tracks provisioned capacity rather than the shape of your compute, so the cost of the private cloud is forecastable and attributable, which per-core licensing makes structurally difficult.
Now the limits, stated plainly, because the six properties are not all storage properties and a post that implies otherwise is not worth reading.
Simplyblock is not a private cloud. It does not provide the control plane, the tenant portal, the service catalogue, the identity and access layer, the quota system, the showback or billing engine, or the API your consumers will actually call. Those are platform functions and they stay platform functions. Of the six properties, simplyblock addresses elastic capacity, tenant isolation at the performance layer, snapshot and clone as an API, and the storage half of unit economics and capacity planning. It supplies the storage half of self-service provisioning and none of the interface half. Governance, chargeback policy, and the tenant experience are somebody else’s product, and if those are missing, the storage layer will not rescue the project.
Nor does it fix a platform you cannot operate. If the destination’s upgrade path is beyond the team, or the support model does not match the risk tolerance, storage is not the binding constraint and this is not the post you need. The VMware alternatives comparison is a better starting point in that case, and for teams whose private cloud is a commercial service rather than an internal one, the service-provider version of this exit covers a genuinely different set of constraints. Teams already committed to a Proxmox-plus-Kubernetes estate will find the platform-specific version of this argument in private cloud storage for Proxmox and Kubernetes, and teams facing a forced platform upgrade as the trigger should read what a Cloud Foundation upgrade changes about storage design first.
The useful conclusion is smaller than the usual one and more actionable. Write the six properties down before the platform bake-off, not after. Mark which ones each candidate satisfies on its own. The ones left unmarked are your storage requirements, and they will be roughly the same list whichever candidate wins.
Questions and Answers
What is private cloud architecture, and what does it require from storage?
Private cloud architecture is a commitment to six properties rather than a product you install: elastic capacity, self-service provisioning, enforced tenant isolation, snapshot and clone as an API, publishable unit economics, and a real capacity planning horizon. Four of those six are decided in the storage layer, which is why simplyblock’s recommendation is to specify them before choosing the platform. A pooled block layer served over an NVMe fabric supplies all four the same way regardless of which hypervisor or Kubernetes distribution sits above it, which keeps the platform decision reversible.
Is an on-premises virtualization estate the same thing as a private cloud?
No, and conflating them is the most expensive mistake in this category. The building is not the definition. If a tenant cannot get capacity without a purchase order, cannot get a performance guarantee without a conversation, and cannot take a snapshot without a ticket, it is a virtualization estate with a portal attached. The properties that make it a cloud are mostly storage properties, and a self-service front end does not create them.
How is private cloud storage priced, and why does the model matter for chargeback?
Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. That matters for a private cloud specifically because chargeback has to be attributable: a platform-aligned storage line can be published as a rate per platform unit, and there are no capacity tiers to reconcile against tenant usage. Simplyblock is a paid product, not a free tier; the advantage is forecastability and attribution, not absence of cost.
Should a private cloud be hyperconverged or use a separate storage tier?
Both are valid and simplyblock supports either from one control plane, so treat it as a deployment decision rather than a product decision. Hyperconverged, with storage co-located on the workload nodes, keeps node count and topology simple and suits smaller, more uniform estates. A separated tier reached over the fabric decouples capacity growth from compute growth, which is what makes elastic capacity and a real planning horizon achievable at larger scale. The important thing is that changing your mind later should not be a re-platforming project.
Does simplyblock replace a private cloud platform like Cloud Foundation?
No. Simplyblock is the storage layer, not the private cloud. It does not provide the control plane, the tenant portal, the service catalogue, identity and access management, quotas, or the billing engine, and those functions are not optional in a real private cloud. What it does is supply the storage properties consistently, so the platform above it can be chosen, and later changed, on its own merits.
What is the difference between private cloud and hybrid cloud for storage design?
The difference that matters is that hybrid means the same application meets two storage profiles with different latency characteristics, and nothing in the platform reconciles them automatically. A private cloud gives deterministic performance because you chose the media and the fabric. A hybrid design has to decide explicitly which workloads may cross the boundary, and that list is almost always shorter than the architecture diagram suggests. Data location is decided twice in a hybrid model, which is the part regulated buyers tend to underestimate.
Which private cloud properties does the platform choice settle on its own?
Realistically two: the interface half of self-service provisioning, and the governance and identity model. Everything else in the list, elastic capacity, performance isolation between tenants, snapshot and clone behaviour at scale, and the cost shape you can publish, depends on the storage layer underneath and will not be settled by winning a platform bake-off. That is the practical reason to write the six properties down before the bake-off rather than after it.
