I read Barb Darrow’s article about the Robert Scoble open letter with much interest. Apparently, the letter revitalized the old discussion about cloud APIs: which ones to support? Scoble’s letter was a response to that of Cloudscaling’s Randy Bias whose note to the OpenStack management suggested they work on building in API compatibility with Amazon’s Web Service stack.

Interestingly enough, this discussion comes just a few weeks after a webinar I hosted with Forrester’s Henry Baltazar. In the webinar we discuss the pros and cons of renting storage in the cloud (think S3) vs. building an in-house storage cloud solution using open source technology and commodity hardware (SWIFT), or buying a fully integrated solution like DDN WOS (Web Object Scaler). Obviously, our discussion is restricted to the storage part of the story, but the arguments aren’t that different for compute.

Robert and Randy seem to be having the Rent vs. Build discussion over APIs, but to me the API is just an API. The API is just the steering wheel, for lack of a better analogy. What really matters is the engine, the fuel and the design. Those elements contribute to speed, performance, security, usability and efficiency. And, that is exactly where the difference is made, both for compute and storage clouds.

When we were designing our WOS object storage platform, we decided to put our energy into providing a scalable, cost-efficient, easy to deploy and manage and hyper-fast platform. We designed a 100 percent pure object platform, with no file system layers in the architecture since you don’t need that for immutable data and it just adds to the complexity and limits scalability, anyway. We built in a choice of data protection schemes and we made the system latency-aware. The result is a storage cloud platform that is many times faster than anything currently available, and also a helluva lot cheaper from a TCO point of view.

WOS is being deployed by the largest cloud and web application providers today in spite of its native API seemingly being a lot less “feature rich” than the S3 or the SWIFT APIs. They say it’s simpler and what really matters to these customers is the high throughput/high IOPS performance that the platform provides them.

That said, it’s DDN’s objective to be the most versatile object storage platform on the market, so we will continue to add new and popular APIs to the long list of already supported interfaces, gateways and applications. One year ago, it was a logical decision to support S3 for customers who decided to move to a faster and more cost-efficient, in-house object storage platform. Now, support for OpenStack SWIFT is also in the works.

So, going back to the discussion, there are a few questions to ask: should OpenStack move to the Amazon API and why? One argument I read is that the OpenStack API has too much of a Rackspace flavor.  Still, I don’t really see how choosing the Amazon API would fix that. Could the Amazon API become the one and only standard? From an adoption standpoint, probably; although, definitely not from an openness point of view.

With what we learned this week, I’m not sure how “open” the open source community really is. It looks like the only way to provide openness to (storage) cloud platforms is to support multiple APIs. Ironically, it is not the open source community, but instead companies like DDN, vendors of so-called proprietary technologies, that are in fact taking the lead in building platforms that give customers an open choice of APIs.

What do you think? What really defines open today, and is this a dog eat dog world and is there room for more?

  • DDN Storage
  • DDN Storage
  • Date: August 2, 2013