Cloud application portability remains unrealistic

Cloud portability once seemed like a groundbreaking advancement in the digital infrastructure landscape. Initial expectations were high with the launch of Amazon S3 in 2006 and similar services. Providers promised the ability to migrate workloads across different service providers seamlessly. Oh, what a lovely world it would be.

The services suggested a future where enterprises could effortlessly switch to providers that offered better pricing or enhanced capabilities. Despite the initial excitement surrounding the public cloud model being “as a service” and “on demand,” true portability has proven elusive and costly.

In 2017 I pointed out that cloud application portability was science fiction. Today it is still complex and costly for most of the same reasons. Of course, anything is possible in IT if you accept that money answers every question and if your enterprise is prepared to spend it in great quantities. Few of us have open checkbooks, so the core issue is that cloud-to-cloud application portability takes much more work than many people were promised.

Portability is never easy or cheap

The fundamental challenge lies in the inherent differences between cloud environments. Each cloud provider operates with unique APIs, protocols, and feature sets, creating significant technical barriers to easy platform-to-platform migration. This has led to cloud services being another enterprise vendor option, procured and managed like traditional IT services. As Roy Illsley, Omdia’s chief analyst, points out, both cloud and on-premises environments require different levels of remediation work to adapt workloads to new platforms. These efforts can range from minor adjustments to almost complete rewrites of application code, contingent on operating systems and programming languages. I’m not sure why this is surprising news, but for many migrating to the cloud, it is.

Although transferring applications running within virtual machines might appear manageable, it diminishes some advantages of the cloud, including scaling flexibility. As for cloud-native applications designed specifically for cloud environments, the reality is similarly complex. Despite Kubernetes being a standard framework utilized by major and minor cloud providers, moving applications built on Kubernetes between providers often necessitates addressing variances in configurations and additional plug-ins.

It’s never as easy as those promoting containers and Kubernetes let on. Indeed, I’ve been involved with several container-based development projects after they went off the rails because IT leadership did not understand this obvious fact.

Still worth considering?

Some experts still advocate the pursuit of cloud portability due to its strategic benefits. According to Sid Nag from Gartner Research, having some portability allows organizations to mitigate vendor lock-in risks. However, that can be done better by leveraging negotiating power during contract renewals and safeguarding against potential problems tied to over-reliance on a single provider.

Achieving portability requires careful planning and architectural foresight to minimize dependencies that tether applications to specific cloud services. This usually means taking a least-common-denominator approach: To run everywhere is to run nowhere well. Performance and optimization issues commonly arise, making these “portable” applications too expensive to run—even in the cloud.

The absence of formal cloud standards emphasizes enterprises’ responsibility to ensure compatibility and functionality across different environments. Provider-specific services often drive developers to build applications optimized for unique ecosystems such as AWS or Azure. Data migration adds another layer of complexity. Data portability often involves moving data along with applications, which can be technically challenging and costly.

Right about now, you might ask, “Do you have any good news, Dave?” Please read on.

What can enterprises do?

Enterprises have several choices to minimize the costs associated with the difficulty  of cloud application portability:

Deploy applications across multiple cloud providers. Enterprises can deploy an application across multiple cloud providers to distribute risk and reduce dependency on a single vendor. This strategy also offers leverage when negotiating terms or migrating services. It may prevent vendor lock-in and provide flexibility to optimize costs by leveraging the most cost-effective services available from different providers.

That said, you’d be wrong if you think multicloud is the answer to a lack of portability. You’ll have to attach your application to native features to optimize them for the specific cloud provider. As I’ve said, portability has been derailed, and you don’t have good options. A “multiple providers” approach minimizes the negative impact but does not solve the portability problem.

Build applications with portability in mind. This approach involves containerization technologies, such as Docker, and orchestration platforms, such as Kubernetes. Abstracting applications from the underlying infrastructure ensures they are compatible with multiple environments. Additionally, avoiding proprietary services and opting for open source tools can enhance portability and reduce costs associated with reconfigurations or migrations. Again, most enterprises can’t avoid using the native services needed to allow the container to run efficiently and meet business requirements.

Use effective data management to minimize transition costs. Enterprises should consider structuring their data to facilitate easy movement between clouds while also being mindful of data egress fees. Employing a hybrid cloud or cloud-to-cloud transfer solution can also help maintain seamless data access and reduce associated costs. Businesses can avoid expensive and complicated data migration processes by planning data architecture with portability in mind.

Here’s one piece of advice I often give: Do not consider cloud application portability when building applications. It just adds cost and risk, and most applications will never move from their initial cloud platforms.

I often hear that enterprises want to be able to relocate if the provider goes out of business, becomes unreliable, or raises prices. Those are valid risks, but unlikely. All applications can be moved if enough money is spent. You’ll find that the risk cost of relocation is much less than dealing with cloud application portability.

I took a lot of heat for that article I wrote in 2017. Hopefully by now, those who pushed back will consider themselves educated on the science fiction of application portability. That’s good enough for me.