Most cloud operators ship one product. They sell a public cloud, with a single self-serve console, or they sell a private cloud, with bespoke deployments bearing little resemblance to each other. ZCP runs both from the same stack. The same compute, the same orchestration, the same operations. The layer on top separates the two products.
The shared foundation
Both products are built from three layers, and every layer is the same software on both sides.
Physical. Bare-metal servers running 10 GbE networking with IX peering and BGP. NVMe / SSD / HDD storage tiered for performance, capacity, and archive. The operational disciplines, observability, security, power, cooling, are the same disciplines we apply to a customer’s private cloud and to our public regions.
Orchestration. Apache CloudStack as the IaaS control plane, Ceph (RBD for block, RGW for S3-compatible object) for storage, Kubernetes as the PaaS control plane, and a set of platform services on top, VMs, block, object, load balancers, VPC networking, IAM, DNS. None of these are proprietary, none of them carry per-core licence terms, and none of them install agents inside customer workloads.
Service delivery. What the orchestration produces: MaaS (bare metal), IaaS (VMs and storage), PaaS (Kubernetes clusters and managed databases). These are the things a customer consumes.
For a Private Cloud Build-Out, this is where the product stops. The customer (or their MSP) owns the consumption, through the CloudStack API, the CLI, Terraform, or our white-label portal configured for their tenants. The stack is theirs.
The CMP delta
To turn the same stack into a public cloud, we add a single layer on top: the Cloud Management Platform. The CMP is what makes ZCP self-serve, hourly-billed, and globally accessible without a sales call. Three things live in this layer:
- Portal and self-service. The customer-facing UI, sign-up flow, account management, and documentation. The portal is a thin layer over the CloudStack and PaaS APIs.
- Billing and identity. CAD invoicing tied to usage metering, RBAC across multi-tenant accounts, audit logs across every administrative action. None of these are needed in a single-tenant private cloud, where the customer’s identity provider and finance system already own those functions.
- Marketplace and API. A public catalog of OS images and one-click apps, a public REST API, and the SDK. The marketplace is what enables the “I want to launch a VM and a managed Postgres in five minutes” experience.
This is the entire difference. The physical stack underneath does not change. The orchestration does not change. The services delivered do not change. The CMP wraps them into something a self-serve customer buys hourly.
Why this architecture matters
Three implications, all of them deliberate.
A graduation path. A customer who starts on the ZCP public cloud and grows past it moves to a Private Cloud Build-Out without re-platforming. The CloudStack API, the Ceph buckets, the Kubernetes manifests, they all work identically on a dedicated stack we deploy for them. The CMP layer is the only thing they shed when they go private. The workloads themselves do not move.
A white-label path for partners. MSPs and channel partners resell either side. The Private Cloud Build-Out gives them a managed environment to operate. The public-cloud delivery layer includes white-label marketplace functionality for partners who want to put their own brand on a multi-tenant offering. The same engineering foundation supports both.
A clean factoring. The CMP is the layer most cloud operators conflate with the cloud itself. We separate it explicitly because the orchestration layer underneath has a different lifecycle and different audiences. The orchestration is shared across hundreds of customers and operated by ZSoftly engineers. The CMP is a product surface built for marketing and self-serve needs. Treating them as one piece creates the “you must take all of our managed services or none of them” problem. Treating them as two layers lets us ship private clouds without the public-cloud baggage, and public clouds without rebuilding the foundation.
The design rule, in one line
No per-core licence. No forced upgrade tiers. No proprietary agents in your workloads. This principle made the same stack viable for both delivery modes. Anything violating it (a proprietary hypervisor, a closed-source orchestrator, an opinionated agent) would have prevented the private cloud from becoming a real product, and would have made the public cloud hostile to customers who wanted to migrate workloads in or out.
Sources and further reading
- Apache CloudStack: About CloudStack and the API reference.
- Ceph: Ceph documentation for RBD, RGW, and CephFS.
- NIST SP 800-145, The NIST Definition of Cloud Computing, the definition of the four deployment models and three service models we use in this post.
- For the migration story from VMware onto this stack, see our step-by-step migration guide.