Click to learn more about author Matt Yonkovit.
Ever since the start of information technology and the first computers were invented, there has been vendor lock-in. From the very first mainframes through to modern cloud and data companies, the guidance has been to avoid lock-in where you can. It’s also the reason open-source software was created, so that users could retain control over their applications. Managing your IT destiny has always been important.
However, there is a lot of conflicting advice when it comes to maintaining control. Database vendors advise against getting locked into a single cloud provider; cloud providers say avoid being locked into a single database; other parties counsel you to avoid lock-in from both. A growing number of people believe that lock-in is unavoidable, so it’s better to just concentrate on other things instead.
Getting to the bottom of this involves sifting through what is actually going on, and working out the impact it has on your business, as well as deciding what you are happy to accept. The truth is that every decision around IT involves some degree of lock-in, and you will have to live with the consequences of any decision over time. Of course, knowing this, in theory, is different from applying it to decisions as they are made in real life.
It’s important that you consider how you can keep control of your data when you choose who to work with. Are you willing to trade convenience and speed for potential lock-in over time? Without conscious consideration of the impact of your IT decisions, you can end up trapped, without the key to your data.
Where Are We with Lock-In?
When you build an application or decide on your infrastructure, you are making decisions you will have to live with in the future. From the obvious things like picking a programming language, database, or cloud provider, through to implementing a specific deployment methodology, these decisions will affect your team and your business.
Even choosing an open-source project for your database is a type of lock-in, as you will depend on this over time. When and if you then want to change, it will take work to migrate away from that project, whether it is open source or closed. The critical things to consider are how much work it will take to move, and whether this hypothetical cost will be higher than the return on investment from your implementation.
In an ideal world, this issue should not arise. Companies should want their customers to be so happy with the service or software that they don’t want to leave. The challenge here is how we create the value that customers want. A customer might be happy now, but their circumstances may change and the right decision made in the past, may not be appropriate in the future.
Value is subjective, especially in the open-source space, where you compete with free access to something that customers can achieve themselves (with enough effort). This leads many vendors to create services or hooks that make it more difficult and challenging for users to move away from a particular tool, even if it is to the free version of the same software. This includes only adding new features to the paid version of a project, or deliberately keeping some “secret sauce” back from the open-source project.
This has been the approach of “open-core” versions of open-source software for many years. Open core offers users special features or exclusive services that make things easier for users in exchange for additional fees. While this creates value for a particular group of customers, it leaves others at a disadvantage. Over time, users rely on these features so much that they become locked in.
Moving away becomes an expensive and lengthy process. Vendors then count on the fact that the cost and pain of switching will be greater than the cost and convenience of moving somewhere else.
This is why many people choose community or open-source versions of the software they run. Although you are still locked into the project – you rely on that open-source project or software version, after all – you still have the ability to choose another vendor to support you, move to another platform, or avoid escalating fees for open-core software licenses. You can even fork the whole project and create your own version if you desire. Avoiding open-core or enterprise software versions is one less stumbling block in this process.
The Role of the Cloud –More Accessible, Yet More Difficult to Leave
The arrival of cloud computing and “as a Service” options has changed the lock-in discussion again. Now you have another layer of choice when it comes to accessing open-source projects, as cloud can make those projects easier to deploy and use. At the same time, this ease can make it more difficult to maintain portability and control of your technology over time.
For many users, the cloud makes things easier. It opens up technologies previously out of reach for smaller developer teams that lack specific skills. While this can be useful, it also means you can be less prepared to deal with problems if and when they occur. If the team lacks core skills and understanding, it can be difficult to solve problems for yourself or avoid unnecessary spending.
Alongside this, it is easy to end up using services that are not as open as they appear. For example, some cloud database services are advertised as being “open source compatible.” In practice, this often means that they have additional components linked to open-core projects, rather than being fully open source. Or, they may effectively be proprietary versions of open-source projects due to the changes in approach and functionality they have implemented. Either way, this leads to differences between versions of the same open-source project and means they are no longer compatible with each other.
In practice, there is another problem – the business model for the cloud is based on use, rather than effectiveness. A cloud provider sells you capacity, and in return you get business value. However, there is no incentive for the cloud provider to ensure efficiency for you as a customer. In fact, the more capacity you buy, the better it is for them. This means that there is no motivation for them to make their services more efficient, which is problematic if you have a limited budget.
Somebody Else’s Problem
Douglas Adams came up with the idea of the Somebody Else’s Problem (SEP) Field in his book “Life, The Universe and Everything”: “An SEP is something we can’t see, or don’t see, or our brain doesn’t let us see, because we think that it’s somebody else’s problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it’s like a blind spot.”
For many companies, the concept of lock-in falls under the SEP Field. Less than 15% of IT leaders and board members said they cared about lock-in in our Changing Face of Open Source survey earlier this year, while 21% of all respondents specifically flagged avoiding lock-in as a benefit they wanted to achieve.
While it is gratifying that people concentrate on the value that open source provides, helping people understand the value of not being locked-in is something the whole open-source community will have to work on.
There are several reasons behind this SEP situation. One is that the average tenure of a developer at a company is less than three years. By the time prices for a given service get too high or management considers a move, it will be someone else’s issue to deal with, as the original developer or architect responsible for the choice has already moved on.
Another reason is the rise of faster iteration as an excuse to not think too hard about choices. This is summed up in the famous Mark Zuckerberg quote that companies should “move fast and break things.” This captures the spirit of being unafraid to make decisions, try new things, and invest in new technologies, but it also sums up how companies can make rash decisions when spending someone else’s money to deliver something, then worry about reducing costs later.
For those who have to deal with the infrastructure, the lock-in issue is fundamental to their planning. They understand there will be long-term implications of decisions made around which database to use, the language to program in, and which cloud to implement on. Anything that can help avoid too much lock-in will get considered.
This is one of the reasons why containerization has become more popular. Alongside the ability to implement microservices, containers are more portable and can theoretically run in the same way across multiple environments, from internal private cloud and on-premises systems through to public cloud and hybrid deployments. The whole “cloud-native, run-anywhere” approach is tempting as a way to get the benefits of cloud, without being locked to a specific provider.
Lock-In – Bad, or Just Misunderstood?
In summary, lock-in is a real challenge and IT teams need to consider it when planning their overall strategies. If you need to extract your systems from a specific provider in the future, it can burn a lot of money and hours.
Trading some freedom, portability, and control is fine, as long as you are able to achieve your goals. Working with a specific provider could help you deliver faster, more efficiently, and at an acceptable price. If those criteria are met, then being tied to that provider is simply a strategic decision.
The bigger issue is companies going down a particular route and finding themselves in a lock-in situation without their knowledge. Getting tricked into vendor lock-in, then being held hostage at a higher cost level than you anticipated, is the nightmare scenario that lock-in represents for most IT leaders.
So, what is the right approach here?
Rather than denying lock-in, or painting it as the ultimate evil to be avoided at all costs, it’s important to get to the truth of any situation and view it with eyes fully open. It’s up to you to choose the level of lock-in that you are comfortable with, and to select the right partners to help deliver on your goals. Unlocking the value of your data might involve relying on a specific database or cloud provider, but that does not mean that you should commit for all time. Ultimately, you need to find the combination of features, benefits, and potential lock-in that works best for your business.