The Dollars and Cents of How to Consume a Private Cloud

In my blog, how does the world consume private clouds?, we reviewed different ways to consume private cloud software:

1. Do-it-yourself (DIY)
2. Software distribution from a vendor
3. Managed service (your hardware & datacenter, software managed by a vendor)
4. Managed & hosted service (hardware, software, datacenter all outsourced)

Let’s look at the economics of the first three alternatives. Rather than an absolute total-cost-of-ownership (TCO) analysis, we will focus on a relative comparison where line items that are identical in all three scenarios, e.g., hardware costs, will be removed.
Of course, cost is not the only criteria in choosing your consumption model; there are other criteria, such as the ability to recruit OpenStack talent, long-term strategic interests, customizations required, and so on, but these topics are not covered in this blog.

DIY

This initially appears to be a no-brainer option. After all, isn’t open-source free software? Doesn’t one just download, install and be on their merry way? Unfortunately not -- open-source software provides numerous benefits such as higher innovation velocity, ability to influence direction and functionality, elimination of vendor lock-in and short-circuiting standards by defining APIs, drivers and plugins. But “free” is not a benefit mainly because open-source projects are not finished products. Below are typical costs incurred in a DIY scenario based on the numerous customers we have had the opportunity to work with who initially tried DIY OpenStack.

Cost	Representative Breakdown
Fixed size engineering team of 13 engineers(Size independent of cloud scale)	5 Upstream engineers (to fix bugs, work on features, create reference architecture) 5 QA engineers (to package, QA & do interop testing) 3 Lifecycle tooling & monitoring engineers
Fixed size IT/OPS team of 9 engineers(Size independent of cloud scale)	1 IT architect (to architect, do capacity planning) 1 L3 engineer (troubleshooting) 2 L2 engineers (to deploy, update, upgrade, and do ongoing management) 5 L1 engineers (to monitor, look at basic issues, respond to tenant requests)
Variable size engineering team of 1.1 person per 100 nodes and 1.1 person per 1PB storage(Size depends on cloud scale, kicks-in only when past fixed size minimums - so no double counting)	Compute: 0.3 IT/OPS architects per 100 nodes 0.1 L3 IT/OPS engineer per 100 nodes 0.3 L2 IT/OPS engineer per 100 nodes 0.4 L1 IT/OPS engineer per 100 nodesStorage: 0.3 IT/OPS architects per 1PB storage 0.1 L3 IT/OPS engineer per 1PB storage 0.3 L2 IT/OPS engineer per 1 PB storage 0.4 L1 IT/OPS engineer per 1 PB storage
Dev/ Test cloud	$50,000 depreciated across 3 years required to test updates, upgrades, configuration changes etc.
Loss of availability	A DIY cloud typically has a lower availability than alternatives. Once you calculate the number of minutes of cloud downtime per year, you can multiply this by the margin loss per minute.E.g. for 98% cloud availability and $50 loss per minute of cloud downtime equates to a loss of $525,600 per year.
Production delays	A DIY cloud typically takes longer to implement, delaying a production deployment. E.g. for 6 months of delay and each month causing the business $50,000 of loss, that equates to $300,000 of one-time loss.

 

Software Distribution from a Vendor

In this consumption model, the engineering burden is shifted to the vendor, but the IT/OPS task resides with the user. The costs look like follows:

Cost	Representative Breakdown
Fixed size IT/ OPS team of 3.5 engineers(Size independent of cloud scale, the team is much smaller than in the DIY case because there is a vendor to take support calls)	0.5 IT architect (to architect, do capacity planning) 1 L2 engineers (to deploy, update, upgrade, ongoing management) 2 L1 engineers (to monitor, look at basic issues, respond to tenant requests)
Variable size engineering team of 1 person per 100 nodes and 1 person per 1PB storage(Size varies depending on cloud scale, kicks-in only when past fixed size minimums - so no double counting)	Compute: 0.3 IT/OPS architects per 100 nodes 0.3 L2 IT/OPS engineer per 100 nodes 0.4 L1 IT/OPS engineer per 100 nodesStorage: 0.3 IT/OPS architects per 1PB storage 0.3 L2 IT/OPS engineer per 1 PB storage 0.4 L1 IT/OPS engineer per 1 PB storage
Dev/Test cloud	$50,000 depreciated across 3 years required to test updates, upgrades, configuration changes etc.
Loss of availability	A cloud based on a distro typically has better availability than DIY. Once you calculate the number of minutes of cloud downtime per year, you can multiply this by the margin loss per minute.E.g. for 99.5% cloud availability and $50 loss per minute of cloud downtime equates to a loss of $262,800 per year.
Software support costs	In lieu of the internal engineering team, in this scenario, there is a support cost payable to the vendor.

 

Managed Service from a Vendor

Here the engineering and IT/OPS burden for the software is shifted to the vendor. The costs look like follows:

Cost	Representative Breakdown
Loss of availability	A managed cloud typically offers the highest availability of the three options. Once you calculate the number of minutes of cloud downtime per year, you can multiply this by the margin loss per minute.E.g. for 99.9% cloud availability and $50 loss per minute of cloud downtime equates to a loss of $52,560 per year.
Managed services costs	In lieu of the internal engineering & IT/OPS team, in this scenario, there is a managed service fee payable to the vendor.

 

The Bottom Line

Here are results of 3 scenarios we ran:

	Relative Costs (4 year timeline)
Initial number of VMs	3,000	20,000	60,000
DIY cost/VM	$1,448	$249	$118
Distro cost/VM	$614	$179	$124
Managed cloud cost/VM	$298	$189	$149

The net-net is that for small clouds, managed is a very attractive option. For mid-size clouds a distribution may be more cost effective. For the largest clouds, DIY might be the least expensive option assuming the IT team can keep the availability reasonably high 98.5% or higher.