When you think about digital transformation and cloud computing, you think about attributes like scalability, agility and freedom. Words like “lock-in” don’t fit on the list of what makes the cloud so promising. But that’s exactly what is happening with too many organizations as they migrate more and more of their workflows to the cloud.
Vendor lock-in can happen almost without any notice. One day you start reviewing invoices from cloud vendors and you discover that things cost more than you had expected and some contracts have you locked in and committed to some outrageous pricing.
In addition to being held captive for non-competitive pricing, vendor lock-in can leave you more vulnerable to data breaches and cyberattacks. It can also impact your agility and productivity if a cloud provider is failing to live up to the terms of your SLA and you still can’t switch to another provider.
A good way to prevent this lock-in problem from overtaking your cloud infrastructure is to understand how it can happen in the first place. One of the most common paths to lock-in relates to the volume of your data. Many times, organizations will start small, but over time, migrate so much data that’s it’s untenable to make a change. This is sort of a self-imposed lock-in, but it’s every bit as difficult to overcome as an onerous contract.
Another common problem is building cloud apps that are dependent on the capabilities of a specific cloud service provider (CSP). Again, this situation can creep up on you and your teams. You might start with a simple app, but over time, the functionality of the app becomes intertwined with the CSP features and, eventually, you’re stuck. Moving would require starting over and rebuilding the app.
Contracts from CSPs and others can be onerous, as well. For example, you or your teams might learn that one CSP offers a new feature that aligns perfectly with a new app you’re building. However, you can’t take advantage of it because of the termination policies in your current CSP contract. This can lead to long, unacceptable delays in your development schedule.
So, how do you avoid the costly problem of vendor lock-in? How do you keep moving fast, yet protect your enterprise and your teams from having their cloud efficiency and agility limited? Here are four strategies worth considering:
1. Be intentional about a multi-cloud strategy
Chances are that you’re already on this path — but it might not be entirely planned. The idea here is to be sure to use offerings from at least two CSPs. This may seem like an obvious way to mitigate the possibility of lock-in, but it can still happen in a multi-cloud environment. The key is to develop a plan that tries to predict the needs of each work group or department and do your best to line deploy them the most aligned public cloud environment. Taking a planned approach also allows you to make ongoing decisions based on price, features, security, resilience and infrastructure components.
2. Think Portability
It’s tempting — especially when the pressure is on to deliver — to commit quickly to a cloud platform that offers some features or functionality that accelerates your development process. But those advantage might be short-lived. It’s possible, and even likely, that another CSP will offer even more helpful features and functionality in the future. You don’t want to be stuck. To avoid it, build portability into your cloud-based apps by making sure they’re only loosely coupled with the features and components. Also, ask your dev team to try and avoid building apps that are dependent on the proprietary features of a particular CSP. You’ll likely get push-back on this and it might not always be possible — but it’s an important thing to consider at the front end of the development process.
3. Negotiate favorable terminations
Most negotiations with vendors focus on the positive aspects of the relationship. It’s hard to imagine when you’re being courted by a sales rep that the company they represent could ever take on an adversarial posture. But it’s important to think that far ahead and negotiate an exit strategy during the buying process. It’s important to get clarity on your contract around required notice for termination and the particulars of migrating apps and data in the event you choose another CSP. Also, pay close attention to language regarding automatic renewals of service agreements. It might be a good idea to even have the hard (but fair) conversation with your sales rep that starts with, “What happens if we want to move to another provider?”
4. Consider hybrid cloud options
A multi-cloud infrastructure, by definition, is the use of more than one CSP. While using multiple providers helps guard against vendor lock-in, it’s far from a guarantee. Exploring the use of private cloud, edge computing and the retention of some on-prem assets is a way to create a more flexible, scalable and versatile infrastructure. This approach can be particularly helpful for ensuring that you own your data. Every CSP operates under its own laws and contractual terms. It’s important to understand those intimately. It may be safest of all to store your most proprietary data on your own private cloud. It’s important to pay attention to contract terms with your cloud vendor and to understand the laws under which they operate. You may want to protect more sensitive data by storing it in a private cloud or an on-prem data center.
There are other ways to avoid the problem of vendor lock-in — such as asking your IT team, engineers and developers to develop agnostic cloud expertise that spans all CSP offerings. In general, however, the key is thinking ahead and developing a strategy that’s mindful of the day you find yourself leaving a particular CSP. The natural approach is to find the features and components that solve your immediate development problems. Sometimes, that can’t or shouldn’t be avoided. But in most cases, a solid long-term plan that incorporates the four strategies outlined here can keep you on a good digital path moving forward.
