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 Azure AI Foundry tools for changes in AI applications Microsoft’s launch of Azure AI Foundry at Ignite 2024 signals a welcome shift from chatbots to agents and to using AI for business process automation. By Simon Bisson Nov 20, 2024 7 mins Microsoft Azure Generative AI Development Tools analysis Succeeding with observability in the cloud Cloud observability practices are complex—just like the cloud deployments they seek to understand. The insights observability offers make it a challenge worth tackling. By David Linthicum Nov 19, 2024 5 mins Cloud Management Cloud Computing news Akka distributed computing platform adds Java SDK Akka enables development of applications that are primarily event-driven, deployable on Akka’s serverless platform or on AWS, Azure, or GCP cloud instances. By Paul Krill Nov 18, 2024 2 mins Java Scala Serverless Computing 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 Resources Videos