OpenStack Isn’t Our Savior from Lock-In or Support Costs

by Bob Plankers on December 29, 2012 · 5 comments

in Cloud,Virtualization

There is an attitude among some now that OpenStack is, or at least will be, our savior from vendor lock-in in the Infrastructure-as-a-Service cloud space, as well as something that will help corporations save a lot of money in licensing fees from VMware. While I see the potential I think there’s more to the picture.

To start with, OpenStack will lock you in just the same as a commercial offering, even though it’ll be “open.” If you want to move from OpenStack to another solution to another there will still be a bunch of hassle to move virtual machines and applications, just the same as if you wanted to move between VMware and Hyper-V, or to a public cloud offering. OpenStack is just as proprietary as VMware or Hyper-V solutions in this regard. Right now it may be even more proprietary, as there isn’t much of an ecosystem of third-party and native tools for it. That’ll change as the product matures, but they’ve got a long way to go to catch VMware and their ecosystem. Everybody speaks vSphere, and increasingly everything speaks vCloud. Look at Hyper-V — it’s been around for years and its ecosystem is only just starting to take off.

As far as helping corporations save a lot of money… we’ll see. To me, OpenStack represents a tradeoff between staff time and support costs. Running OpenStack right now requires more staff time to administer and support it than a similar VMware implementation, because it’s a completely different skill set than your IT folks likely have now, and because that skill set will likely involve actual software development[0] to really support it well and make it work in your own organization without commercial support.

Yes, a VMware implementation is more expensive in license fees and software support, but compared to hiring more people it’s a wash. You can spend $100K yearly on staff or you can spend $100K yearly on SnS from VMware (or Piston Cloud, for that matter, if you want commercial OpenStack support). For me, the tie always goes to the solution that involves fewer humans. Humans are expensive, take up physical space, require expensive, complex, and unproductive auxiliary support systems like payroll and vacation and bathrooms and laptops and air conditioning, are annoyingly subject to Metcalfe’s Law[1], and are often just as temperamental and hard to work with as VMware software. Given a choice between buying more humans or buying more vendor support I usually side with whatever solution has fewer humans, and automating the difference. And frankly, most organizations will opt to have a commercial support contract anyhow, thereby negating most of the SnS savings arguments.

To be clear, I’m not anti-OpenStack at all. I think it shows an enormous amount of promise as a second real on-site end-to-end cloud infrastructure option. Let’s not get ahead of ourselves, though. It’ll be a year or two before it’s something mature enough for most organizations to consider, with its own commercial support options, and an ecosystem with enough tools to solve problems for the enterprise. Then we can talk about lock-in and costs.

——

[0] A real developer, not an IT guy that knows Visual Basic and took C in college and has “fixing the printer in HR” in his job description. Of course, managing a development team might not be a skill set that your organization’s management has, either.

[1] Metcalfe’s Law, according to Wikipedia, states that “the value of a telecommunications network is proportional to the square of the number of connected users of the system (n^2).” For humans you can replace “value” with “amount of communications necessary to keep the team aligned and operating.” If you have a team of four people your communications effort can be expressed as 4^2 = 16. Grow that by two people, such as the folks you’ll hire to support OpenStack, and your effort can be expressed as 6^2 = 36. Certainly non-linear, and at a certain point you spend more time communicating than you do working on actual, real problems your business has.

Previous post:

Next post: