Cloud portability is still science fiction
Enterprises want cloud portability. Why? Well, they want to hedge bets in case a public cloud provider “breaks bad” in terms of consistently poor service, or performance issues, or, more likely, jacking up the subscription fees to obnoxious levels.
As many CIOs I have talked to put it: “We need to have choices. Choices mean leverage.” I get that.
However, to have true choices, the workloads, including applications and data, need to be easily moveable from public cloud to public cloud. This means that the code will move, the data will move, and it’s a matter of recompiling, configuring, and testing on the new cloud platform.
However, it’s never that easy. Indeed, if you’ve ported applications and data to public clouds you’ve had to refactor them to leverage some cloud-native features. These include spinning up native compute and storage servers, leveraging native security and governance, etc. It’s impractical not to leverage these native-cloud services to support your applications, else you pay way more for the workload in terms of cloud service consumption or not meeting the requirements of the business, such as security.
Being cloud native is good. However, it also greatly limits portability. Those cloud-native services on one public cloud must be written in new cloud-native services on another public cloud. They are not compatible, and although everything is portable if you have enough time and money, these workloads would not be considered “pragmatically portable.”
Of course, many enterprises believe that new technology will save us, namely containers and serverless computing. Although serverless computing is great for net-new applications, meaning we’ve designed them from the ground up for a serverless architecture, there will be little hope for public cloud portability here. After all, the public cloud providers have their own cloud-native serverless capabilities, and those are mostly unique to each public cloud.
Containers have more promise, but it takes a great deal of work to shove old workloads into new containers. Again, the benefit of containers is mostly around net-new applications. You can “containerize” most applications, and, indeed, they would be easily ported from one cloud to another, but the amount of work and money needed would typically prohibit many enterprises from moving in that direction for most existing applications.
So, is practical cloud portability still science fiction? For all practical purposes, it is for now. Sorry.
Related Alrticles