By Apratim Ghosh
12th February, 2019
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 lock-in. 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.
In this 60-second video, learn how the cloud-native approach is changing the way enterprises structure their technologies, from Craig McLuckie, founder and CEO of Heptio, and one of the inventors of open-source system Kubernetes.
IT INSIGHTS
What is the cloud-native approach?
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 multiple 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
