The more use an organization makes of a particular vendor’s products or services, the more dependent it becomes upon them, and, in turn, the more difficult it becomes to change providers.

So it’s extremely important for customers to understand what the exit looks like, even if it’s unlikely they will exit in the near future.

Picture this not so uncommon situation. You’re building a cloud-aware application, using proprietary cloud APIs to control the infrastructure, provision and deprovision resources dynamically and send data back and forth between your application and your cloud provider.

Your application gets large and complex, and for whatever reason—costs, lack of features, reliability, scalability, etc—you decide to look for an alternative vendor.

You call a meeting to get opinions as to where you should be moving your workloads to, only to find out that switching requires you not only to change the API calls but to re-think and re-architect your application.

The problem is that an API is an abstraction of the underlying technology and the technology choices of the vendor. So using an API often dictates using an architecture style and designing an application around a specific implementation. That’s the lock-in.

Your engineering team is extremely busy, with no shortage of important projects to get to, and you know refactoring would be incredibly expensive and impractical, so you’re faced with the dilemma of either staying with a provider that’s pushing you back or spending valuable resources on refactoring.

The solution

Customers need to understand the trade offs of vendor lock in and should always enter lock in scenarios with their eyes open to the potential threats that it can cause. Above all, customers should always have an exit strategy from lock in.

Think about using open APIs as an insurance policy for the future.