The Dollars and Cents of How to Consume a Private Cloud

Amar Kapadia - December 19, 2016 - ,

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 nodes
Storage:

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 nodes
Storage:

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.

banner-img
From Virtualization to Containerization
Learn how to move from monolithic to microservices in this free eBook
Download Now
How is Cloud Native Changing the Landscape of Edge and 5G? [Recording]

Late last year, Mirantis hosted a Cloud Native and Coffee panel featuring CTO Adam Parco, Global Field CTO Shaun O’Meara, Director of Technical Marketing Nick Chase, and special guest Darragh Grealish, CTO of 56K Cloud. Below are highlights of the discussion that touch on what edge is and how developers can bring cloud native innovation to edge computing and 5G. Watch …

How is Cloud Native Changing the Landscape of Edge and 5G? [Recording]
Moving to Cloud Native: How to Move Apps from Monolithic to Microservices

Enterprises face the challenge of consistently deploying and managing applications in production, at scale. Fortunately, there are more technologies and tools available today than ever before. However, transitioning from a traditional, monolithic architecture to a cloud native one comes with its own unique challenges. Below, you will find a list of the critical first steps you need to take when …

Moving to Cloud Native: How to Move Apps from Monolithic to Microservices
Mirantis Newsletter - January 2022

Every month, Mirantis sends out a newsletter chronicling top industry and company news. Below you’ll find links to blogs, tutorials, videos, and the latest updates to our enterprise, open source, and training offerings. If you don’t currently receive the newsletter, you can subscribe by clicking the button on the top right. Mirantis Brings Secure Registries to Any Kubernetes Distro Launched earlier this …

Mirantis Newsletter - January 2022
Technical training
Learn Kubernetes & OpenStack from Deployment Experts
Prep for certification!
View schedule
WHITEPAPER
The Definitive Guide to Container Platforms
READ IT NOW
LIVE WEBINAR
Getting started with Kubernetes part 2: Creating K8s objects with YAML

Thursday, December 30, 2021 at 10:00 AM PST
SAVE SEAT