I love open-source OpenStack. Here’s why you may not.Companies and organizations are rushing to adopt the popular open-source OpenStack platform, but few are prepared to handle the implementation. Decision-makers should stop and consider a few things.
It’s inescapable: Companies and organizations of all sorts are looking to adopt open-source OpenStack. In fact, according to a survey conducted by Linux.com at the 2014 CloudOpen in Chicago, OpenStack is now the most popular open-source cloud project, followed closely by Docker and KVM. The OpenStack Foundation now includes 800 corporations and organizations as members, and 2,000 code contributors.
Yet I’d argue that many of the organizations interested in adopting open-source OpenStack are not in the best position to do so, nor are they taking the right KPIs into perspective when evaluating it. I believe that adopting OpenStack has the potential to save money and increase computing power — I’m a huge fan, in fact — but a successful deployment really depends upon your company's provider relationships, and the depth of your company’s technical staff and their capabilities.
Maintenance, support and other TCO factors are criticalOne of the key metrics that often gets overlooked during the evaluation period is the amount of maintenance and dev support the open-source OpenStack platform requires to operate most efficiently. That varies greatly depending on the size of the environment, as analyst firm 451 Research attempts to articulate in a recent report. The figures in the lead paragraph suggest that running a private cloud powered by an OpenStack distribution will cost around $0.08 per virtual machine hour, but running your own turnkey private cloud will not cost much more: around $0.10. Both are far cheaper than the average figure of $1.70 per application hour for a public cloud (or $0.80 per application hour for committed use such as AWS Reserved Instances). These figures do not factor in the costs for employing OpenStack-proficient engineers, but the immediate return on investment of 20% is not to be dismissed.
The key decision-makers involved in the process often look primarily at the more immediate ROI (given an aversion to OpEx or CapEx) versus longer-term and more difficult-to-quantify TCO factors such as productivity, downtime or upgrade costs. Some example KPIs decision-makers should consider in a more holistic analysis include:
- Developer productivity. Every hour a developer doesn’t have to fill out an IS/IT request form for IaaS resources is another valuable hour he/she can spend delivering on the business initiative
- Coding. Depending on the type of deployment, another measure to consider is the frequency, speed, failure rate and quantity of applications generated by developers or re-coded in a month as compared to legacy environments
- Usability. Given that developers and other technical staff are the predominant end users of any IT platform, another key metric might be overall satisfaction of the platform — how usable is it?
- Tenants. How many applications, business units or research departments are hosted within an IaaS platform?
- Information/data output. What is the speed of information and delivery for insights and analysis? In a research environment, for example: is data analysis on genomic sequencing faster and more efficient than with a legacy system?
The value of OpenStack is never being locked down to a single providerFor those with an eye toward maintaining true provider autonomy, open-source OpenStack is a standard for deploying infrastructure as a service (IaaS). But there is a lack of clear documentation on how to roll it out, maintain it and upgrade the platform. Hence, companies and organizations often work with a provider to handle those tasks, but that decision to an extent negates the “open” intention and benefit of OpenStack. These flavors of OpenStack — whether from a Tier 1 systems provider or a turnkey provider — come with a variety of wrappers and customization to ease this deployment and maintenance. Which is a valuable enhancement that also has the unfortunate side effect of inserting a level of vendor lock-in. Once you outsource those important tasks to a turnkey provider, you lose much of the choice and autonomy that were the original draw for open source.
Unfortunately, down the road there is no easy way to simply export the data from a proprietary OpenStack platform to the open-source version. Switching versions may necessitate a massive amount of downtime and require the developer or database teams to work with each other on how to safely, and quickly migrate the hosted applications.
Short of rolling your own solution (which is fodder for another article), this is unavoidable. So as a customer, the choice that remains — once you adopt the outsource model — is which provider you want to pay a maintenance fee for the next three to five years. That choice is far from clear, but should not be made lightly. More on that in a moment.
Unforeseen costs of OpenStack talentThe costs of acquiring proficient open-source OpenStack talent is high, and it may be difficult for your company or organization to retain that talented staff for long due to market forces and increasing demand for their services. For example, if you elect a flavor from a Tier 1 or turnkey provider, proficiency now requires a level of specialization in that particular version — and the provider you choose will likely have already acquired the most proficient staff in the industry.
Eventually your organization’s staff members will achieve their own level of mastery — which now makes them considerably more valuable, and most likely to seek a new opportunity at the turnkey provider or with one of its competitors. Turnkey providers can typically offer higher compensation than enterprise IT, and often more varied intellectual challenges — two key measures for retaining top talent.
“We are continually asked by large, name-brand organizations if we think they should move to OpenStack,” says Storage Switzerland co-founder and industry analyst George Crump. “Before we answer, we look at their staff capabilities. They very rarely have anyone already familiar with OpenStack but often have personnel with the ability to be trained. There is clearly a need for more OpenStack-ready personnel or more open turnkey solutions that allow the seamless use of OpenStack as a service and the seamless exit.”
A report issued by Forrester Research analyst Lauren Nelson in May 2015 backs up this statement. According to Nelson, “once enterprises train members of the team, some find it hard to retain them, given the high demand for trained OpenStack engineers. For many enterprises, the challenges ahead seem too daunting without a vendor distribution and/or services to accelerate their journey.”
Owen Rogers, a senior analyst at 451 Research and author of the 451’s Cloud Price Index report, recently stated in an interview with Diginomica that, “finding an OpenStack engineer is a tough and expensive task that is impacting today’s cloud-buying decisions. Commercial offerings, OpenStack distributions and managed services all have their strengths and weaknesses, but the important factors are features, enterprise readiness and the availability of specialists who understand how to keep a deployment operational. Buyers need to balance all of these aspects with a long-term strategic view — as well as TCO — to determine the best course of action for their needs.”
In the endAs stated up front, I’m a huge fan of open-source OpenStack. Once ROI and TCO calculations are done, I believe that adopting OpenStack is less costly and risky compared to going with COTS software. But given the impact of maintenance and future modification, and the difficulty of finding, growing and retaining the requisite IT talent, selecting a provider becomes a critical and long-term choice. And it’s not one that can be readily changed down the line. When making that choice, three factors are key:
- The provider’s commitment to OpenStack (it needs to be in this for the long haul)
- The provider’s ability — and willingness — to understand your specific business and IT requirements (which can impact architecture recommendations, deployment cost-effectiveness, future enhancements, road map, etc.)
- The provider’s ability to easily and cost-effectively supplement the expertise of your internal team (basically, acting as an extension of your organization)
But only if you go into it with your eyes open.