The truth about lock-in and cloud computing

You can't get both distinct features and portability across cloud platforms -- just as you can't with on-premise platforms

Much of the static around cloud computing has come from the notion of portability, or the ability to move data and code from one cloud to another or back to the enterprise. Word on the street is that the emerging cloud computing platforms are "proprietary," thus portability, and in many cases interoperability, is going to be an issue. However, the core issue is a trade-off of features versus portability.

The portability concern is sound. Chances are that if you write an application on one of the existing cloud platform providers (such as Amazon Web Services or Google App Engine), moving that application to other cloud platforms or perhaps to an enterprise server is going to be a pain in the neck. There are just too many differences between the cloud platform providers, so many rewrites of code and reworking of data will have to be on your to-do list.

[ Get the no-nonsense explanations and advice you need to take real advantage of cloud computing in the InfoWorld editors' 21-page Cloud Computing Deep Dive PDF special report. | Stay up on the cloud with InfoWorld's Cloud Computing Report newsletter. ]

In the world of cloud infrastructure providers such as, Microsoft, GoGrid, 3Tera, and Mosso, to name a few, things are a bit different. Why? Because these providers are in essence using traditional technology "platforms," such as IBM and the LAMP stack. Thus, moving code and data should be much less daunting.

Core to the portability issue, however, is the trade-off between leveraging the native features of the cloud provider that makes the code and data less portable, or writing portable code, which means that your application is not leveraging native features. Which is better?

We've been down this road before. In the days of client platform interoperability, when OS/2, Windows, and many Unix flavors roamed the earth, we played around with portable development environments that allowed you to "write once, deploy anywhere." However, we quickly learned that these technologies meant not doing any particular platform well, and the applications were slow and feature-poor. Developers typically picked a platform and layered deep into the OS to make their applications shine.

The whole provider profit motive is there too. Why support portability if that means your users can't leverage the unique features of your cloud computing platform? Also, it allows customers to easily move to other providers. A vendor may outwardly state that support for portability is strategic, but the reality is that in each release, new features -- such as APIs their customers are screaming for -- are not at all portable. It's a dance that software vendors have played for years, and cloud computing providers are no different.

We are going to quickly find that even with core portability standards for the cloud computing platforms, including coding and data standards, portability will always be a trade-off. It's between leveraging native features that make your cloud-based applications be the best that they can possibly be on that particular platform versus focusing on portability. Unfortunately, as it stands now, you can't have it both ways.

Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform