Lock in is an oft discussed consideration when making technology decisions. I tend to see it used more by vendors seeding Fear Uncertainty and Doubt (FUD), but I also see it in the native decision making processes of many of my customers. Let’s take a look at it, starting with what it really is. I’ve dabbled into this topic a bit in the past if you’re interested: http://www.definethecloud.net/the-difference-between-foothold-and-lock-in/.
If you’re an American the best example I have is your cable company. Those bastards have you locked-in. At some point in human pre-history they footed some of the cost of getting cable run to neighborhoods, and the homes in them. They used that investment to lobby politicians into providing them government protected monopolies. Since then they’ve spent obscene amounts of money keeping your politicians fat and happy in order to maintain that monopoly. Don’t like their pricing, offering, etc? Too F’ng bad. If you want decent broadband internet access, you’ll be paying them. Because you already pay them for that, you’ll probably lump in some cable TV. A content medium allowed to stay horrible and antiquated based on the above monopoly. In short, you’re locked-in.
This is the most extreme form of lock-in, but it does a good job of illustrating the point. Lock-in can be a natural effect of the technology, purposefully driven into products by the vendor, or even driven through law and governmental controls such as above. Lock-in is real, exists all over the place, and can range from annoyance to being a real problem creating huge costs to the end-user as is the case above. FYI if you want to do something about that above monopoly skip voting about it unless you’re a fan of wasting your time. Instead use your wallet and switch to your cell-provider for home broadband when they start offering it in your area, then dump cable TV in exchange for the plethora of internet TV options.
Now let’s take a deeper look into lock-in starting on the consumer side. Love them or hate them, Apple has one of the most locked-in eco-systems in the consumer world. They beautifully tie their hardware and software together building an eco-system where each Apple product often only works with others, and each Apple product is greatly enhanced by the next. You like the IOS experience, great, buy an iPhone. Love your Android phone but really want that shiny Apple watch? Time to replace that phone. Even the default browser on the phone is Apple software. Companies that want into that closed system pay for it. Google is reportedly about to pay Apple $9 Billion for the privilege of staying the default search engine (https://9to5mac.com/2018/09/28/google-paying-apple-9-billion-default-seach-engine/.) Even their cable, and interfaces are often proprietary forcing you to buy their expensive eco-system of accessories and adaptors, which from what I hear tend to change with every new phone.
Now, while that’s a lot of lock-in it isn’t necessarily a bad thing, and shouldn’t necessarily keep you from buying Apple. It is the reason I don’t buy Apple products but not simply because the lock-in exists. I don’t buy Apple because the devices, prices, features, as a whole don’t outweigh the lock-in for my personal use-cases. That is going to be a different decision for every individual. The moral of the story is that the existence of lock-in shouldn’t bar you from choosing a product, but it should be weighed against all of the other factors. In my case, if I was willing to switch from PC to Mac that would be the tipping point to switch me into the entirety of the Apple eco-system.
Now let’s move up the stack to enterprise tech. There is a lot of real and perceived lock-in. Networking is a great example of where it gets talked about a lot. Interoperability in network is driven through standards, but those standards move s-l-o-w-l-y. Often networking vendors launch features, protocols etc. before they become standardized. This typically means that the feature will only work with their equipment and software. In these cases it doesn’t mean you shouldn’t use it, if you need it now, you need it now. Again, you weigh the advantages against the risks, just like every other decision.
As we move to cloud, the lock-in conversation appears again. Each cloud uses it’s own API, provides it’s own interfaces, and features, nearly all proprietary. If you design and build an application on cloud a, you’ll need to redesign and build it if you want to move. This creates a perceived lock-in problem. Should I put all of my eggs in one basket knowing I have a costly transition if I ever need it? Should I design my apps to run on multiple clouds? Should I attempt to implement some form of cloud broker that can abstract the underlying architecture and provide cloud portability?
These are valid questions, and will have to be assessed at some level within every organization. That being said, the potential lock-in should not turn you off from cloud adoption. The on-premises infrastructure you’ve been running for years has as much, or more, lock-in than any cloud you may move to.
The biggest pitfall to avoid comes in the form of a specific form of multi-cloud deployment in which organizations attempt to build apps for multiple clouds. This will almost always be a mistake, whether it’s to avoid lock-in or some misguided disaster recovery/business continuity strategy. The issue with this method is the significant cost and complexity involved in trying to build an application capable of running on multiple-cloud environments. These will almost always outweigh the perceived benefits.
Multi-cloud is not a bad thing, but avoiding lock-in should not be a primary factor. Additionally when looking at deploying a multi-cloud environment you should be looking to do so on a per app basis, not disaggregating an individual app. There will also be some limited use-cases where individual application tiers, or components may reside on separate private or public cloud infrastructures.
In almost all technology cases your complexity and overall operational costs will be exponentially lower the fewer vendors you utilize. From sales calls, product updates, to integration points and customization each additional vendor adds cost. This doesn’t mean that you should move to single vendor strategies, it does mean you should assess the decision carefully. You want a dual-vendor strategy at each technology tier, great, stick to two. You want to choose a single vendor for each piece of the stack, fantastic. Either way align the costs and complexities, to the benefit they provide.
The downside of lock-in is universally exaggerated. The real question is whether you’re getting the value from the product you need, in an eco-system that supports your requirements, at a cost you can afford to pay. If those things weigh out, then any real or perceived lock-in becomes a complete non-issue.
