Three Considerations to Prevent Cloud Lock-in

Creative Commons Attribution-ShareAlike 3.0OSCON 20101

OSCON 2010

Presented by Mark R. Hinkle

VP of Community

www.zenoss.org

[email protected]

Twitter: @mrhinkle

Three Considerations to Prevent Cloud Lock-in


FLOSS Freedoms Prevent Software Lock-In

1. The freedom to run the program for any purpose.

2. The freedom to study how the program works, and change it to make it do what you wish.

3. The freedom to redistribute copies so you can help your neighbor.

4. 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

1.Freedom to move from Platform to Platform

2.Access to your Data

3.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/


Organizations Dedicated to Cloud Freedoms


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 EditionBy 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


Once You’re Locked In, Getting Out Can get Messy


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

Documents

Three Considerations to Prevent Cloud Lock-in