451 Research: Cloud Price Index – Private Edition, Part 3: the best value TCO for private cloud?

InsightaaS: Back in December, InsightaaS reported on a new 451 Research initiative designed to determine baseline costs for different cloud delivery models. At the time, InsightaaS's Mary Allen noted that "trend analysis in the Index service over time should better reflect changes in a highly dynamic market and the drift to or away from commoditization for different service categories – information that may help educate cloud service buyers looking for value, and providers looking to refine services offerings."

In just over four months, these words have been proven true - and 451's analysis has become the focus of a new level of debate around cloud pricing. This month, 451 analysts Owen Rogers,  William Fellows, and Al Sadowski published an exceptional three-part review comparing the costs of private cloud based on proprietary technology, commercial OpenStack distributions, and DIY OpenStack services - and added perspectives on public cloud and managed hosted private cloud.

This is groundbreaking research: it provides a comparative view of TCO that has not previously been available in the market, and one which, as the December research pointed out, will continue to evolve over time. This piece is already the subject of intense discussion in the OpenStack community, and it seems clear that the discussion will continue there and in other quarters.

To be fair, there is no overarching 'silver bullet' formula that will yield a perfect answer to the question "what's the best approach to cloud?" As the authors point out in their conclusion, "Proprietary offerings, OpenStack distributions and managed services all have their strengths and weaknesses – what matters are features, enterprise readiness, and having people in place that understand how to keep a deployment operational...Buyers will need to balance all of these aspects with a long-term strategic view of where the business is going – as well as TCO – to determine the best course of action." As the passage notes, the need for perspective is important – but so too is the need for this perspective to be informed by clear and consistent cost information. InsightaaS expects that over time, the 451 Cloud Price Index will become a standard component of internal and external discussions for both buy-side firms and their suppliers.   


In this report, we have used data from 451 Research's Cloud Price Index - Private Edition, plus manpower costs, to examine the TCO of small-scale on-premises and hosted managed private cloud deployments built on OpenStack and proprietary commercial offerings. Each of these options can be cost-beneficial in some circumstances. In our results, Microsoft, VMware and Red Hat have a lower TCO than OpenStack. For buyers choosing OpenStack, however, supported distributions show a clear TCO benefit over the DIY approach. Meanwhile, hosted managed private cloud services offer a better TCO when the ratio of VMs to administrators in a self-managed deployment falls below 100.

The Cloud Price Index - Private Edition comprises a range of benchmark indicators that together show the average price of a small-scale private cloud across a range of options, including OpenStack distributions, managed services and in-house deployments. By considering the total costs of our 'basket' of hosting services, infrastructure, software and operating systems from a range of providers delivered using a range of mechanisms, we can find the average market price per hour, per virtual machine, of our basket. By measuring the change in the cost of our basket over time, we can evaluate how the industry is changing, and what this means for service providers and consumers.

This introduction details the need for an index, plus the methodology followed. The second report in our series shows the latest values of the CPI price indicators for our standard virtual machine size of 500GB local storage, 96GB RAM, 2 x Intel E2670v2 10 Core CPU:

  • Our Commercial (Proprietary) Hypervisor and Orchestration indicator stands at $0.10 per VM-hour and includes a quotation volunteered by VMware for its vCloud Suite Advanced, plus estimates for Red Hat Enterprise Virtualization & Cloud Forms, and Microsoft System Center plus Windows Server 2012.
  • Our OpenStack Distribution indicator stands at $0.08 and includes quotations volunteered by SUSE, Canonical and HP Helion, plus estimates for Red Hat, IBM and Piston Cloud.
  • The OpenStack DIY indicator, based on our self-architected private cloud using Dell hardware, stands at $0.06.
  • The Managed Private Cloud indicator comes in at $0.26, but pricing variance is large between providers – Accenture, Adapt, Blue Box, Canonical, CenturyLink, Dimension Data, Internap, LogicWorks, Metacloud, Mirantis and Verizon provided quotes for this indicator.
  • Using data from the Cloud Price Index - Public Edition, we've also been able to derive an equivalent price for public cloud of $0.17 - AWS, Colt, Google, Microsoft, Swisscom, Verizon and WindStream all voluntarily submitted quotes, and estimates for Rackspace and CenturyLink (using public pricing) were included.

Total cost of ownership

TCO is a subjective and somewhat controversial topic. Look at the TCO entries on any vendor blog and you'll see that companies arrive at completely different outcomes and have widely dissimilar opinions with regard to very similar scenarios and circumstances. The primary issue affecting TCO is manpower cost. Licenses and hardware at least require some prescription. With manpower, how much time is needed to dedicate to what task cannot always be easily determined.

