The specter of vendor lock-in by cloud service providers is clear as the driven snow: modified programming languages, proprietary API's and non-portable cloud services.
A recent speech by Vinton Cerf:
“…Each cloud is a system unto itself. There is no way to express the idea of exchanging information between distinct computing clouds because there is no way to express the idea of “another cloud.” Nor is there any way to describe the information that is to be exchanged. Moreover, if the information contained in one computing cloud is protected from access by any but authorized users, there is no way to express how that protection is provided and how information about it should be propagated to another cloud when the data is transferred.” – from a recent speech by Vinton Cerf
Cleanly extracting oneself from the clutches of a cloud service provider varies in pain. User lock-in is more of a compelling force as application functionality, code idioms, APIs, and aspects of the information system start to increasingly depend on Cloud provider specific services, such as transaction management , non-standard messaging and proprietary storage data formats.
Exit strategies will depend on the type of cloud service provider, and the underlying technologies used to provide those services. For infrastructure clouds, application code and configurations are self-provided; these applications are the property of the consumer. In some IaaS implementations, virtual machine portability provides migration of running application loads from Cloud provider to internal resources or to another Cloud provider.
The question of application portability becomes murkier as PaaS or SaaS offerings are used. In these cases, the cloud service provides the application’s basic architectural framework, which is usually tightly coupled to the underlying technical and operations infrastructure. De-coupling those applications is a difficult proposition, and may not be possible given intellectual property considerations. Its going to be tough to imagine these vendors agreeing on exposing thier black-box software generator with a standard programming model and interface. It will be important to consider data and process portability when utilizing PaaS and SaaS providers, and to allow for re-platforming or re-hosting if a transition is needed.
The steps to reclaim a system that has been designed, coded, tested and deployed using one or more cloud services will depend on where you plant your system components.
Here are some things to keep in mind as you seek a flexible relationship:
- Typically, Cloud providers do not own Intellectual Property for artifacts developed or hosted within their IaaS platform; however, clear delineation of ownership is required to avoid potential future litigation.
- Cloud services, by definition, should be loosely coupled
- To reduce vendor dependency explore a hybrid approach whereby internal and external resources are implemented to fulfill a business requirement for mission critical or even secondary applications
- Encapsulate provider specific integration points into core management and provisioning systems to isolate changes introduced by altering the sourcing model
- Deploy run-time applications in a manner abstracted from underlying infrastructure and machine image
- Build custom, standards based images capable of running on variety of standard platforms
- Backups should also be machine independent
- Carefully design application architecture and development techniques to minimize
- Compliance to government mandates is not portable and neither are System certifications
- Promote open standards
- Put together a transition migration plan and test your cloud migration theories ...
