Wikipedia traces the first use of the term “write once, run anywhere” to 1996. A Google search turns up 139,000 occurrences of that phrase. So why is the dream of absolute portability still elusive 20 years after it was first described?
The cloud was supposed to make portability easier. In theory, fully virtual environments should reduce dependence upon underlying hardware, and cloud providers typically offer a choice of platforms and tools. Once an application is in the cloud, it should move anywhere else pretty easily, right?
Unfortunately, no two IT environments are exactly alike and the cloud is no exception. Users may not know this however. When the IDG Enterprise 2014 Cloud Survey asked if switching from one cloud provider to another is more or less difficult than switching from one on-premise provider to another, 29% of IT leaders said it is more difficult, compared to 22% of non-IT leaders. More than 40% of the non-IT leaders said they just didn’t know.
Ignorance isn’t bliss in this case. The reality is that moving between clouds can be very challenging. While cloud providers do all they can to make it simple for customers to move applications to their platforms, they don’t necessarily make it easy to leave. Cloud computing is evolving its own unique brand of vendor lock-in, but there are precautions customers can take to make migration easier.
First, understand that most cloud vendors don’t want customers to have absolute portability because that would reduce their business to a price-sensitive commodity. Even if they did want to make migration easy, they must necessarily make choices that limit customer flexibility. The selection of hypervisors, operating systems, management tools, virtual machines and network configurations each present potential migration gotchas, and no infrastructure as a service (IaaS) provider is going to support them all.
Even fully “open” environments have incompatibilities. For example, network bandwidth provided to virtual machines by one supplier may be different from that of another, which can have a direct impact on performance. Or two providers may use different versions of the same open-source operating system or database, creating unanticipated compatibility issues.
The best way to avoid cloud lock-in is to minimize dependence upon the cloud vendor’s infrastructure. When moving to the cloud for the first time, you can reduce friction by searching for vendors that support a wide variety of platforms (that includes databases, development tools and network management protocols — several versions of each) as well as pure open-source standards like OpenStack.
You can also create new applications on top of a hypervisor whenever possible and use high-level languages to buy you a certain level of insularity from the platforms below. Even better is to write applications using the new breed of containers, such as Docker, which are operating system- and hypervisor-independent. However, for legacy applications that were created for a specific hardware/software environment, you’re going to have some customization to do.
When moving between public cloud providers, test your application in the new environment before shutting off the old one. Make sure the service provider can simulate real-world conditions like transactions and simultaneous user sessions. Most applications run pretty well when there’s only one person using them.
Consider also the amount of data you need to move. If you have hundreds of users or millions of records in your cloud application, it’s going to take time and money to move everything. Can you afford the downtime? That’s also true for software as a service (SaaS) applications, which have the same interoperability limitations as their on-premise counterpart.
Be sure users know that moving to public cloud is not a panacea. It’s great in many ways, but the dream of “write once, run anywhere” is still just that – a dream.