Why yes, it is a thing as I am writing an article about it. BUT – Is it something that an enterprise should be concerned with, ever?

In my travels of visiting all sectors of industry in 2017 (and prior) from Dallas to Minneapolis, Phoenix to Pittsburg, I would either, 1 – Frequently be asked, “Should we be concerned about Public Cloud lock-in?”, or 2 – Frequently be told, “We’re looking at a multi-cloud approach.”

My blunt response: “Why?”

 

Let’s take a step back and set the context of the majority of these conversations.

  1. Heart of America – Usually 100% on-premises aside from O365 if they are “innovative”
  2. Client is looking at Public Cloud options
  3. Lock-in is the idea that because I’m using proprietary features of a piece of hardware or software, if needed, I won’t be able to move to another similar piece of hardware or software because I now depend on that feature.

Why Cloud Lock-in is clouding your judgment

I’m going to provide a few reasons the enterprise should not be even remotely concerned with “Public Cloud Lock-in.”

  1. The public cloud provides features and services that your ITO and datacenter(s) will never be able to provide, let alone provide at any SLA near what they can provide them at. (Not specific to lock in, but specific to driving revenue, innovating and continuing to build a successful company, which needs to be said.)
  2. Which software do you use as a Hypervisor? I’d guess ESXi. You’re locked in. Are you using vCenter HA, FT or vMotion to help with uptime and alleviate operational issues? Locked in. Are you using SRM for failover? Locked in. vSAN or NSX? Locked in. (In my years of consulting, I still have yet to come across anyone running anything other than ESXi for production workloads. I’m sure they are out there.)How about your main revenue generating application? Running on SAP? Oracle? SQL? Locked in.  I haven’t even started with hardware, and I hope you get the point so I’ll stop there. No one blinks an eye at the level of lock-in that we have in our data centers today yet we go into analysis-paralysis when it comes to the Public Cloud (…because it is the new kid on the block…which leads me to my next point.)

    Analysis-Paralysis Continued
    The public cloud as we know it today has existed in many fashions for over ten(10) years. AWS – 2006. Azure – 2010. GCP – 2011.

  3. These providers have existed for over ten years and thus far, you haven’t taken advantage of them, and now you want your team to onboard more than one? Sounds like an operational nightmare based on the last ten years of culture.
  4. For the last ten years, have you or your company upgraded your storage, compute, backup, software versions, people, processes, governance? Anything? Well, of course, so again, while you’re stuck in this constant cycle of nothing, quit thinking about lock-in, pick one and move.
  5. Lastly – for the vast majority of enterprises, your value is in your data, is in your code, is in your application. The infrastructure running your data, code and/or application should not be of your concern. With that said, you can, today, very easily spin up thousands of EC2 instances in AWS, run your application for a week, spin up thousands of Azure VMs in Azure, run your application there and use DNS to move your application(users) over to Azure. Would I ever recommend this? No, but the point being, the infrastructure on the back end should be transparent. (Don’t forget to break down the Azure VMs once you have completed this experiment.)Is this an evolution of your enterprises’ structure, culture, operational model and day-to-day inner workings? Damn right it is, and there is no better place to start that journey than by picking a  single public cloud vendor and starting as soon as possible.

To summarize, yes you may lock your self into minor features of said public cloud but remember that infrastructure should be completely transparent to the teams deploying their applications, and thus lock-in is not something to be concerned with.