In everyday life, no one would want to buy into a service where they felt they had no alternative provider.

We all take competition for granted. For consumer utilities such as gas or telephony, it would be inconceivable to buy into a provider where you had absolutely no ability to switch provider in future. And in any service I can think of where competition cannot thrive (such as the UK rail network), we as consumers pay the price through poor service, and complacency.

That is why cloud vendor lock in is one of most common (and important) conversations I have with clients.

Decision makers are rightly concerned about being locked into a cloud platform with no clear exit strategy.

Vendor lock in is not a new concern in technology.

I can remember over a decade ago being tasked to architect and develop a web application that was built to run on on both SQL Server and Oracle databases, just in case the company changed its “strategic” database vendor. That seems crazy now, and a real waste of money; but the customer had concerns about owning a technology that might die. The truth is, legacy never dies; it just hurts if you cant see the exit.

Vendor lock in is particularly important to consider in the design of cloud services and integration; Part of the promise of the cloud is to only pay for what you use when you use it. It is an OpEx driven financial model, avoiding a big up front costs for licensing and hardware in favour of metered consumption. This is good for most businesses, but some clients are concerned that they may incur greater costs in future if a vendor increases it’s pricing. Customers of cloud vendors need to understand what the exit looks like, even if it is unlikely they will exit in the near future.

Good lock in

If lock in is undesirable, how can it ever be a good thing? In software architecture (like all forms of design), no decision is a zero sum; there are always trade offs in the decisions we make. Beware the technologists who turn up with a single “right” answer. Life is not so simple as “AWS is wrong” or “Open source is the only way”. There are no new problems to solve in technology.

However much of the cloud services market is focussed on pioneering new approaches to old problems. This is particularly true of the software as a service and platform as a service market. Vendors are providing innovative new ways of solving problems, and if you are the first to market there is inevitably an element of lock in. Technologists cannot chastise vendors for lock in created through innovation. There are many first to market examples. Amazon were the pioneers of massive scale storage in S3 with a proprietary api to consume the service. Salesforce invented a new market in cloud crm with entirely proprietary tools and language constructs. Azure invented the notion of managed platform compute.

The trade off many face when choosing a cloud vendor is between buying into a unique selling point that is built, deployed and managed in production as a finished capability and building something new, costly and unproven. This is good lock in, so long as there is an exit strategy.

Bad lock in

After the pioneers create innovative new services, the competitors arrive to challenge them. And after some time, a “standard” emerges, normally in the form of protocols. Much of what Amido does is about really understanding the protocol soup on standards that is the internet. This stuff is important to anyone who cares about the integration and operational model of their digital business. Standards are a good thing; they provide an exit strategy to vendor lock in. Proven standards de-risk complex undertakings, by defining contracts against a pattern that is proven to work against certain design goals. This is pure SOA philosophy.

However, the term “standard” should be treated with some caution; standards are open to interpretation. They are sometimes hijacked by a vendor as a marketing tool to attack their competitors. In my opinion, this is what open stack represents today; it’s a vendor backed (Rackspace) claim of a standard that the majority market leading cloud service providers have yet to adopt. The innovating cloud service providers tend to adopt standards when they become too mainstream to ignore anymore. Recently, Microsoft have become very good at doing this; examples include the Azure Service Bus adopting support for AMQP, and Azure Active Directory supporting the majority of identity protocols and token formats.

A vendors adoption of standards is where bad lock in can start. Many vendors approach standards with an “embrace and extend” strategy to keep you locked into an eco system. The most obvious examples of this are with browsers. Vendors adopt the latest HTML standard and then add their own browser features that extend the standard. When sites use these features, users remain locked into the browser. IE6 is the quintessential example of this problem.

Embrace and extend is caused by a vendor having an agenda to cross sell you more services. The truth is, all vendors have an agenda. One needs to understand the vendor’s business model to avoid the pitfalls of vendor lock in. Google sell advertising. Apple sell hardware. Amazon sell content. Facebook sell you. Microsoft are mid flight between being a seller of software licenses to a seller of cloud services. Each of these vendors have different forms of lock in caused by what is commercially most important to them. Because Amazon sell content, they push services such as Kindle onto all platforms no matter how exotic; the lock in is in the content itself. Microsoft’s move away from licensing into cloud services has meant that Office 365 subscribers now get a full fat (excellent) office suite on their iPad; the lock in no longer with Windows but to the Office 365 subscription.

Bad lock in therefore is essentially capitalism at work; it is bad, but it is also understandable.

Ugly lock in

Where bad lock is visibly unpleasant, ugly lock in is invisible and devious. It is the footballing equivalent of a cynical foul. Again, it is caused by a vendor agenda, but in my opinion the difference is that it involves a vendor removing support for something previously supported, or changing terms and conditions to force a third party to remove something.

There are several examples of this I can think of in technology:

Google attempting to remove support of the H.264 video codec from Chrome in an attempt promote its own WebM codec.

Apple changing its iOS App Store terms and conditions to force third parties to remove in app purchases that bypass the App Store. This meant apps such as Amazon’s Kindle app had to remove the store button from its app, while iBooks keeps its link to iTunes.

Fortunately, I am not yet aware of any ugly lock in scenarios with cloud services, but I suspect that is purely because the commercial market is still maturing.

Conclusions

Cloud service customers should embrace vendor lock in when there is a clear commercial advantage to adopting the vendor’s cloud platform. However, customers need to understand the trade offs this approach brings and should always enter lock in scenarios with their eyes open to the potential threats that lock in can cause. Above all customers should always have an exit strategy from lock in. At Amido, we are committed to “no vendor agenda” with our clients, providing impartial advice to help client make decisions around the cloud services lock in conundrum.

‍