Since I posted my missive about OpenStack not being our savior from lock-in or support costs I’ve had a number of comments and discussions about it. The discussions generally start from the point of view that I’m wrong. Let’s take a look at a few of these.
Also, it might seem like I’m picking on Randy Bias and Greg Ferro a little here but Randy seems like a good guy, and Greg is a friend, so there’s no animosity. Just point/counterpoint.
TL;DR version: OpenStack is cool but isn’t some magic tech that prints money, open source doesn’t mean you don’t have to pay someone to support a service built on it, customized open source and custom solutions using open source don’t mean someone can just pick up support for it, Linux and open source is actually scary to the bulk of IT staff out there, and every organization in the world wants less IT. More humans in your IT department isn’t less IT, it’s the worst of more IT.
“You’re being nonsensical and conflating switching costs with lock-in. They are not the same thing.” – @randybias, CTO of the OpenStack reseller Cloudscaling.
Dictionary.com says that lock-in is “an act or instance of becoming unalterable, unmovable, or rigid” or “commitment, binding, or restriction.” Seems about right for an organization that is unable to switch from one product to another.
How does lock-in happen in a corporation? One way is that the feature set offered by one solution doesn’t exist anywhere else. If you’re using those features and need them you can’t switch. Another way is that an organization doesn’t have enough money to execute a change. A change in infrastructure costs money in terms of staff time spent switching, license & support fees for both environments, and hardware to operate both environments in parallel for the duration of the switch. Last, sometimes there isn’t an exit strategy. There are quite a number of cloud solutions out there, especially SaaS ones, where a data export just isn’t a feature. For IaaS I always argue that as long as you can boot a VM from an ISO image there will always be an exit strategy.
OpenStack doesn’t free us from any of these things that contribute to lock-in. It doesn’t magically solve the feature set problem. Though it may save me some money in licensing it doesn’t magically put money in my pocket to pay staff to do the work to switch. It doesn’t buy me new hardware. It doesn’t magically require less support, though the form that support comes in may be different from other hypervisors. And it doesn’t have a magic migration path from other hypervisors.
“Free” software is rarely free to implement, and I’m sure Cloudscaling sends bills to people despite their basis in open source software. :) Open source cloud software is just another option to consider, like everything else out there, with its own pros and cons.
“*You* control your destiny with open source solutions and this is why open source is so broadly adopted in the enterprise.” – @randybias
“You can just get someone else to support your open-source software deployment.” – a bunch of people on Twitter
First, I call shenanigans on the idea that open source is broadly adopted in the enterprise, at least in the ways we’re talking about here. Might be headed that direction in some specific ways, like Hadoop, but I think this is optimism. Most open source software running in enterprises is there inadvertently, as firmware or an appliance, and not usually as a conscious choice. It’s actually a problem for many people trying to use VMware’s vCloud Director, as those deployments require Linux knowledge, and that’s something that most places don’t seem to have. Lack of Linux knowledge isn’t a plus for OpenStack, seeing as OpenStack is deeply, and in some ways quite arcanely Linux-based.
If there were broad, meaningful adoption of open source infrastructure we’d see more Linux expertise out there. We’d also not have to argue constantly with vendors about providing CLIs. Seriously, who chooses a single pane of glass over a CLI thinking it saves time? Windows admins!
Second, enterprises are risk-averse, and those that aren’t IT hosting companies tend not to deploy anything, much less open-source software, without a vendor standing behind it in some way. Why? It’s a hedge against staff knowledge gaps and personnel issues, at least. The only way a company will ever really control its own destiny with open source is if it forks the code base and hires its own developers to work on the software. That might be feasible for companies like Google where IT is their product, but for most others it’s not even a consideration, and so they will be at the mercy of the open source developers just like they are at the mercy of the commercial vendors. When is the last time you had a say in the way Red Hat Enterprise Linux was built? Does Richard M. Stallman really represent your best interests? Never, and hell no.
Besides, you’d still have to pay the developers you hired to support the forked codebase. Does that cost more or less than an equivalent commercial solution?
Right now it looks like most of the commercial offerings of OpenStack are customized in some way, and Dominic Wellington (@dwellington) said it best: “OSS also has lock-in: custom development on one stack is rarely portable to another. #TANSTAAFL”
Simple experiment: call Piston Cloud and ask them if they’ll support a Cloudscaling environment.
“The cost per host for VMware/Citrix quickly becomes unsustainable… if you are building a cloud platform for 50K to 100K hosts.” – rearranging Greg Ferro’s argument just a little. Greg is a networking consultant in the UK.
Neither of us know what hosting providers pay for VMware or Citrix licensing so we probably shouldn’t talk about whether it is cost-competitive or not. I guess I’m not really talking about hosting providers, though, I’m talking about more traditional enterprises. Hosting providers have their own economics and motivations that are much different from companies that don’t offer IT services as their primary product. In some ways VMware is also a competitor in these spaces. Does Rackspace want to run their competitor’s software? Probably not. Makes total sense for them to develop their own software and maintain a small army of coders to make it work. Even their choice to give it away has benefits, too, in that others will develop the ecosystem for them for free.
“When licensing software for more than 10K units, it’s more likely to be cheaper and better to use humans. Even better, you can design and more tightly specify your solutions to exactly match your business needs.” – Greg Ferro
Sounds like the ultimate in lock-in to me! It’s a classic buy-versus-build decision. For a few operations build makes more sense because of the product they’re delivering, and by building their own infrastructure they gain a competitive advantage. For most it makes more sense to buy, because IT services are not their competitive advantage, not the market they are in, and not a market they want to be in. This is the same rationale that led Facebook to release the Open Compute Platform specs — it’s not their core business.
Also, I’ve never correlated more humans with more tightly specifying anything, except maybe a new internal HR system. And what is an HR system? Overhead you wouldn’t need if you had automated instead of hiring. :)
“While it is complex and ‘hard’ to manage a lot of human meat puppets to deliver projects, Amazon has proven that it’s possible. And Facebook. And Google. Your business can also achieve these outcomes if you are smart and able to refocus on your IT resources.” – Greg Ferro
Apples and oranges. This is confusing the companies where IT services are their product with companies that consume IT resources. A corporation that makes water pumps hires a lot of meat puppets to build water pumps. Likewise, a company that makes a social networking site hires a lot of meat puppets to sell you ads. Having a bunch of employees and being successful doesn’t mean that you did it right, though, or that any of those employees are the IT staff we’re talking about.
The one thing these companies do have, though, is automation and standardization, which are central tenets of cloud computing no matter what software you run. They automate and standardize to cut unneeded staff, reduce human error, and refocus the staff they have on the interesting problems. Ask a Rackspace employee sometime what their server to admin ratio is. It’s thousands to one. Then consider that the average enterprise is lucky if they get to double digits of servers per admin. Facebook, Google, Amazon, and Rackspace don’t have more people than they need, and they don’t have people doing things that are best left to machines and scripts, which is exactly what my second main point is. Better software, fewer humans, more clue.