Until a few years ago, you could almost guarantee that every technology vendor pitch would include a claim about how they could help a customer avoid lock-in. It could be through open-standards or open-APIs or an SDK that would allow customization. And then the industry changed and avenues to acquire technology expanded to include public cloud computing and the mainstream use of open-source technologies. These new “vendors” weren’t the same names that had dominated previous generations of IT, so they could use vendor lock-in as FUD to highlight why their new capabilities we worth a look from the IT department (or directly by the lines of business).
Back in the day, technologists would wait until the committees at IETF, IEEE, SNIA, W3C or some other standards body had decided what was officially a standard. Standards were intended as a way to manage interoperability, but also control costs so that no single vendor could dictate a technology and hence hold a market hostage on prices and profit margins. It was the leverage that customers had against the technology vendors. Interoperability was customer’s leverage against lock-in.
Somewhere along the way, may people seem to have forgotten what lock-in really means. They have forgotten that it happens every time any new technology is downloaded, deployed or implemented. Lock-in is the cost of making an initial decision + the cost of learning that new technology + the cost of maintaining that technology + some (potential) future cost of changing that technology. There are other “opportunity costs” that can also be factored in, such CAPEX vs OPEX (eg. public cloud) or agility costs of being able to modify the technology directly (eg. open-source), but those are really just variations on maintenance costs.
And the reality of today’s cloud computing world is that “lock-in”, as a measure of cost, has not gone away just because there are now options to use public cloud or open-source technology. Let’s look at some basic examples:
- If you use Amazon AWS, you are locked into using their architecture (Regions, Availability Zones, EBS, AMIs) and their management (APIs, etc.). While it is possible to move resources out of AWS, there is a cost involved with doing this (Divorce-as-a-Service isn’t free) – whether that means you have to convert AMIs back into another template format or you’re paying outbound bandwidth costs to remove your data or you have to modify your applications to leverage a new set of APIs (eg. AWS S3 vs. OpenStack Swift).
- If you consider using OpenStack, the first thing you need to decide is which distribution of the OpenStack code to use, and which projects to use. “Trunk” would give you access to the same code as everyone else in the community ($0 software cost), but you would then own the costs of deployment, integration, training and on-going upgrades. One of the 15+ distributions (PistonCloud, RedHat, IBM, Canonical, SUSE, Nebula, Debian, HP, Rackspace, Intel, Cloudscaling, etc.) would simplify the deployment and on-going support, but at a cost of licensing – along with locking you into their tools and add-ons. And there is currently still quite a bit of variation between OpenStack distributions (with some distributions setting up their own Interoperability Labs). To reduce some cost, you could attempt to leverage the RefStack resources, but this only validates to minimum capability levels and doesn’t ensure that some capabilities won’t lock you longer-term.
- If you think you might start with AWS but then move to a different cloud at a later time, for example because of cost or security concerns, then you’ll have the lock-in challenges of other cloud software not supporting all the AWS APIs (example: HP drops support for AWS API).
“Lock-in” originated as a term used by technology vendors to open up a conversation about switching from your existing technology. It simply means “cost” in some form or another. And just because you may be acquiring or consuming cloud computing technology from a new set of vendors (or via open-source foundations), it doesn’t means that those lock-in costs have gone away. They may just now be associated other line-items on your budget, such as operations or training or 3rd-party development groups.