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.
Leave a Reply