The End of Vendor Lock-In

How long is your current hosting contract for? How many years are you obligated to work with your current database partner? If you are in the cloud then these obligations don’t exist.

Technology moves at an incredible pace, especially in the world of engineering. We don’t just see this in new languages and frameworks, but in paradigms of abstraction. A whole fleet of startups and new companies have emerged, partnering with major cloud providers and offering enterprise-ready managed solutions for popular tooling.

These managed solutions embody agility and the ability for you to shift more and more focus towards delivering features and business logic to push your company into the future. AND the future is fast. Orders of magnitude faster than it is now. And with this, time to market and the ability to pivot will be more agressive than they have ever been. So we need this abstraction.

What Is Lock-in

Lock-in is the antithesis of agility and a road block to potential. It’s when you don’t have access to your own data, when contracts and legalities prevent you from moving platforms or force the use of a specific tool or technology. Lock-in is not going all in on a cloud provider. And lock-in is not using a managed service.

This mindset however is incredibly prevailing. Recently when attending the Google Cloud Next event in San Francisco is was able to chat with quite the volume of technical leaders and senior engineers working for major brands and on ambitious projects.

The general mentality being that if you develop using the services and frameworks for one cloud provider you are locked in. But let’s take some inventory.

Changing Fast

Look at all the applications and services deployed through your current organization. How many of them have undergone a rebuild or rearchitecture in the last 5 years? 3 years? 1? I would wager most of them. If you have older less-touched applications around I’d also bet those are the ones engineers least want to touch.

Technology is change, especially in software development. Stale applications that don’t adapt and grow will rust and wither.

Those that Challenge Change

When technologists push back on cloud-first architectures siting “vendor lock-in” as a concern I like to open the dialogue to hear their concerns.

• What part of this would lock you in?
• What would be the downside of using the cloud providers service?
• How would this “lock-in” differ from you building and hosting your own solution?

And the answers I get are always the same. (In order)

• We would be committed to using those technologies.
• Our applications would be built around specific technology.
• We can move our own technology between providers if we containerize it and aren’t using there tools.

All three of these are true.

They are true, but unrelated to the idea of lock-in.

Going with any technology is a commitment and choosing what to use should be based on need and investment value. If deploying a Kafka instance would require several engineers and ops professionals to maintain then that comes with heavy fiscal and opportunity costs to the business.

Going with any technology is a commitment and choosing what to use should be based on need and investment value.

Where Work Goes

Its true that if you use a managed solution and decide to change later it will require work, but migrations and refactors always require effort. The question is: Is that future effort more or less than the total effort it would otherwise take to deploy your own solution and maintain it AND migrate that soltion in the future if the situation arised?

With AWS and GCP you still own your data and have access to it, tooling is well documented and the reality is that Google and Amazon are both here to stay for the foreseeable future. New technology will always emerge and no one knows what major paradigms will appear 10, 15, or 20 years from now.

As long as you have access to your data and own your own business logic you can change platforms. As long as you aren’t under a temporal contract you can move any time.

The world of “lock-in” is gone, and what we are left with is an expanse of opportunity. Solutions and abstractions will vary from service to service and there are always multiple options, but we are in a world where we are no longer locked-in.