I’ve been knee-deep in cloud technologies for the last five years, working with startups to Fortune 500 organizations. Surprisingly, the concern of “Vendor Lock-in” didn’t start popping up until about a year and a half to two years ago. Realizing this, a couple of questions popped into my head:
- What exactly is vendor lock-in?
- Why now, is vendor lock-in such a concern where it wasn’t before?
- Can it be avoided?
- What should an organization take as next steps?
What exactly is vendor lock-in
Lock-in is not a new concept, before the cloud when everything was on-premise it was and still is a real thing. At its heart, vendor lock-in is the inability to shift from one vendor to the next effortlessly. The failure to move can be for a couple of reasons:
Let’s be honest; cost is the number one reason why companies experience vendor lock-in and the biggest reason that it is considered a problem. Changing from one vendor can cost your company for migration, training of staff, consultants, legal review, lost employee productivity, etc. Your company will see these costs in at least one if not all areas, the larger the application or hardware, the larger the cost to move.
On-premise there are varying degrees of these costs. For example, changing server vendors probably isn’t very expensive, but it will take you 3-5 years to age out all of the old vendor and phase in the new vendor. Servers are essentially commodities, and thus, little cost associated with changing them. Using a virtualization platform such as VMWare or Citrix makes them even more of a commodity and cheaper to replace since you have they hypervisor as an abstraction layer. Now let’s talk about storage, now you are starting to feel the pain. There are substantial costs regarding migration of data and probably training. Taking it one step further to your ERP system you are feeling the hurt, productivity, training, legal contract review, and consultants. It’s making my wallet hurt just thinking about it.
In the cloud, many of these costs still exist, but there are ways to mitigate some of them. The best way to reduce the costs to switch cloud vendors is to add an abstraction layer. What do I mean by that? Well, let’s take a look at serverless technology for a good example. You could deploy your program using CloudFormation, lambda, and SQS for queueing. But this is vendor locked-in; Lambda, SQS, and CloudFormation are all AWS proprietary tools. Instead, you could use the serverless framework. The serverless framework is an abstraction layer that can deploy your config to any of the major cloud vendors, so your staff only has to learn one tool. You can also change the cloud vendor by tweaking some code, or with the serverless event gateway, you can span all of the clouds. Sounds pretty great huh? There is only one problem with this solution. You’ve just vendor locked-in to the serverless framework. The same goes for build pipeline software or containerization. You’re still going to be locked into some vendor at some point unless you build everything internally.
Contracts aren’t always a roadblock in changing vendors, but some vendors make it very difficult through hostile pricing tactics. Some vendors have a continuously upward pricing model; once you buy into their products and set a utilization level, you’re stuck there forever. If you decide to use less of their product later, you still have to pay the higher price. Your only option is to get rid of all of their products and kill the contract altogether, not always an easy thing to do.
Typically, with the cloud vendors, these contracts don’t exist (barring any individual pre-payment plans for substantial discounts). The cloud is a pay as you go consumption model if you don’t want to use it anymore, don’t and don’t pay anymore. Seems rather simple and fear free to me.
Having staff with the right skill set is a significant blocker to changing vendors. Having been in technology for 23 years, I know that vendor technologies are close and if you know one, you can still poke around another and figure it out. Your staff probably has enough experience to make the switch to a new vendor. However, when a problem arises, experience has taught me that issues don’t live in this superficial area of vendor crossover, they live deep in historical knowledge and experience. Lack of this knowledge is where the risk lies regarding skillsets.
In the area of skills, the cloud and on-premise are somewhat close when it comes to the skill set requirements for changing vendors. The rate of change in the cloud is substantial, and there are many criteria and capabilities to be kept track of continuously. If you look at the what’s new on AWS, there are about 20-30 changes a week occurring in just the AWS cloud. The amassing of this knowledge is what makes operations efficient and is a considerable opportunity cost upon changing.
Proprietary technology is the last area that causes vendor lock that I’ll discuss. Typically, I don’t consider proprietary technology to be a bad thing. I view proprietary technology as something that can be used as a differentiator and can give your company a competitive edge. Using the latest and greatest technology is what can keep your company moving ahead and being able to iterate quickly keeps you ahead of the pack. However, quick iteration is the key, if you don’t have an agile process that can make use of the next technology you fall into the vendor lock-in trap. Also, you will want to keep an eye on migrating to a non-proprietary solution once the technology becomes mainstream. This lack of agility is how companies get in trouble; Technology lock-in leads to the number one problem, cost. The vendor knows you can’t iterate off of it (you would have already) so they drive up maintenance and renewal costs.
Why now, is vendor lock-in such a concern where it wasn’t before?
I’ve found myself scratching my head as to why vendor lock-in is such a concern with the cloud, where it wasn’t mentioned as much in the on-premise world. From my point of view, the cloud offers unprecedented ability to shift workloads from one cloud to another. Additionally, the primary cloud service providers (CSPs) usually (sans a few proprietary offerings) offer competing products at competing prices.
I attribute most of concern to stem from fear of having all of your eggs in one proverbial basket. On-premise, your infrastructure is composed of multiple vendors, storage, networking, servers, etc. If any of these vendors starting to raise prices, fail, be sold off to a competitor of your business, it wouldn’t affect everything you have. Such is not the case in the cloud and probably why people become cautious.
Another important point is that when I think about the cloud, I’m looking at it from a perspective of a highly automated, defined as Infrastructure as Code, and using opensource abstraction layers whenever available. So, moving from one cloud to another or using more than one cloud at once is significantly more manageable as I’m not going into the cloud console and setting everything up by hand. If you’re going to treat the cloud like a conventional data center, then yes, it will be significantly harder to move your workloads.
Can vendor lock-in be avoided?
Vendor lock-in is impossible to avoid, at some point you’re going to use something, be it a proprietary technology to give you an edge or an abstraction layer to provide you with cloud mobility. These are still vendors. Now there are ways to de-risk abstraction layers by using open-source technologies. Using open-source allows you to continue work if the vendor goes out of business, or if they start taking the product into a direction that doesn’t align to your needs. It also ensures that pricing won’t be a handicap in the long term as well. Of course, there are cons to using open-source as well, but I’ll save that for another blog post. My point being, you will need a vendor at some point, and you should choose those vendors carefully and re-evaluate them on a timely basis to ensure they are still the best choice for your company. The cloud has driven innovation to breakneck speeds. This speed causes technology, and offerings fall in and out of favor faster than ever.
What should an organization take as next steps?
There is little difference in the steps to take if you’re starting out or are well into your cloud journey, but rather how you implement them. The key things are to start laying down the groundwork to create a flexible cloud deployment that uses IaC and DevOps to the maximum extent and abstraction layers where possible. Using these three items will significantly reduce the amount of work required to convert from one cloud to another or a multi-cloud environment. If you are already deployed into the cloud, the prudent course would be to start to migrate to these technologies as you make changes, perform deployments, and upgrades. Thus, allowing you to phase out the old manual configurations over time without disrupting current work.
The prudent advice is don’t go it alone. Many companies provide cloud migration and deployment services, and they have the in-depth experience and breadth of knowledge to assist you and prevent costly expenditures and reconfigurations due to deviations from best practice. These firms also have the pulse of upcoming and current technologies and can direct you for fast adoption and prevent vendor lock-in difficulties. Most importantly they help you in breaking cloud anti-patterns that originate from an on-premise mindset which will help to significantly lower cost and management overhead in the long run.