When you look at the success of some very proprietary solutions and the loyalty with which customers defend them, you have to wonder if vendor lock-in is really as bad a thing as we sometimes make it sound.

The subtext in the discussions around data portability and interoperability in general in cloud computing is really about vendor lock-in. Those driving efforts to come up with solutions that allow customers to pack up their data and head to another provider are primarily concerned about the dangers of being locked-in to a single vendor solution.

But given the loyalty to some brands and products that are unapologetically proprietary and inherently create a vendor lock-in situation, one has to wonder whether vendor lock-in is really a bad thing and if it is, for whom?

Take the iPhone. Really, you can take it because I don’t have one and don’t want one. But millions of people do and they are incredibly loyal to this proprietary device. Apple does not apologize at all for its business practices that support a locked-in user base, and it is unlikely that consumers even consider this to be a negative when purchasing an iPhone. Indeed, the proprietary nature of the iPhone is not what keeps me from purchasing one.

After all, it does what it does and it does it incredibly well, with an ease that makes it usable by just about anyone. What’s to complain about? Yes, your data is locked up inside the iPhone, you aren’t going to pack it up and take it to a Blackberry or the next big thing. But users don’t seem to care and certainly don’t even consider that they might one day want to change. They’re in love with their iPhone, loyal as hell, and don’t really care.

It isn’t just loyalty, it isn’t ignorance of options. Explaining all the benefits of some other product isn’t necessarily going to win the day there. Folks are loyal to a product because it (a) does what it says it does, (b) solves all their problems and (c) the company isn’t going anywhere.

It’s only when one of these is violated that you begin to hear rumblings of anger from the basement of IT. If a product can’t do something or doesn’t do it to the satisfaction of customers, then they get angry. But as long as all three conditions are met, generally speaking, IT has no good reason to migrate to another solution. They don’t seem to care that they’re locked in to the solution because it’s solving their problems. As long as the vendor appears stable and has long-term viability, it isn’t really a problem, is it?

The increasingly complex nature of data center architectures makes a migration from one product to another difficult and painful regardless of the level of “lock-in” . As with applications, the more integrated an infrastructure solution is into the architecture and business processes, the less likely it is to be replaced. If it isn’t broke, don’t fix it is probably a truism in IT more than any place else today.

Increasingly organizations do appear to be looking more closely at the possibility of vendor lock-in with any given solution, even open-source solutions that may result in vendor lock-in because of the commercialization of support by a single vendor. Cloud computing is no exception, by the way, as indicated by a CIO.com survey focused on cloud computing issues:

That's according to a new CIO.com survey of 240 IT professionals involved in technology-purchasing decisions. The June 2009 survey, "CIO On-Demand Services Survey," reveals that cloud computing fears regarding security, data management, total cost of ownership, regulatory and compliance issues, and vendor lock-in have actually increased as compared with results from a similar survey in August 2008.

The thing is you rarely see an organization worrying about vendor lock-in where standards exist to ensure the interoperability and portability. If not of the configuration and/or meta-data required, at least of the interoperation with other IT systems. Take switches and routers, for example. All utilize standards like IP and even though the configuration of a Cisco switch is very different from an HP ProCurve switch, you rarely see anyone getting up in arms about being “locked in” to the configuration specifics of either option. The most important part of choosing most infrastructure solutions, it would appear, is that there is internal standardization on a given platform. If all the switches in the organization come from one vendor, it makes management just that much easier. Sure, a forklift upgrade from one switch vendor to another may be painful in terms of the configuration necessary to achieve such a migration, but still that doesn’t seem to engender “vendor lock-in” fears. IT isn’t agonizing over the decision, paralyzed with fear. We geeks fear change, but not that much.

There are no standards around configuration, just protocol support. The maangement scripts used to automate tasks or integrate the CLI with the rest of the infrastructure and management systems (Sonoa Systems’ CEO Chet Kapoor has a great example of this kind of “lock-in” in his post “The API is more than the new CLI”) developed for switch Brand X are very unlikely to work with Brand Y. If we look at more complex solutions up the infrastructure stack, we find more and more customization available and, unforutnately, that flexibility comes with a price: with each customization it becomes more and more difficult to extricate that solution without a great deal of effort from the infrastructure.

But without that customization what do you have? You have a turnkey solution that may suit your needs today, but not tomorrow. And when tomorrow rolls around you’re left with the option of (a) solving a new problem with a new product, adding to the overall management burden and costs to maintain or (b) forklift replacing the solution with one that’s more flexible and provides the ability to adapt to new problems and technologies more easily.

So organizations have come to demand flexibility and customization, but still fear (according to surveys, at least) vendor lock-in. Part of the appeal of open-source software was that organizations could have the source and modify it at will. Customers were no longer at the mercy of vendors to wait for new features. They didn’t have to worry about not being large enough to command a vendor’s attention and have every request attended to as soon as possible. They were in control. 

Vendors in the infrastructure space have heard that demand and have addressed it. Juniper’s new unified operating system allows development of custom solutions to be deployed across their network infrastructure devices. Cisco provides the means by which their ISR (Integrated Services Router) can be “upgraded” with custom developed software. And F5 has long offered its network-side scripting solution, iRules, as a means to customize its unified application delivery infrastructure to support the quirks, flaws, and unique environments in which applications are deployed. 

Not even standards can address this problem completely, as the customization and flexiblity of a solution is usually unique to the solution and, thus, there exist no standards to make it “easier” to back out and migrate to a different solution. You can’t run a solution developed on JunOS on a Cisco ISR, and vice versa. You can’t execute iRule logic on a Cisco ACE. These are solutions unique to the vendor that, although you may have the source code you can’t easily migrate to a new solution without work. It’s important to remember, too, that just because solutions offer the means to customize and extend does not mean it’s a requirement. You can still use a Cisco ISR without writing an extension, you can use a BIG-IP without ever writing a single iRule, and you can run a Juniper device without developing new functionality. It’s optional.

So the question becomes is the flexiblity and customization that customers have demanded for years and that inherently leads to deeper integration into the organization, making migration admittedly more difficult, worth it? Is vendor lock-in really a bad thing or is it just the fear of being locked into an emerging technology where long term viability of the vendors is in question? 

Go ahead, sound off. What’s your opinion? Is any feature/option/situation that leads to vendor lock-in inherently bad? Is it sometimes acceptable? Do you really even care or is this “fear” really a competitive vendor fear and not nearly as important to the enterprise as some vendors would have us think?

Has the possibility of “vendor lock-in” ever stopped you from making a purchasing decision or is it just a “potential risk” that’s weighed in the overall decision making process?

Related blogs & articles:

• Cloud Hype Peaks, But IT Concerns Increase – CIO.com
• Survey on Enterprise Open Source Usage Shows Disdain for Lock-In
• VMware cloud initiative raises vendor lock-in concern
• The API is more than the new CLI
• Cloud, Standards, and Pants
• The API Is the New CLI
• Meh. It’s Just Data.
• Duty Calls: Data Portability in The Cloud is an Application Integration Problem, Not a Cloud Problem