Category: Cloud Storage Initiative

Validating yet another feature of the CDMI standard (see previous post for an earlier one), Amazon announced their Object Expiration feature for S3. While not a new concept for storage interfaces, it is the first cloud implementation of this capability that I know of. The idea is simply to have the server side of the cloud do object deletion on your behalf automatically, once the lifecycle of that data has completed.

As part of overall Data Lifecycle Management, object deletion is the most common terminal state for data. CDMI has standardized the interface for this capability in cloud storage with a comprehensive Retention and Hold Management feature (Chapter 17). The granularity of the standard CDMI feature is finer than that of the S3 feature in that it allows for retention and deletion on individual objects (although you could accomplish this in S3 with prefix = object name, it doesn’t scale using the header fields that Amazon uses). The S3 prefix mechanism can be used to scope the expiration policy down to individual “directories” (forward slash terminated parts of object names), and CDMI allows this also for the semantically equivalent CDMI sub-containers.

Complying with Regulations

Although the ability to delete objects when their lifecycle completes is useful, it is insufficient for complying with regulations such as Sarbanes-Oxley, or for eDiscovery needs during litigation. For most enterprises, they need to show that the data has not been modified during its lifecycle. In addition, if a subpoena is issued for the data – you DO NOT want the object deleted, even if it’s retention period has expired – this can cost you millions of dollars in a pending court case…

The CDMI standard anticipates that storage clouds will want to offer a more robust, full featured retention and hold management for corporate data, and that a standard means of achieving it will be needed. Take a quick look at Chapter 17 (it’s quite compact while being comprehensive) and investigate using the standard way to achieve this function. If you are a cloud vendor trying to emulate the S3 interface, good luck to you – Amazon will continue to expand the definition of what “S3” means (like adding this feature), forcing you to constantly modify your cloud’s storage interface to keep up (as well as requiring you to reverse engineer any bugs that exist).

One of the features of many storage systems and even disk drives is the ability to encrypt the data at rest. This protects against a specific threat – the disk drive going out the back door for replacement or repair. So it was only a matter of time before we would see this important feature start to be offered for Cloud Storage as well. Well, today Amazon announced their Server Side Encryption capability for their S3 cloud offering. This feature was anticipated by the CDMI standard interface when it was finalized as a standard back in April 2010.

Standard Server Side Encryption

So, how does CDMI standardize this feature? Well, as usual, it starts with finding out if the cloud actually supports the feature and what choices are available. In CDMI, this is done through the capabilities resource – a kind of catalog or discovery mechanism. By fetching the capabilities resource for objects, containers, domain or queues, you can tell whether server side encryption of data at rest if available from the cloud offering (yes this is granular for a reason). The actual capability name is: cdmi_encryption (see section 12.1.3). This indicates that the cloud can do encryption for the data at rest, but also indicates what algorithms are available to do this encryption. The algorithms are expressed in the form of: ALGORITHM_MODE_KEYLENGTH, where:

• “ALGORITHM” is the encryption algorithm (e.g., “AES” or “3DES”).

• “MODE” is the mode of operation (e.g.,”XTS”, “CBC”, or “CTR”).

• “KEYLENGTH” is the key size (e.g.,”128″,”192″, “256”).

So the cloud can offer the user several different algorithms of different strengths and types, or if it only offers a single algorithm (such as the Amazon offering), the cloud storage client can at least understand what that algorithm is.

So how does the user tell the cloud that she wants her data encrypted? Amazon does this with a proprietary header of course, but CDMI does it with standard Data System Metadata that can be placed on any object, container of objects, queue or domain. This metadata is called cdmi_encryption (see section 16.4), and contains merely a string with a value chosen from the list of available algorithms in the corresponding capability. There is also a cdmi_encryption_provided metadata value to tell the client whether their data is being encrypted or not by the cloud.

Lastly, there is a system-wide capability called cdmi_security_encryption (section 12.1.1) that tells the user whether the cloud does server side encryption at all.

Server side encryption is an important capability for cloud storage offerings to provide, which is why CDMI standardized this in advance of having cloud offerings available. We expect more clouds to offer this in the future, and customers to soon realize that – without CDMI implementations, these offerings are locking them in and causing a high cost of exiting that vendor.

There is a post by Jerry Huang , CEO of Gladinet on the problems with trying to be compatible with Amazon’s S3 API. Jerry suggest you look at OpenStack or a common library instead.

Amazon’s API (as with any cloud vendor’s API) is a moving target for sure, but the main issue is that these APIs are under the change control of a single vendor. Doesn’t matter how “open” the API is (in terms of copyright license) because the vendor can change it to disadvantage a competitor. So if you are a competitor, you would be foolish to use that API as the only interface into your cloud. So what happens? Each cloud vendor releases their own “open” API – similar but slightly different (enough to get around copyright), almost always RESTful and pretty much they all do the same thing.

So, you get the situation we have today with rapid proliferation of many different interfaces all pretty much the same. But that doesn’t help the poor clients. They have to code to N different interfaces to work with N different clouds. And since they are rapidly evolving, they have to keep up with all these API changes over time.

The Cloud Storage standard CDMI does not have this problem. CDMI is under the change control of a standards body (SNIA) and accommodates requirements from all the cloud storage players in it’s standardization process. More importantly, it was developed under the SNIA IP policy to help prevent any of the specification author companies from gaming the spec with their Intellectual Property. Thus cloud vendors can pick up the CDMI specification and implement it with confidence. They don’t need to come up with their own API. CDMI also has a standard way to extend the specification for vendor specific functions that still allows for core compatibility with other vendors. Want to do versioning? There is an example vendor extension in CDMI that shows you how.

From a client side point of view, Jerry also mentions common libraries. Jclouds is a good example of this (for Java). There also common libraries for other languages. While that can insulate a client from the many proliferating APIs, it’s a tough task to keep that library up to date with these APIs (just ask Adrian). The sooner the various cloud providers can implement the CDMI standard (even along-side of their existing ones), the sooner common libraries like Jclouds can just maintain a single adapter to a standard API.