Does multi-cloud solve for vendor lock-in?
Sort by:
To a degree. There is a downside to having multiple vendors. Take more time to manage both, can lose some discounts, complexity of multiple vendors, etc.
A better way is to create a no lock-in strategy by building an abstraction layer for managing connections into your main cloud provider and then the secondary one(s).
In a word, no.
One has to be cautious about thinking of multi-cloud to address concerns around vendor lock-in. I shared my thoughts on lock-in and the different perspectives four years ago in this post:
https://avoa.com/2016/09/27/is-the-concept-of-enterprise-lock-in-a-red-herring/
Let's look at the options. If you were to use multi-cloud to address vendor lock-in, you would lose buying power (leverage) and have to architect to support each of the providers infrastructures and architectures. Generally that means working toward a common denominator with works against advantages in using any given provider's higher level functions.
Most are using multi-cloud where there is one dominant public cloud provider and then second (and tertiary) providers are used for specific functions. It keeps buying power (leverage) focused on one provider while also allowing the team to focus on the architecture for one provider (primarily).
As you rightly point out, would you run two ERP systems or two email systems? The short answer is no with the exception of migrations. For example, migrating from Netsuite to SAP is as about as much fun as a root canal.<br><br>I'm reminded of a conversation with Meg Whitman many years ago while at eBay; in her view when a company exceeds $1.5B in revenue for distinct product lines, it is possible to treat them as separate entities such as eBay and PayPal. With discrete R&D functions, they have the advantage of picking discrete public cloud providers. Again, Adobe uses AWS for one distinct LOB and Azure for another. Attempting to use multiple cloud providers within a LOB only creates more complexity when it comes to building and operationalizing services.<br><br>All said and done, the key thing is to do your homework on which public cloud provider you intend to use because switching costs will be painful. Introducing two or more public cloud providers into your R&D team will also incur hidden costs well beyond whatever rates you've negotiated.<br><br>Going up the stack, I prefer to think of Cloud apps more like ecosystems from a business functionality persective and less technology. For example, Salesforce may be your CRM cornerstone for your Sales ecosystem and switching costs later on would be painful. However, training modules from third parties that integrate into Salesforce have less of an impact on the ecosystem.<br><br>So in summary, being thoughtful is key as some of these decisions will have a profound impact on your multi-cloud vendor lock-in.
On one level it seems as if we're back to the DB2 wars for those of you that can remember Oracle vs. Sybase vs. Informix, etc. One argument is to only utilize those features that are common to all. The downside is that you don't get to use all the features such as stored procedures that make a particular solution more compelling.
Perhaps it is Mike that mentioned earlier, but I am of the camp to fully leverage your cloud provider to the max should it enable your business to be more competitive.
So the one caveat; if you have distinct lines of business that generate sufficient revenues (let's call it $1B+), then you have the opportunity to leverage two or more cloud providers to the max without negatively impacting your business. Why? You should have sufficient critical mass in R&D for each distinct LOB to master the capabilities of a specific provider. For example, I believe Adobe leverages AWS and Azure without negatively impacting their competitive advantage.
I agree with the comments made in this thread. I'll point out a slight adjustment to the question. Multi-cloud is unlikely in many cases to enable transparent migration of the same workload across cloud providers. This could work for some of the most basic workloads (render-farms, monte-carlo simulations), but generally speaking most apps are 99% but not 100% ignorant of the infrastructure they run on - and that 1% can matter a lot.
HOWEVER
Multi-cloud DOES solve for vendor lock-in on new projects. When your management framework allows you to have some workloads on one cloud provider, and others on a second, when you implement the third - you now have choice. When your environment is fully designed for a single ecosystem, your growth must go to your existing vendor.
In today's world of micro-services, this can be hugely important. I just retained Rackspace as the MSP for Woven - and one of the benefits is that in the future if we build micro-services on Azure (which we may need to), Rackspace has no issue supporting that ecosystem. If I had gone with a GCP only vendor, it would have prevented us from even considering such a move.
(full disclosure - I'm on the Rackspace board, but they definitely earned our business - it was not given to them)
This is a 'it depends' type of question... If you use non-vendor specific APIs/services and/or abstractions like Kubernetes, then yes, multi-cloud can reduce/eliminate vendor lock-in. However, if you do use vendor specific APIs/services, then you lock yourself in. In a multi-cloud environment, keep in mind you will need to ensure your network connections to each of the clouds is commensurate with your expected performance (as an example, think about running a desktop in AWS and accessing Microsoft 365 in Azure). Also, think about the added complexity of having to deal with multiple vendors and the myriad of extra work your team will need to do to maintain the multiple enviornments.