So instead of making assumptions about manpower on behalf of the buyer, we use Cloud Price Index data to analyze at what ratio different options become better value. Our approach can be used to determine, for example, that if "you use x% less manpower because of this option, it may be cheaper." In this way, buyers can use our approach to dial up different options and determine the effect on TCO. This measure should scale to any use case – the x% value should be the same regardless of the number of virtual machines and engineers, as long as the unit cost for VMs is approximately similar to our findings.

Our approach comes with a Safe Harbor – we have used industry-standard salary data extracted from salary comparison website Indeed.com. From this source, OpenStack engineers cost $126K, and VMWare, Red Hat and Microsoft engineers cost $91K, all based in California – these figures are used in our TCO calculations (see our math at the end of this report for more information). Of course, this assumption will vary depending on the supply of qualified individuals at the location where they are desired, when they are desired. Furthermore, these findings will change depending on the precise scale, architecture and characteristics of the private cloud. Buyers should perform their own assessments of value for an accurate view of their particular circumstances, and shouldn't rely on these figures to be true for all scenarios.

With the managed cloud and public cloud options in the table below, our approach has been to show what 'golden ratio' of virtual machines to engineers will provide a better TCO than an alternative option. In other words "If you are successfully operating a private cloud based on a ratio of X virtual machines per engineer, then you are probably getting a better TCO than outsourcing management." By using this ratio approach, we have been able to define thresholds for the TCO implications of manpower, without making an assumption on how much manpower expense is required to support each particular option. Furthermore, these ratios should scale – if the private cloud is expanded linearly such that our unit costs remain the same, the criteria stated should still hold. However, this, of course, depends on specific circumstances.

The main overarching disclaimer for this work is that quotations, estimates and assumptions are based purely on the specific 'basket' of products and services for our specific requirement. The same price, patterns and ratios will not be the same in all other circumstances. However, by setting benchmark indicators, we have a methodology for viewing and tracking the market over time.


Table 1 below shows the criterion for which the TCO of Option B is less than that of Option A for all of our five indicators. In other words, it defines the thresholds at which Option B becomes cheaper than Option A. We can think of these ratios as a scale, weighing two different options. In the situation where each option requires the same number of engineers, then one option will have a higher TCO. The question is how many more engineers will make the balance tip so that the other option becomes more expensive? This 'tipping point' represents the relative change in TCO. You can add up to this tipping point, and option A will remain more expensive. Add any more, and it will tip to make option B more expensive. So the question for the end user to ask is: "Will I need to add or reduce engineers to support this new technology, and how will it affect TCO?"

As an example, when does an OpenStack 'DIY' implementation (Option B) become cheaper than an OpenStack Distribution implementation (Option A)? The intersection of these options on the table shows that DIY will only have a lower TCO if an increase in manpower of less than 46% is required to support it, relative to a distribution. So if you have four engineers operating an OpenStack Distribution, you can move to OpenStack DIY and reduce TCO on the condition that you only need to take on one more full-time employee (an increase of 25%) to support the new implementation. If you need to take on two further full-time employees (an increase of 50%, thereby crossing the 46% threshold), then you'd get better TCO using the distribution in our scenario. However, it's worth noting that a minimum number of engineers will be required to support a DIY OpenStack implementation, and these numbers are not easy to find or justify financially. The colors represent the findings shown in bullet points below. The math behind this approach is discussed at the end of this report.

Key findings

The TCO of proprietary commercial cloud management offerings is less than that of the OpenStack distributions in our scenario. The so-called 'tax' for using commercial proprietary code such as that from Microsoft, VMware and Red Hat does not present itself when investigated here. In fact, commercial code offers a 'proprietary dividend.' A buyer could hire up to 3% additional staff to support the proprietary offering, and it would still be cheaper than the TCO of using OpenStack distributions. Data supporting this finding is shown in red in the table.

For a proprietary offering to be a better value than OpenStack DIY in our scenario, the proprietary offering needs to deliver a 60% manpower savings. Considering the complexity of installing, configuring and managing OpenStack, this seems achievable. The proprietary offering's TCO benefit is simply the result of the high cost of OpenStack engineers – the distributions themselves are priced lower than the proprietary offerings. However, commercial code does potentially present more financial risk. These vendors may raise their prices or discontinue services, plus there will be a substantial economic cost to migration.

However, contracts, planning and budgeting for 'just-in-case' migration can reduce the risk of being painted into a corner. With OpenStack, migration should, on paper, be less expensive, but it will be made more difficult than necessary due to a lack of federation among providers and the numerous OpenStack reference architectures. Data supporting this finding is also shown in red in the table. In the scale diagram below, in a like-for-like manpower scenario, OpenStack is more expensive simply because of the high cost of engineers in this field. The scale only tips if you have to hire 3% more engineers for the proprietary cloud, which is unlikely in practice.

