August 2009 Archives

When we posted our ParaScale Fact Check blog post earlier, it was specifically oriented to a situation where there were specific, unsupported claims by ParaScale. 

A fact check should be based on facts, not marketing claims or opinions.

The claim that ParaScale offers Web services APIs, among other claims, initiated our response.  Now, ParaScale not only does not have them, but claims that you should not use them, unless and until there are S3 APIs.  Furthermore, they have now initiated a Mezeo fact check.  Except they are making marketing claims, they do not, nor can they offer "facts" that are claims by Mezeo that are not in fact true.

Here are their claims and our responses:

Mezeo does not give you the storage economics to compete with Amazon.

Mezeo response:  ask our many customer references in the hosting industry, they are competing and winning against Amazon.  By the way, we came from the hosting industry, and we know how much it costs to host storage. They don't state a fact, this is their opinion, and it is unsupported by facts.

Mezeo is not adaptable to your customer's data access needs of standard protocols.

Mezeo response:  We have offered WebDAV support since Q1 of this year, our Windows Native client has been available since we launched our company, as well as REST APIs.  CIFS and NFS are easily with the scope of our capabilities, and we will be advising our customers and prospects of our plans in this area. It is unclear to me that this demonstrates a "lack of adaptability".

It is simply proprietary REST API with custom clients. 
Mezeo response:  This is not a fact.  In fact, we now have to fact check ParaScale again.  The Mezeo platform offers significant, extensible services that go beyond those on competitive public cloud offerings.  These include secure sharing, public sharing, collaboration, tagging, notifications, permissions, and numerous other services that make Mezeo a desired platform for Web developers.  Our SPML based provisioning integration; APIs for billing and bandwidth utilization, and Acceptable Use Management further differentiate the offering.  Many consider our ability to accommodate both industry standard file systems and clustered file systems (like ParaScale, for example) for the storage target of a Mezeo based cloud as an advantage.  You can mix and match storage offerings in a Mezeo cloud to achieve different offerings of price, performance and availability, all on a single infrastructure.  Finally, access, via APIs, WebDAV and our white label clients are a critical differentiator, and we deliver all of this today!

PROPRIETARY REST API:  With an understanding of REST and APIs, you understand that this is not the critical issue.  The critical issue is that Web developers want to develop against platforms that offer REST APIs.  The minimal changes required on the APIs to move from one cloud to another has never been raised as an issue of significance, versus the services and features of specific clouds.  

To this very point, Lydia Leong of Gartner, in a recent blog post, asks the question:  Are Multiple Cloud APIs Bad?

"... I believe that it's too early in the market to seek commoditization. Universal commitment to a particular API at this point clamps standardized functionality within a least-common-denominator range, and it restricts the implementation possibilities, to the detriment of innovation. As long as there is rapid innovation and the market continues to offer a slew of new features -- something which I anticipate will continue at least through the end of 2011 and likely beyond -- standardization is going to be of highly limited benefit."

Mezeo is also engaged with the SNIA Cloud Storage Technical Working Group (I talk about the group here) to work with the industry to sort out the requirements for APIs that will allow for transportability, and there are other vendors that build wrappers that provide for easy portability amongst APIs.  

Finally, here's an opinion: if I were calling myself cloud storage for the IT hosting industry, and I did not offer REST Web Services APIs, I would likely argue that they are not needed, or at least that they are the wrong ones if they are not like S3.  When I am with my colleagues in the Web Hosting Industry, they find this argument against APIs amusing to say the least, and that's a fact you'll have to accept my opinion on! 

My last post on REST generated some attention.  Since it is an important topic, I wanted to share some additional links for those who are trying to improve their understanding of REST:

- Stefan Tilkov's Intro to REST presentation and When is an API RESTful?
- Dare Obasanjo's Explaining REST to Damien Katz
- Paul Precod's Second Generation Web Services, REST and the Real World, SOAP, REST and Interoperability
- Tim Bray's The Sun Cloud and REST, as in Take It Easy
- More stuff from Roger Costello
- Ryan Tomayko's How I Explained REST to My Wife
- Roy T. Fielding's Dissertation: Chapter 5

