Are We Really Concerned with Public Cloud Vendor Lock-in?

August 22, 2017 1 By Eric Shanks

Recently, I was fortunate enough to attend Cloud Field Day 2, out in Silicon Valley. Cloud Field Day 2 brought a group of industry thought leaders together to speak with companies about their cloud products and stories. I was a little surprised to hear a reoccurring theme from some of the product vendors, which was: customers being so worried about being trapped by a public cloud vendor.

Is It True?

Based on my cloud consulting job, I can say that yes, many times customers are a bit worried about being locked in by a public cloud vendor. But most times this isn’t a crippling fear of being locked in, just a concern that they’d like to mitigate against if possible. But it’s like most things in the industry, you pick a valued partner and move forward with a strategy that makes sense for the business based on the information you know right now and a bet against the future. When virtualization was a new thing, I don’t recall that many conversations about making sure that both vSphere and Hyper-V were both in use in the data center so that lock-in could be prevented. We picked the partner that we saw had the most promise, capabilities, and price and built our solutions on top of those technologies. It’s still like that today, where you’ll pick a hardware vendor and attempt to prevent having multiple vendors because it increases the complexity of your services. You wouldn’t want to hire more people so that you can support two platforms, you’d want to hire the right employees to operate your corporate vision.

Now, with all of that being said, public clouds might be slightly different because the prices can change quickly and a new bill is receive every month. Also, moving off of a service means migrating data and instances much like a data center migration would. So I understand the fear of picking a vendor and pushing forward, but there are benefits of this strategy as well.

What Do I Miss Out On By Not Locking In?

Consider the following things that you might miss out on by not locking in with a single cloud vendor.

  • Price – Many times you can get price drops by adding volume. If you’ve got half of your workloads in a single public cloud vendor and half in another, you’ve got lower volume and may miss out on pricing discounts.
  • Capabilities – Some public cloud vendors have capabilities that others don’t. If you have decided that all of your workloads must be able to live in any cloud, you must only use the lowest common denominator of services. This means you miss out on some of the best stuff public clouds can offer.
  • Operational Simplicity – How do I deploy my workloads across two different cloud providers? Do I need two different processes coupled with two different sets of administrators who are skilled in such tasks? Do I need to have a single cloud management portal such as VMware vRealize Automation, RightScale or ServiceNow to sit in front of my clouds and deploy workloads for me, and if I do that, am I locking in with that vendor?

Wouldn’t it be simpler to do your research and pick a public cloud vendor that you believe will be the best fit for your organization and then spend your time optimizing your environment to work really well with it?

What Did Cloud Field Day 2 Showcase?

During the CFD2 sessions three different vendors pitched the delegates on the value of not-locking in with a single public cloud vendor.

Scality – Scality was promoting the idea that companies really like and want to use object storage based on Amazon’s S3 API which seems to be the defacto standard. But, without a real standard and with the concerns that some companies might want to keep their data on-prem or in Azure, they’ve released their “Zenko” product. Zenko is a solution that provides the S3 interface and lets you put your own storage solutions behind it, giving you the portability of your own S3 object storage.

Platform 9 – Platform 9 was pitching the idea that customers love AWS Lambda but are too afraid of vendor lock-in to really use it. So, they’re introducing a service called “Fission” that will spin up a container on-prem to execute your Lambda-like code. This isn’t the first time Platform 9 has suggested this type of model. Their other product leverages the Openstack API to be the front end for multiple clouds.

Nirmata – Nirmata had a similar pitch which was to have a single platform to orchestrate containers across multiple clouds. This one is a little different in my opinion since orchestrating containers in multiple locations is a great way to provide availability and portability. But again, this is used when Kubernetes could be used on other cloud providers instead of locking in with a product.


What Do You Think?

Mutli-cloud and hybrid cloud is a subject that is often debated but are the trade offs worth the extra complexity? Are you trading a public cloud vendor lock-in for a product vendor lock-in? What is the right method of handling these decisions? I’d love to hear your feedback in the comments.