Preventing Vendor Lock-In as You Migrate to the Cloud

�Insanity is when you keep doing the same things expecting different results,� wrote Rita Mae Brown. In a similar vein, in The Life of Reason, George Santanyana (1863�1952) famously wrote, �Those who cannot remember the past are condemned to repeat it.� While IT has been battling lock-in since the earliest days of computing, not too much attention has been paid to this problem as IT rushes to madly to embrace the cloud.

To prevent being locked in to a single vendor, you need to ensure that the architecture you have selected can run on multiple clouds, and that the data can be easily migrated from Cloud A to Cloud B. While that sounds trite and simple, it�s still true. And in theory, it�s not hard. But as usual, God (or the Devil; take your pick) is in the details. Totally new development without any use of legacy code is the easy case, but it is not so common; we all carry around the accumulated baggage of the past. However, should you be fortunate enough to have this luxury, I would suggest developing on Eucalyptus or OpenStack, a new open source effort led by Rackspace and NASA, and using one or more of the most favored languages for cloud development, namely C++, Java, or Python, or PHP for less-demanding applications. This approach gives you the greatest choice of providers. Eucalyptus runs under VMware, is compatible with AWS, supports Windows Virtual Machines (in Eucalyptus Enterprise Edition 2.0), and is supported by many, if not most, of the cloud service vendors. In addition to Linux images, Eucalyptus EE 2.0 customers can now deploy images running on Windows Server 2003 and 2008 and Windows 7, along with an installed application stack in a Eucalyptus private cloud environment.

OpenStack, currently built with the Ubuntu Linux distribution and using the KVM virtualization hypervisor, is compatible with Amazon�s AWS and is expected to run directly on Linux as well as be compatible with VMware, Xen or Hyper-V. However, if, like most enterprises, you need to deal with an accumulation of legacy applications, then it is obviously important to understand what the accumulated inventory of platforms and languages consists of, and to determine whether source code is available or has been partially or totally lost (this happens much more than one might imagine).

Next, you need to determine whether to use this as the opportunity to recode or to just make the existing applications work in cloud. If you are recoding, then the previous advice holds. If not, vendor choices for migrating applications to the cloud will be dictated (and limited) by several constraints:

� Does the vendor support the operating system(s) and programming languages that you require?

� Which database management systems are required? Is there a vendor-maintained �image� that supports your DBMS?

� How much memory and processing power is required? Does the vendor provide sufficiently powerful machines, and is there room to grow?

� Do you choose a private, public, or hybrid cloud? What impels your decision?

� Do the management tools you have in place support management in the cloud? Are there upgrades available?

� How rapidly do your needs change, and can your vendor provision and deprovision fast enough?

� Does the vendor�s service level agreement (SLA) meet your needs?

� Is your auditor satisfied with the vendor�s documentation of its compliance with SAS 70 and ISO 27001? Is SysTrust certification available?

Source of Information : Implementing and Developing Cloud Computing Applications 2011