OpenStack and private cloud: who gains leverage, and who just sinks in complexity

In 2012 interest in private clouds has grown noticeably. OpenStack makes it possible to build your own cloud infrastructure: manage virtual machines, networks, and storage through a single API, modelled on how public clouds work. That sounds attractive - especially for companies that want to control their data and not depend on an external provider.

But before moving in that direction, it is worth answering one question honestly: is the company ready to pay the real price for that independence? The price here is not in hardware. The prior question - whether your own infrastructure makes sense at all versus hosted or public cloud - is worth settling first. And it is worth being clear that virtualisation is not the same as a cloud - a distinction that matters before evaluating OpenStack.

What is actually being purchased

A private cloud is not a product you deploy and forget. It is an operating model. Along with it you are purchasing:

• a team that knows how to run and evolve it;
• processes for automation, monitoring, backup, and incident response;
• willingness to spend engineering time on infrastructure rather than on the product;
• responsibility for reliability that the provider used to carry.

OpenStack itself is a complex system with many components. Installing it is possible. Keeping it running, updating it without service degradation, and handling non-trivial failures - that requires people with specific skills and experience who are not easy to find.

Who this actually makes sense for

A private cloud justifies its complexity when several conditions hold at once:

• there is scale: several hundred servers, or consistent growth toward that number;
• there is competence: in-house or via a contractor, people who have already run OpenStack in production;
• there are specific requirements around data, networking, or isolation that public clouds cannot meet without significant cost;
• there are mature IT processes overall: change management, monitoring, SLA discipline, on-call rotations.

If even one of those conditions is missing, a private cloud will create more problems than it solves.

The typical trap

A company with 30 servers decides that a private cloud will give them flexibility. They deploy OpenStack. The first three months are energising. Then:

• failures that engineers are not equipped to diagnose quickly;
• updates that nobody wants to do because it is unclear what will break;
• developers complaining that the experience is worse than the public cloud they are used to;
• accumulating technical debt because there are not enough resources for proper automation.

The infrastructure works, but badly. And leaving it is also not straightforward - data and configurations are already there.

What to consider as an alternative

For companies that need control but whose scale does not yet justify the full OpenStack stack, there are intermediate options:

• virtualisation at a single data-centre level with good processes - VMware or KVM with proper orchestration;
• a hybrid model: sensitive data inside, elastic capacity from a provider;
• a managed OpenStack service from a specialised host, where the infrastructure expertise stays with the contractor.

Each of these options gives less full control, but also costs less to operate.

Three questions before the decision

Before starting a serious conversation about private cloud, I recommend answering three questions:

1. Who will be running this a year from now, and is that person already in the company?
2. What specific problem does the current approach not solve, that OpenStack will?
3. If it turns out a year from now that this was a mistake - how easy is it to get out?

If the first question has no clear answer, the conversation about platform choice has not started yet.