I'm interested to get perspectives on Cloud platform and software 'lock in'. How do IT leaders view this balance. I find that 'lock in' is perceived as 'bad' and that platform transportability is more important. However I believe 'lock in' can also be viewed as investment into unique capabilities of the Cloud platform or software you purchase, which aren't easily found elsewhere. When choosing to invest in a Cloud platform and software how do you evaluate the pro's and con's of Lock In?
Sort By:
Oldest
Director of IT in Healthcare and Biotech8 months ago
I agree with , after all how many of us are locked in to not just Java, but also Microsoft Windows, Cisco network equipment, Oracle databases, GPU providers, long term consulting or network circuit contracts - but no one ever mentions these. But one is never locked-in, you can always switch technology or providers, then the question really becomes what are the switching costs. Then you have to decide do you 1) want to invent in "switching ahead of time" (aka architect to be cloud agnostic) or 2) save the money and switch later if needed? If you pick a bad cloud provider then you may wish you went for option #1, but if you select a good provider then you'll save *lots* of money (and performance) by going with option #2. A few other considerations:
1) Skillsets - Multi-cloud is *hard*. Very few company have expertise in a single cloud, let alone all three major cloud providers. You would have to hire more staff than you otherwise have to.
2) Maintenance - specific services are often listed as key lock in use cases (e.g. AWS Lambda, GCP Bigquery, Azure AD...) but to avoid using them you would have to spin up VMs and run the services yourself. This is just onprem moved to someone else's datacenter and you lose out on big benefits of cloud (the automation/managed services) - you end up doing all the maintenance work that you hoped to avoid.
3) Performance - Each cloud provider has features that are unique to them, this often extends down to specific settings. By abstracting to a higher level you wouldn't use these and will miss out on the benefits. And making an application multi-cloud can be horrifically bad as network latency between provider datacenters will limit data movement.
4) Cost - Each of the big cloud providers have volume discounts, by spreading usage thinly across the providers you can easily miss out on significant savings. Also the major providers also have charges for data egress, so data movement between cloud may become significant.
At my previous employer we had a developer team strive for cloud agnosticism, they had a translation layer for data and API calls, and they supported all the clouds (and oddly enough they became the source of lock-in). And it worked, but at a cost of money, time, and performance. No enterprise translation layer can scale to AWS/GCP/Azure size nor hyperscaler speed (they're coming out with new services all the time). So even though the solution created by the dev team worked, it was slow and couldn't scale, gathering many customer complaints. Ultimately they re-architected specifically for one provider, it's been 3-4 years and everyone's been happy since.
My recommendation: take your time and select a primary provider that's best for your entire organization - security, infrastructure, development, support, business all *need* to part of the process. Don't let the marketing gimmicks or short term credits sway you, this is a big decision that you have to live with a long time.
Chief Technology Officer in Services (non-Government)8 months ago
Interesting comments, i like the point around the miss of volume discounts if you're spreading your cloud credits thinly. I also do wonder if teams like the 'intellectual challenge' of being agnostic, i.e. it's harder to build something that is transportable, therefore more satisfying to accomplish.
For instance, we've selected 25 years ago to develop in Java. We're kind of locked-in by this decision.
All the applications we've built throughout the years made the organization locked-in by the IT department.
So at the end, there's no such things as 'transportability' except for low-level elements such as servers including cloud hosting. But for software, the minute you start integration a solution to your ecosystem, you slowly become 'locked-in' somewhat.
But how often will you really switch to another solution? Hard to predict but chances are low.
We've been juggling for a few years about this. Some say that selecting multiple vendors in our landscape will prevent from this. But we end up integrating many softwares for nothing when 1 vendor could have provided 3 functionalities for example.