10.4 Open-source cloud platforms

What this is and why it exists

Everything so far has assumed a public provider. Some organisations do not have one — because of sovereignty rules, because of regulation, because they already own the hardware, or because they are the provider. This lesson is what runs a cloud when nobody is renting it to you: the platforms, who actually operates them, why the sentence "we will build our own cloud" costs more than it appears to, and one project's history that is a lesson by itself.

The vocabulary

• Private cloud — cloud-style self-service and metering, on hardware your organisation controls.
• Cloud platform software — the software that turns racks of machines into that self-service system.
• OpenStack — the largest such project, described by its own foundation as "a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed and provisioned through APIs with common authentication mechanisms".
• OpenNebula — a smaller, simpler platform aimed at virtualisation-led private clouds and edge deployments.
• Apache CloudStack — a platform designed around being operated by service providers, with multi-tenancy assumed.
• Compatible API — an interface that deliberately mimics another provider's, so existing tools work against it.
• Sovereignty — a requirement that data or systems remain under a particular jurisdiction's control.
• Total cost of ownership — the whole cost including people, power, space, replacement and time, not the hardware invoice.

The mental model

Start with what these platforms actually do, because it demystifies them. A public provider's console is a self-service layer over pooled hardware: you ask for a machine, something decides where it runs, a network is attached, storage is provisioned, an identity system decides whether you were allowed, and a meter records it. Private cloud platforms implement that same layer over hardware you own — compute scheduling, virtual networking, block and object storage, identity, images, and a dashboard. Understanding them as the components you have already met, assembled by you rather than by a provider, is most of the understanding.

OpenStack is the large, capable, modular one. It is composed of separate projects for each of those functions, which is its strength — you deploy the parts you need — and also its reputation: a full deployment is a substantial system, and the organisations running it well have a team whose job that is. The service names live in its own documentation rather than in this lesson, because they are worth reading from the source and there are more of them than a first pass needs. OpenNebula is deliberately smaller and simpler, chosen where the goal is orderly virtualisation and edge sites rather than a full provider-scale platform. Apache CloudStack assumes a provider operating it for tenants, so its multi-tenancy and account model are strong out of the box, which is why hosting companies pick it.

Eucalyptus is the fourth name your syllabus mentions, and its history is the lesson. It was built to offer an AWS-compatible interface, so that tools written for that provider would work against your own hardware — an attractive idea, seriously executed. HP acquired it in 2014 and folded it into a public offering that was shut down in early 2016; DXC then stopped development and support by the end of 2017; and members of the founding team continued the codebase under AppScale Systems. Take two things from that. First, the compatible-API strategy is a hard place to stand: you are permanently reimplementing somebody else's moving interface, and being merely compatible is never a reason to choose you. Second, and more practically, the platform under a private cloud is itself a dependency with a lifecycle — it can be acquired, discontinued or handed on, and you should ask who maintains it and who pays them before you build on it.

Then the honest case for private cloud, which does exist. Data that must remain in a particular jurisdiction or on particular premises by law or by contract. Hardware you already own and have already paid for. Workloads so steady, heavy and long-lived that rented capacity is genuinely more expensive. Being a provider yourself. Those are real, and in India the sovereignty and residency cases are increasingly ordinary rather than exotic.

And the honest warning, which is that the cost people compare is the wrong cost. "We will build our own cloud" is usually costed as hardware against a rental bill, and the hardware is the small part. The real bill includes the people who run the platform around the clock, the data centre space and its power and cooling, the network, the spare capacity you must buy for peaks you cannot rent your way through, the replacement cycle, the upgrades of the platform itself, and the security work. Add those and the comparison often reverses — and the version that does not reverse is the one where the organisation was going to be paying for a data centre anyway. Do the arithmetic honestly, including the people, and the decision usually makes itself.

What you should now be able to explain or do

Describe what a private cloud platform does, in terms of the components you already know. Say what distinguishes OpenStack, OpenNebula and CloudStack in a sentence each. Recount the Eucalyptus history and give the two lessons in it. Name four genuine reasons to run a private cloud. List the costs missing from a hardware-versus-rental comparison, and say which single one usually decides it.

Check yourself