Not to name names, but I’ve been reading in several publications that one of the main reasons to go to multicloud is to avoid vendor lockin. While I can see the logic behind this assumption—that having more cloud providers means you can be more independent—the reality is much different.
For example, if you have an application in the cloud, and you’re using a multicloud architecture, you’ll have two or three choices where to place that application workload and associated data: Amazon Web Services, Microsoft Azure, and/or Google Cloud Platform.
You’ll pick one cloud for that application and do the standard migration processes to get it up and running. What most people don’t understand is that, as part of that migration, you’re likely to make the application workloads cloud-native. That means you’re going to alter the applications, slightly or heavily, to take advantage of the native cloud services, such as API management, governance, security, and storage.
By altering the application to be cloud-native, you’re locking yourself in to that cloud provider, for that application. If you don’t go the cloud-native approach, it’ll be easier to migrate that applocation to a different provider later—but at the price of a suboptimal deployment due to not being cloud-native.
You have to make a trade-off between using advanced application capabilities (cloud-native), and thus also accepting vendor lockin, or keeping the app geberic and less optimal to avoid that lockin. It does not matter if you’re using a single-cloud architecture or a multicloud architecture, the lockin trade-off is the same.
Of course, it is an advantage to have another public cloud connected and integrated into your architecture so that other public cloud options are available if and when needed. But you still have to make that same trade-off between being cloud-native and avoiding lockin.
You might think you can avoid the trade-off by using containers or otherwise writing applications so they are portable. But there is a trade-off there as well. Containers are great, and they do provide cloud-to-cloud portability, but you’ll have to modify most applications to take full advantage of containers. That could be an even bigger cost than going cloud-native. Is it worth the avoided lockin? That’s a question you’ll need to answer for each case.
Moreover, writing applications so they are portable typically leads to the least-common-denominator approach to be able to work with all platforms. And that means that they will not work well everywhere, because they are not cloud-native. I suppose you could write portable applications that are cloud-native to mutiple clouds, but then you’re really writing the application multiple times in advance and just using one instance at a time. That’s really complex and expensive.
Lockin is unavoidable. But lockin is a choice we all must make in several areas: language, tooling, architecture, and, yes, platform. The key is to choose each lockin poont wisely, to mimimize the need to change horses. But when a change must happen, there’ll be a price to be paid. If you make the right choices, you’ll pay that price not very often, and you”ll have gained more from those choices in the meantime than you would have gained from a least-common-denominator approach.
