The elusive dream of cloud portability: Why migrating workloads isn't so simple

Analysis One of the promises of the public cloud was that customers would be able to migrate workloads if they wished, taking advantage of market freedom to switch to a different provider if it offered lower costs or some other advantage. What happened to that dream?

Cloud services are nearly 20 years old, if the launch of Amazon S3 in 2006 is considered as the start of the cloud era. But despite all the early hype about the model being "as-a-service" and "on-demand," the reality is that cloud has become just another vendor channel for most enterprises, procured and managed in the same way.

Shifting a workload from one provider to another might be a straightforward task if all the clouds were the same. The problem is that they aren't, and there are various barriers to actually changing provider, as the UK's Competition and Markets Authority (CMA) has been finding during its investigation of the marketplace.

There are differences in APIs and protocols between clouds, not to mention features in the services on offer by the various providers, to name just a few of the technical barriers to portability.

"The idea of workload portability is a topic that has been the nirvana for enterprise organizations for years. The ability to move any workload to the cheapest, most secure, fastest environment at will," Omdia chief analyst Roy Illsley told The Register.

"However, in cloud, just like on-premises, the environments have some fundamental differences that require remediation work to be performed, depending on multiple factors such as the operating system, programming language etc. and they range from minor to almost complete rewrites of the code," he added.

If you are just dealing in applications running inside virtual machines, moving these is perhaps a little easier, barring details like having to make changes to their networking connections with the outside world. But working like this is perhaps losing some of the promised benefits of moving to the cloud, such as ease of scaling.

How about so-called cloud-native approaches to building applications, which by their very name are designed for running in a cloud environment? This often simply means that code is deployed in containers managed by Kubernetes, the software framework for operating a whole bunch of them, originally developed by Google.

There are Kubernetes services operated by all the major cloud providers, and also indeed smaller players like Civo that focus purely on that. So it should be easy to move one application built for Kubernetes from one cloud to another, right? Sadly, it's not so simple as there are still differences between the services, with different plugins and extensions to be taken care of.

"Cloud-native, and Kubernetes in particular, was supposed to eliminate these differences, and for the most part it does. However, even here the configuration and implementation differs by environment, so workloads are more portable, but often they still require some configuration changes," Illsley said.

This was highlighted in an article from McKinsey Digital, where the authors tested migrating a workload between different Kubernetes services. They concluded that Kubernetes isn't a silver bullet for portability, as there are add-ons or services that need to installed and managed to ensure the application is deployed and configured as it is supposed to be.

So is there any point in even trying for cloud portability? Yes, according to Sid Nag, VP for Cloud, Edge, and AI Services and Technologies at Gartner Research.

Having at least some ability to move cloud provider is important to reduce the risk of vendor lock-in, can give some sway when renegotiating contracts, but most importantly, things can go badly wrong for an organization heavily invested in a single provider, Nag told us. Just ask Aussie superannuation fund UniSuper, which found its entire online account had been deleted by Google not long ago.

According to Nag, it is possible to build applications with the aim of making portability as easy as possible, but doing so means putting a lot more effort into upfront planning and architecting of the application, and being careful about dependencies that might tie your code to specific services. Doing so might even be considered good development practice, however.

• Google, Oracle, Microsoft make their case for VMware migrations – HPE on the outer?
• Apple, Google ease cross-cloud data transfers, perhaps with costly catch
• UK CMA early findings indicate Microsoft restricts cloud choice
• VMware by Broadcom has a licensing portability win with Microsoft

"In the world of cloud, there are no standards bodies," Nag said. "There's the IEEE for networking, so when Cisco or Juniper build a switch, it has to work to those standards, but there's no such thing in the cloud and responsibility falls on the customer to ensure their applications work."

Kubernetes is theoretically a standard, but Nag observes: "Every cloud provider builds their own service around it, and the devil is in the details."

When it comes to services, one of the selling points the big cloud players boast about is the number and range of services they have. Many developers expressly picked AWS as the cloud to build their applications on because it has the broadest range of services available, while Azure has services targeting Microsoft users such as Azure Active Directory.

So the dilemma is whether to make the best use of the specific facilities available on a particular cloud platform, or to write applications that only make use of the generic services that are common across clouds - at least the major ones.

"The question of will we ever get seamless workload portability for me is still a bit of a dream, because in complex environments, the interaction between all the different components/layers must be compatible across all possible combinations, and is that likely?" asks Illsley.

"Workloads are more portable with less effort now than they were in the past, but what about the data? If you move the workload do you also need to move the data?"

That's another question of course, because your data could be in an S3 object storage bucket on AWS or it might be filed away in a database service hosted by whoever your current cloud provider might be. How easy is that data to exfiltrate, or more importantly how much would it cost to do so, compared with accessing it where it is?

This brings us back to the UK CMA, and its investigation into whether such things as egress fees are inhibiting customers from moving easily from one cloud to another. We await its conclusions with interest. ®