REST reflects the architecture of the Web.  One of its most important characteristics (and there are many) is that it is "stateless".  That means that a REST style command from a requestor to a responder has everything in it the responder needs to know in order to take an action.  No further handshaking is required.  Very efficient and Web like.  Since it is "stateless" it works very well with a "stateless" server architecture, in order to achieve Web scale.  In this way many clients can interact with many servers against a large pool of objects to accomplish many interactions, well, you get the point, Web scale.  That's one reason we use RESTful Web Services API commands to access the Mezeo Cloud Storage Platform servers, which are also stateless architectures, implemented via Linux.  Web scale, one of the requirements of cloud.

REST is also highly efficient, so that interactions between requestors and responders via a network can be done with a minimum of overhead.  If you ever download a 500 gigabyte file via a cable modem based internet connection, you will likely appreciate any efficiency that can be achieved.  Speaking of efficiency, REST also accommodates caching, at both the client and the server, which can dramatically improve the efficiency of your interactions with the "object" (an object could be, for example, a file, like a picture, or a pdf). 

Developers who utilize RESTful Web Services APIs to create applications appreciate the efficiency and capability of the APIs.  Expect, over time, to see more commonality among base case APIs and other APIs that expose storage cloud specific advanced services.  For example, Mezeo based clouds offer a secure share, collaboration, notifications, and nested files and folders, for example.  Some clouds may have such a unique set of APIs that others will create translators (wrappers, for the IT guys in the audience) for them, and we will continue to make headway on openness.

RESTful APIs are a critical part of new application development, and represent the delivery of Service Oriented Architecture infrastructure for storage.  Storage is now programmable.  And I bet you thought cloud storage was just a utility computing model applied to storage, for scalability and pay for use.  Both are necessary, but not sufficient for cloud storage.

Most of us in the Cloud Storage industry strongly believe that a key capability of a storage cloud is the REST style Web Services API.  Many of the most popular storage cloud services include or exclusively use REST, including SoftLayer's CloudLayer, Amazon S3, Nirvanix SDN and Rackspace Cloud Files.

Other access methods that are most often associated with Cloud Storage access include cifs, NFS and WebDAV,  NFS and cifs are not particularly usable via an Internet connection and therefore useless in public cloud offerings.  While WebDAV is very useful for an Internet connection, it is similarly limited, in that all three protocols support traditional file operations like store and retrieve, versus the robust set of services that Web Services APIs can deliver.

Amazon introduced S3 with REST style API access only.  Cloud Files from Rackspace also utilizes REST style APIs. Nirvanix SDN utilizes both REST and SOAP APIs.  Mezeo offers REST APIs.   Various groups are also engaging on the issue of what representations of REST should be common across cloud offerings.  The SNIA, (the Storage Networking Industry Association) has assembled a technical Cloud Storage working group for further refinement of REST style implementations for several purposes.

So, what is the purpose of the other, older access protocols?  When deployed with API based Cloud Storage offerings, they provide additional options for legacy applications to expose their objects (files) to the advanced services of the Cloud, and further make these files available to the new API based applications.

Why all the excitement about RESTful APIs?  Cloud Storage is more than a utility business model applied to traditional storage. It is storage that is accessed via Web Services APIs, over a network. Developers utilize these APIs because they are easy to use and they expose significant capabilities and services from the storage cloud, far beyond scalability, performance and pay for use.  As I have said before, scalability and pay for use are as much a business decision about how you sell storage, as they are a technology implementation of storage.  If there were no need for the API based services, the older and well used protocols would persevere.  This is clearly not the case.

I have carefully avoided the use of the word "standard" associated with the REST  style or architecture.  Here is an interesting view on that topic from Roger Costello:

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)

Cloud storage service providers understand that a new storage infrastructure has emerged, as an embodiment of Service Oriented Architecture, with a set of services that are delivered via APIs.  Scalability, performance and pay for use are attributes of traditional and cloud storage solutions, but Web services APIs are the distinguishing feature of cloud storage.  Accessing storage via Web services APIs represents a revolutionary change in storage, not a simple generational change. REST APIs are the embodiment of the way the Web works and are necessary to expose storage as a "storage cloud"!

What should you expect in relation to these API issues?

Most of us expect that over time, there will be a base set of specifications that are jointly developed within the marketplace and by various industry organization, resulting in a well accepted set of representations for REST style Web Services APIs.  At a panel at Hosting Con earlier this week, both Emil Seyegh of Rackspace and myself confirmed that when the industry gets further clarity on this specification, it will be relatively easy to introduce those APIs into our offerings, and that they can co exist with our current APIs.

REST is a topic that you will continue hearing more about.  You'll most certainly hear more about it from me in future posts.