Trying to Avoid Lock-In Mostly Leads to Just Different Lock-In – Worry About Business Outcomes Instead

I’ve heard so many arguments about lock-in from different people, and I’ve seen people do all kinds of crazy things to avoid it.

In my mind it’s pretty simple:

Lock-in is unavoidable.

IronMaiden

This is an Iron Maiden. You probably wouldn’t like to be locked in one. You’d probably do a lot to avoid getting locked in one!

Why Consumers Sometimes Desperately Try to Avoid Lock-In

There are a couple of main reasons some people try to avoid lock-in:

  • Flexibility to choose whatever solution components they like, which can lead to lower costs.
  • Potential for higher quality and/or quicker time-to-market if the right components are chosen.

These are powerful motivators, and as you will see they can easily lead customers down paths that are often sub-optimal and achieve the exact opposite results of what’s intended.

How People Try to Avoid Lock-In

I’ve seen all kinds of ways to avoid lock-in. I will pick some use cases from experience, but this applies to every discipline.

I’ll list the approach, desired benefit, and explain some of the dangers after each example:

Use a storage virtualization appliance in order to turn disparate storage arrays into commodity items and not be locked into any storage vendor.

    • Congratulations, you’re now 100% locked into the virtualization appliance and all the associated licensing fees. It’s not a philanthropy.
    • You’ve also rendered utterly useless some incredible functionality in the underlying arrays – and that functionality has no good equivalent in the virtualizing system.
    • You’ve made support even more complicated because you now have to deal with the virtualizing vendor plus all the underlying device vendors.
      • In an attempt to remedy this, you start buying all your storage from the vendor that sold you the virtualizing device for a nicely ironic finishing touch.

Use Software-Defined Storage to not be locked into storage or server vendors, and instead buy any server you want. You went whitebox for the lowest price and firmly believe storage arrays are going the way of the dodo.

    • Congratulations, you now are 100% locked into the SDS software. Even if it’s free.
    • You now may lack basic and essential stuff like strong checksums, disk scrubs and several important data management tools.
    • You’ve also made support far harder and massively increased overall risk – for instance, lacking the ability of automating the intelligent upgrading of the firmware of important components.

Use functionality that’s only present in a very specific hypervisor, including all storage services, since you don’t want to be locked into a storage vendor. But at least you bought nice servers that are fully supported by that hypervisor and can allow at least semi-intelligent upgrading of components.

    • Congratulations, you’re now locked really hard into that hypervisor. They are also decidedly not a philanthropy.
    • You now may lack sufficient resiliency and data integrity. Make sure the system can survive the simultaneous failure of any two servers, and that you have enabled data integrity essentials like checksums and scrubs… they may not be enabled by default. Several data services that you’ve long taken for granted may also be lacking.
    • Granular performance and/or capacity upgrades are now beyond your grasp. The result is significant orphan CPU and/or capacity at scale, resulting in infrastructure sprawl and increased costs.

Use a specific cloud offering and go all-in with all the functionality they offer (“serverless” is a good example). You don’t want to be locked into hardware vendors or deal with nonsense such as datacenters. It’s all about elasticity and time to market!

    • Congratulations, now you’re 100% locked into that cloud provider and it will be next to impossible to move to another one or back on-premises.
    • You have to custom-build new applications to take advantage of the special cloud platform features. You also have to ensure your cloud infrastructure can survive various kinds of outages that cloud vendor often experiences.
    • You discover that certain functions are orders of magnitude slower than using on-premises technology – and costs rise to combat this.

And, last but not least: Use a specific storage system family to avoid being locked into backup software, because that storage family has great application integration and could replace backups.

    • Congratulations, the deeper the application integration and customization, the more locked in you are to that storage platform.
    • The platform may not adopt certain trendy technologies as quickly as you’d like (possibly never).
    • It’s actually not a full replacement for real backup software – no catalog, no tape functionality.
Notice a pattern?

You Will Always Be Locked Into Something

The point is that it’s really quite impossible to avoid some sort of lock-in. No matter how benign it may look, the lock-in will be there, one way or another. If you don’t think there is a lock-in, look again, maybe with a different perspective.

It’s more a case of choosing the lock-in wisely.

Realize What You Will be Giving Up – And What You Are Getting Into

I got into more detail on this subject in this article, but in essence, a big reason people are willing to abandon (or embrace) something is simply that they don’t realize the full ramifications of their action.

By moving to this new shiny thing, what are you giving up? Short-term and long-term.

What are you truly getting, and does it overall make better overall long-term business sense than the previous state?

Ignorance is not bliss.

Focus More on Desired Business Outcomes and Less on Tactics and Fashion

  • “Moving to the cloud” isn’t a business outcome. It may be a tactic to achieve an outcome, but in and of itself is not a business outcome.
  • “Going Open Source” isn’t a business outcome.
  • “Going SDS” isn’t a business outcome.
  • “Going all HCI” isn’t a business outcome.

If, for example,  a desired business outcome is increased agility, have you identified which parts need more agility? Where the bottlenecks are? How much more agile you can become by eliminating one or another bottleneck? (Amdahl’s Law holds true even in business).

And what the downsides are, across the business, by going with this or that solution? Long-term?

Choose wisely.

D

One Reply to “Trying to Avoid Lock-In Mostly Leads to Just Different Lock-In – Worry About Business Outcomes Instead”

  1. I’m perceiving conflicting recommendations between this and your previous post (glad to see you’re still posting, though!).

    The exclusive use of a particular solution leads to lock-in and that lock-in can have negative business outcome results in the longer run, even if it seems harmless in the short run. There’s no simple aphorism that can help us decide when to accept a certain amount of lock-in and when to be strenuously wary of lock-in.

Leave a comment for posterity...

This site uses Akismet to reduce spam. Learn how your comment data is processed.