In our scenario, OpenStack distributions are likely to offer a TCO saving compared with using the DIY approach if a manpower reduction of 45% is achieved as a result of using the distribution. Considering the simpler implementation, indemnity and support received as a result of using a distribution, we think this is probable, and distributions thereby present good value. Data supporting this finding is shown in green in the table. In the scale diagram below, in a like-for-like manpower scenario, distributions are more expensive because of their cost compared with free DIY. The scale will tip if you have to hire 45% more engineers for the OpenStack DIY cloud. Considering the complexity of OpenStack, it seems likely that an engineering increase of more than 45% will be required for a DIY implementation, hence distributions present a better TCO.

The value of managed and public clouds depend on how many virtual machines a buyer's own engineers are successfully able to support on a private cloud – the 'golden ratio.' If the private cloud specified in our scenario is being successfully operated at a ratio of one engineer to about 100 virtual machines, it might be deriving better TCO than a managed private cloud. Any less, and the managed cloud is likely to be cheaper to run. However, due to the huge variation in quotes received for managed private cloud (the costliest was 7x the price of the cheapest), this ratio will vary significantly depending on the exact price quoted by each provider; some providers' quotations were cheaper than the cost of an equivalent private cloud service. This is a relatively small threshold point – for pre-production private clouds with low management requirements and/or homogenous workloads, self-managed could be the better option. For production, heterogeneous, mission-critical applications, managed private clouds can give virtual machines the attention they deserve. As more virtual machines are created on the private cloud and new services are added, existing engineers might struggle to manage the sprawl.

The golden ratios at which self-managed private cloud becomes better value than managed cloud for commercial, OpenStack Distribution and OpenStack DIY clouds are 91, 118 and 106 per engineer, respectively. Data supporting this finding is shown in orange in the above table. In the scale diagram below, managed cloud is costlier than self-managed when we exclude manpower. The scale will tip if each engineer is able to successfully support more than ~100 virtual machines on the self-managed cloud.

The low price of public cloud makes this golden ratio even larger. For our self-managed private cloud to be cheaper than public cloud, a golden ratio of at least 250 VMs per engineer is required. Any less, and public cloud is likely to be a better value. As with managed cloud, such a large ratio is achievable particularly when the private cloud is supporting low management requirements and/or homogenous workloads.

The golden ratios at which self-managed cloud becomes better value than managed cloud for proprietary, Distribution and DIY clouds are 253, 297 and 234 per engineer, respectively. Data supporting this finding is shown in yellow in the above table. In the scale diagram below, managed cloud is costlier than self-managed when we exclude manpower. The scale will tip if each engineer is able to successfully support more than ~250 virtual machines on the self-managed cloud.

In terms of TCO, proprietary offerings – at the moment – seem to provide the best value for our requirements. However, since they are commercial technologies, this may not always be the case. Price increases, product decommissioning and other factors may increase TCO, with no simple, inexpensive way out for consumers. This is less of a problem with OpenStack, where the promise of interoperability and portability that the industry touts should allow consumers to move between providers and offerings, which will lead to lower market costs.

Commercial offerings are largely more mature, have more features, and have been widely tested in the market. OpenStack is a disruptive force supported by a wide range of blue-chip vendors, with purportedly less lock-in, but still not without its risks (e.g. fragmentation). As more skilled OpenStack engineers enter the labor market, the TCO benefits of the proprietary software packages will be reduced as salaries are reduced as well. Enterprise buyers evaluating and negotiating with vendors will want to bear this in mind.

At the moment, finding an OpenStack engineer is a tough (and expensive) task. One solution is to use a managed service, which removes the need to find skilled workers to support the cloud. This will often be a cheaper TCO option than a self-managed deployment. The exact TCO savings here will depend on how successfully the user can manage its own private cloud. With super-efficient engineers managing 1,000 virtual machines each, then the managed option makes little sense. Yet if your engineers are struggling to support a few scores of mission-critical applications, then a managed service may be the way to go. But there is still risk here. Managed services require trusting a third party to look after a critical part of the enterprise, and there is a lock-in implication.

Public cloud may be cheaper than self-managed offerings in situations where the golden ratio is high, but the sacrifice is control – managed private cloud providers give consumers back some control while removing the management burden. As a result, they charge consumers more for the luxury of single-tenancy. Often this is a price worth paying for the benefits of security and control.

There is no easy answer regarding which option provides a better TCO. Proprietary offerings, OpenStack distributions and managed services all have their strengths and weaknesses – what matters are features, enterprise readiness, and having people in place that understand how to keep a deployment operational. This manpower is crucial. Buyers will need to balance all of these aspects with a long-term strategic view of where the business is going – as well as TCO – to determine the best course of action.

The math

For completeness, the math behind our calculations is shown below: