140 likes | 344 Views
Three Considerations to Prevent Cloud Lock-in. OSCON 2010 Presented by Mark R. Hinkle VP of Community www.zenoss.org mrhinkle@gmail.com Twitter: @mrhinkle. FLOSS Freedoms Prevent Software Lock-In. The freedom to run the program for any purpose.
E N D
Three Considerations to Prevent Cloud Lock-in OSCON 2010 Presented by Mark R. Hinkle VP of Community www.zenoss.org mrhinkle@gmail.com Twitter: @mrhinkle
FLOSS Freedoms Prevent Software Lock-In The freedom to run the program for any purpose. The freedom to study how the program works, and change it to make it do what you wish. The freedom to redistribute copies so you can help your neighbor. The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.
Organizations Dedicated to Ensuring Software Freedom and Standards
FLOSS Freedoms Don’t Exactly Translate to Clouds In the cloud you need the following freedoms to prevent lock-in Freedom to move from Platform to Platform Access to your Data Tools that that work for all clouds or are extensible to support new platforms
Don’t Sacrifice Freedom for Convenience XKCD - http://xkcd.com/743/
Platform Lock-In No globally recognized standard for virtual machines. Machine images can’t migrate seamlessly from VMware to Xen or from Amazon to Rackspace or other cloud providers Open Virtualization Format – Sounds good but not yet standard, or standardized upon Supported by VMware, Citrix Xen, Oracle Virtual Box, Filesystem emulation varies by hypervisor and OVF doesn’t seem to require consistent filesystem emulation specs Ancillary services may or may not exist on other platforms (e.g. Amazon Simple Queue Service (SQS) or Google AppEngine (BigTable)
Data Lock-In Basic Rights Cloud Users Should Consider/Demand No vendor should claim ownership of the data Vendors always shall provide at a minimum an API (most often storage is via traditional block and file interfaces such as iSCSI or NFS) Customers own their data, and the security/privacy of data Ideally, there would be a standard for a data store format or at least an accepted Infrastructure-as-a-Surface (IaaS) API that all vendors support. Paraphrased from The ‘Cloud Computing” Bill of Rights’ 2010 Edition By James Urquharthttp://news.cnet.com/8301-19413_3-20006756-240.html
Tools Lock-In User Tools must provision, configure and monitor all types of cloud infrastructure or at least be extensible to adapt to your cloud infrastructure: If management interfaces and APIs are different they can be the least obvious gotcha (e.g. Messages from Amazon SQS, don’t exist in RackSpace Cloud) Can your build tools address different target architectures? Configuration management tools function seamlessly across clouds Are migrated cloud instances still accessible to monitoring tools?
State of the Union Nascent Industry, things move fast Lots of open APIs, but still no true cloud portability Lots of proposed standards, no standardization Make sure you understand what you are getting into when you choose a cloud provider
Supplemental Reading DMTF Cloud Incubator | http://www.dmtf.org/about/cloud-incubator VMware OVF | http://vmware.mobi/appliances/getting-started/learn/ovf.html DMTF OVF Standard | http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf Ars Technica | EMC's Atmos shutdown shows why cloud lock-in is still scary Zenoss Blog | Three Cloud Lock-in Considerations Storage Networking Industry Association | SNIA: Cloud Storage for Computing Whitepaper Infoworld | Why Open Source Vendors Won’t Prevent Cloud Lock-in National Institute of Standards and Technology (NIST) | Cloud Computing Open Grid Forum Oasis Identity in the Clouds Technical Committee