The appeal of the cloud for storage purposes comes, in part, from the appearance that the cloud can have infinite and scalable storage. Scalability infers that the cloud provides benefits that will allow the addition of tens to hundreds of users for short or long periods of time—without having to worry about or invest in expensive hardware, software or services upfront.

Cloud storage is fundamentally about the delivery of virtualized storage on demand. Hence, there is the perception that the cloud is elastic in nature; that is, it can handle sudden, unanticipated or extraordinary loads. Elasticity and scalability are not the same, and thus, the interchangeable use of these terms should not be encouraged.

USE OF THE CLOUD
On the consumer front, the pay-as-you go model extends the belief that the cloud is affordable. Buy what you need, when you need it—nothing more. Commercial services for consumers are attracting vast new users to the cloud. Business uses are expanding with the concept and deployment of “private cloud” services continuing.

Cloud services and cloud storage are built on familiar technologies including Service Oriented Architectures (SoA); and among other practices, may be governed in part by Service Level Agreements (SLAs) and such.

As with other forms of technology, users hope there can be uniformity in the interfaces, capabilities and prospects associated with the cloud. This is inherently possible when standards are written and adhered to. However, with any new set of services, it can often take years before sufficient documentation, experience and devotion to developing those standards may occur.

Architecturally, for cloud storage services, the resources available to users (clients) are exposed as data paths, i.e., functional interfaces, which are managed via control paths, otherwise known as management interfaces. Many of the offerings initially available for cloud storage were of best-effort quality, much like the delivery of data using TCP/IP.

Since then, there has been serious work on developing methods that support a quality of service (QoS) level, which will in turn, lead to deployment of additional data-related services.

The Storage Networking Industry Association (SNIA) has been diligently working since before 2010 on an initiative to develop a functional interface that applications can use to create, retrieve, update and delete data elements from the cloud. This work is called the “Cloud Data Management Interface” (CDMI), and as of June 2012, was at Version 1.0.2.

You will hear a lot about CDMI in the near future. The working document, its publication and distribution is controlled by SNIA. Full and complete credit is given to SNIA for much of the context of the material presented in this article.

The CDMI effort is believed by many to be the foremost set of specifications for the universal uses of cloud storage. It is a complex set of specifications rooted in the fundamentals of object-based storage. Where possible, the interface design for the CDMI specification uses RESTful (Representational State Transfer) principles, which is essentially a simpler alternative to SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language). REST has gained widespread acceptance across the Web as the predominant service design model.

Fig. 1: Cloud computing—composed of cloud storage and cloud services

Every container object will possess a globally unique object identifier, or OID, that never changes throughout the life of the object. Accessing the container object is achieved through one or more Uniform Resource Identifier (URI) addresses.

GENERATING METADATA
Like almost all other sets of stored digital data, generated metadata becomes an essential (and required) component that, in CDMI, is used for access control and, from the user side, can include arbitrary user-defined items that help in describing the information about the data in the container— or for other purposes deemed necessary by the user.

Once an object is created, the storage system metadata is generated (by the cloud storage system), and is made available to a CDMI client during any subsequent retrieval of data from the cloud.

CDMI also includes three functional logging capabilities: object logging, security logging and data management logging. The log messaging formats are not defined in CDMI, although it is anticipated that future logging standards will be addressed.

Other capabilities include summary billing information, the export of containers as NFS or CIFS shares, queries and persistent first-in, first out queues, and serialization— the capability to export data and metadata into another cloud system.

For the present, the efforts of SNIA to promote a standardized interface that will allow users to enjoy the benefits of private (restricted) clouds, public (unrestricted) clouds and potential subsequent other offerings, are already being implemented by the industry. The delivery of other services (Fig. 1), including Software as a Service (SaaS), Platforms as a Service (PaaS), Infrastructure as a Service (Iaas) and Data Storage as a Service (DaaS) are surely in our future.

Whether you see your applications as public (open) or private (constrained within the bounds of your business), the “cloud” is here and is accepted. Building the future of your enterprise will involve the cloud as service or storage needs grow.

CDMI is a registered trademark of SNIA; complete details on the current CDMI specification can be found at http://cdmi. sniacloud.com/CDMI_Spec/.

Karl Paulsen (CPBE) is a SMPTE Fellow and chief technologist at Diversified Systems. Read more about these and other storage topics in his book “Moving Media Storage Technologies.” Contact Karl at kpaulsen@divsystems.com.