How Much Should Enterprises Worry About Vendor Lock-in in Public Cloud?

One of the key drivers to a multi-cloud strategy is the fear of vendor lock-in. “Vendor lock-in” means that a customer is dependent on a particular vendor for products and services, and unable to use another vendor without substantial switching costs or operational impact. The vendor lock-in problem in cloud computing is the situation where customers are dependent (i.e. locked-in) on a single cloud service provider (CSP) technology implementation and cannot easily move to a different vendor without substantial costs or technical incompatibilities.

Vendor Lock-in: Public Cloud vs. Traditional Infrastructure

Before the cloud, IT was running in dedicated on-premises environments, requiring long-term capital investments and an array of software license commitments and never ending hardware refresh contracts. Based on that experience, it is understandable that a customer would be concerned about lock-in. Many large IT vendors like Oracle, IBM, HP, and Cisco would “lock” customers into 3–5–10 year Enterprise License Agreements (ELAs) or All You Can Eat (AYCE) hardware and software license agreements, promising huge discounts and greater buying power — but only for their products, of course. I used to sell these multi-year contracts. There is a common ground for sure, as the customer was locked-in to the vendor for years. But that was then and this is now. Is vendor lock-in really a concern for public cloud users?

Isn’t the point of cloud to provide organizations the agility to speed innovation and save costs by quickly scaling their infrastructure up and down? I mean, we get it — your servers, data, networking, user management, and much more are in the hands of one company, so the dependence on your CSP is huge. And if something goes wrong, it can be very detrimental to your business — your IT is in the cloud, and if you’re like us, your entire business is developed, built and run in the cloud. Most likely, some or all of your organization’s IT infrastructure where you are developing, building and running applications to power your business and generate revenue, is now off-premise, in the cloud. But although “lock-in” sounds scary, you are not stuck in the same way that you were with traditional hardware and software purchases.

Can You Really Get “Locked In” to Public Cloud?

Let’s talk about the realities of today’s public cloud-based world. Here are a couple of reasons why vendor lock-in isn’t as widespread a problem as you might think:

• No Long-Term Commitments: Customers can adopt the cloud on their own terms. AWS, Azure, and Google Clouds are designed so customers only use the services when they see value, and they are free to use the technology of their choice. Pay-as-you-go pricing provides customers with the ability to shut down their environment, export their data and virtual machines (VMs), and walk away without ever incurring another expense. Customers are billed monthly without any required long-term commitments or contracts regardless of spend or support tier.
• Customer Choice: Today’s cloud customers have alternatives to proprietary tools with advances in open source software technologies, along with a range of ‘as-a-service’ capabilities that can remake traditional IT — IaaS, PaaS, and even SaaS. A wide range of solutions that support industry standards allow customers to choose what they want to invest in and architect for application portability from the beginning, if they so choose.
• Moving Into and Out of a CSP: Generally speaking, cloud services are built to support both migration into and out of their platforms, and CSPs and the industry at large provide many tools and documented techniques to make it easy to do both. Many cloud service providers offer tools to help move data between networks and technology partners. Customers can securely move information in and out of the cloud regardless of where that information is going: cloud-to-cloud or cloud-to-data center.

How to Mitigate Risk with a Multi-Cloud Strategy

Now the cloud is not without risk, and when we talk to customers the primary vendor lock-in concerns we hear are related to moving to another cloud service provider IF something goes awry. You hope that this never has to happen, but it’s a possibility. The general risks include:

1. Data transfer risk — it is not easy to move your data from CSP to another.
2. Application transfer risk — If you build an application on one CSP that leverages many of its offerings, the reconfiguration of this application to run natively on another provider can be an extremely expensive and difficult process
3. Infrastructure transfer risk — Every major CSP does things a little bit differently.
4. Human knowledge risk — simply put, AWS is not the same as Azure which is not the same as GCP, and your IT team has likely gained a lot of institutional knowledge about that provider’s tools and configurations.

To minimize the risk of vendor lock-in, your applications should be built or migrated to be as flexible and loosely coupled as possible. Cloud application components should be loosely linked with the application components that interact with them. And, adopt a multi-cloud strategy.

How Much Should You Worry About Vendor Lock-In?

Many companies are familiar with vendor lock-in from dealing with traditional enterprise companies mentioned above — you begin to use a service only to realize too late what the terms of that relationship brings with it in regards to cost and additional features and services. The same is not entirely true with selecting a cloud service provider like AWS, Azure, or Google Cloud. It’s difficult to avoid some form of dependence as you use the new capabilities and native tools of a given cloud platform. In our own case, we use AWS and we can’t just wake up tomorrow and use Azure or Google Cloud. However, it’s quite possible to set your business up to maintain enough freedom and mitigate risk, so you can feel good about your flexibility.

So how much should enterprises worry about vendor lock-in in public cloud? IMHO: they shouldn’t.

Originally published at www.parkmycloud.com on September 3, 2019.