What We Mean When We Talk About the Open Cloud

There’s been lots of commentary in the last few days about IBM’s open cloud manifesto. Microsoft hates it, and Amazon thinks it’s too early for standards. Others just wonder what the big deal is since the actual “manifesto” seems very motherhood and apple pie-like.

Engine Yard has signed on to be a supporter of the manifesto, and we wanted to explain our take on the future of cloud standards.

1. We’re a practical company. Engine Yard Solo is the first Rails cloud on the market and we use AWS as our cloud provider. We intend to add other cloud providers in the future, and selfishly, we would like to be able to change a couple of configuration parameters, and have that happen with minimal fuss.

Today, Solo’s provisioning code is tightly bound to AWS’s way of doing things, and we use Amazon S3 API’s for backup and restore. We would love all cloud providers to offer a standard API (or protocol) so that we could write provisioning and storage code ONCE and then run it on AWS, GoGrid, Azure, etc. We would like these API or protocol standards to be managed by an open process with contribution and input from working software developers.

Our favorite standards body is the IETF because of the emphasis on de facto working interoperability, and the core principle that the people who have to suffer the consequences of a standard (aka software developers and network engineers) get to define, socialize and popularize it. Our observation is that semi-closed, vendor driven, or simply inappropriately staffed standards initiatives are suboptimal. In the interest of not hurting feelings, we will not mention specific names, although it rhymes with Schmibre Schmannel.

In the cloud standards space, we like the cut of the Open Cloud Computing Consortium so far — although its support list is sparse.

1. Engine Yard is committed to open source and open standards. How you write your applications and what services you choose to use should not put you in a box in terms of your freedom of choice for un-related services. Writing applications that use proprietary cloud provider API’s is basically a return to the mainframe; you had to buy your hardware and software bundled together, and commit to purchasing maintenance, support and upgrades on that infrastructure until the last user of that application retired or died. API lockin is the oldest game in the software strategy playbook, and most LAMP software developers are justifiably leery of depending on services with high lock-in like BigTable, SQS or SimpleDB.

2. If we had written the Open Cloud Manifesto, we would have put different emphasis on different areas of the document, and worded things a bit differently, but it’s a good place to start. For example, we think that security, and governance are minor, not major issues. We also think that standard metering and monitoring formats are nice to haves—particularly since SNMP already provides a well-baked (if much abused) monitoring standard.

In addition, we agree that “cloud providers must use and adopt existing standards wherever appropriate,” but we’d probably argue that many of the existing standards are not appropriate. In particular, a lot of WS* standards should probably be sealed in concrete and stored in Yucca mountain for the preservation of public safety, in favor of RESTful approaches.