A popular cloud computing discussion is the vendor lock-in. The dependence on one vendor which is so large that the change in the current situation is too uneconomical due to high switching costs. I had such a discussion recently during a panel and would like to describe my general attitude about vendor lock-in. Because I think that a lock-in is necessarily not a bad thing. Actually, we love him. But, we mostly do not realize it. Moreover, we live for decades with him and each of us even every day. A lock-in is unavoidable, it is always there!
The daily lock-in
A good example is IKEA. Our apartment is made up of furniture from IKEA – up to the kitchen. Why? Because it looks good, fits perfectly together AND combining with furniture from other vendors is tough. And? We think it’s great because it does it’s job, but above all it fulfills our requirements. Analogous to IT it means that companies engage consciously on a supposed lock-in with SAP, Microsoft, Oracle and other vendors, because they need it and the vendors meet the requirements as far as possible. One only considers how many companies have adapted to SAP and not the other way around. Because initially there were no alternatives and because SAP met the required functions for the daily business.
The paragon of a lock-in is the iPhone/ iPad. And? Right, all love him! Because the iPhone “raises” the own coolness factor and also brings the functions so many need, even if they do not even know it before. Except for the coolness factor it’s the same for Android. One may argue that Android is open source and thus the freedom is finally greater. On the one hand this is true. And for the individual it’s possible to keep the change in check. From the perspective of a company it looks very different. Here the lock-in is comparable with an iPhone/ iPad, just in the Google universe.
No vendor lock-in is a pure marketing promise
It’s similarly in the cloud and here specifically with OpenStack. Rackspace is the loudhailer of the OpenStack community. The provider argued that it’s easier to go back into the own private cloud infrastructure if an enterprise depends on a public cloud provider who relies on OpenStack. And of course Rackspace delivers an own OpenStack private cloud distribution. At the end Rackspace earns with consulting and other services. Rackspace’s argument is correct, but rather to understand at the marketing level. Because even a vendor like Microsoft, with its Windows Server 2012, gives the ability to leave Azure and go back into the own infrastructure. And you can also free yourself from the Amazon Web Services (AWS) if you own your own Eucalyptus cloud. Although, Eucalyptus is still far away from providing all the services of AWS, but that will happen over time. I also continue to believe that Amazon will buy Eucalyptus sooner or later.
So, even with OpenStack you enter a lock-in. Although they talk about open standards and APIs. But in the end you will also be caught in the OpenStack ecosystem. This means that you can easily switch to another provider who supports OpenStack. But the topic Openness is here rather used as a marketing tool. After all, OpenStack and other commercial open source associations are no fun events. It’s about tough business. At the end OpenStack makes it only easier to change between the various providers that also rely on OpenStack. But, since all the vendors set up virtually on the same technology and distinguish themselves only through value-added services, you have the OpenStack technology lock-in. (Yes, of course it is possible to build your own OpenStack cloud regardless of a provider. But the (financial) burden is out of proportion to the later benefit.)
A lock-in offers more advantages than you think
A lock-in offers several advantages. He creates innovations that one as an alleged “slave” participates from. The vendors constantly roll out improvements from which we benefit. And, the lock-in is good, as long as he just does the job that is expected. If the solution meets the requirements everything is great! As a company, after the decision for a provider, you admit to the lock-in deliberately. On-premise one has engaged for years in a lock-in. Certainly one does not quite agree with one or the other function, but on the whole, one is happy, because the problems are solved and the needs are met. And, as a company in the cloud you take a not insignificant sum of funds in your hand. These investments have to pay first before you think about switching back. One should not be forgotten. If another provider wants to break a company free from an existing provider, it will do everything possible, to enable this path. So, before you get too worried about a lock-in, it’s advisable to look first how future proof are the services and the cloud provider itself and include it in a possible exit strategy.
Conclusion: We live constantly with a lock-in. This can never be completely avoided, and just keep up to very low. A lock-in is somewhat more flexible than the other, but the decision for one remains. Indisputable, we love him, the lock-in!
