When will we have the ability to move workloads between public cloud providers without major surgery? Not soon Credit: tombud 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 content analysis Strategies to navigate the pitfalls of cloud costs Cloud providers waste a lot of their customers’ cloud dollars, but enterprises can take action. By David Linthicum Nov 15, 2024 6 mins Cloud Architecture Cloud Management Cloud Computing analysis Understanding Hyperlight, Microsoft’s minimal VM manager Microsoft is making its Rust-based, functions-focused VM tool available on Azure at last, ready to help event-driven applications at scale. By Simon Bisson Nov 14, 2024 8 mins Microsoft Azure Rust Serverless Computing how-to Docker tutorial: Get started with Docker volumes Learn the ins, outs, and limits of Docker's native technology for integrating containers with local file systems. By Serdar Yegulalp Nov 13, 2024 8 mins Devops Cloud Computing Software Development news Red Hat OpenShift AI unveils model registry, data drift detection Cloud-based AI and machine learning platform also adds support for Nvidia NIM, AMD GPUs, the vLLM runtime for KServe, KServe Modelcars, and LoRA fine-tuning. By Paul Krill Nov 12, 2024 3 mins Generative AI PaaS Artificial Intelligence Resources Videos