Object-defined storage (it’s not about object storage)

I’m here, sitting at the airport while waiting for my return flight from SNWEurope/Powering The Cloud, thinking about the briefings I had in the last two days.

I met many different companies and I also spent some time visiting the booths in the expo area. The show was good as always and even if this year it was quieter than previous years (recession has hit here too!) you can feel the overall quality of the event.

Software-defined bullshit

I spotted “software-defined *” marketing stuff almost everywhere, and it’s clear that if you are not doing something that is “software-defined” you are out! The problem is that, as always, “software-defined” is a buzz word and it has already lost its significance: every vendor has its own (often disturbing) definition of it and you can’t really do much more than listen to their version of the story and let them go through the slides without commenting.

So what?

I would like to point out something that sits underneath the “software-defined” buzz, allow me to call it “object-defined” storage.
Also at this event, I now have evidence that new storage architectures are going that way. I’m not going to repeat myself once again about object storage coolness but I’d like to add something more to my usual object storage rants.

I’m not talking (only) about object storage

Object storage is cool but there are many concerns about its adoptability in traditional enterprises. It can show excellent use cases but, at the same time, for successful deployment you need to use it in conjunction with specific applications (written to take advantage of the APIs) or gateways (like NAS or Sync&Share ones).
That makes object storage suitable only for certain type of applications and not for ordinary enterprise performance-demanding applications (like ERPs or virtualization, for
example).

That said, something interesting has been happening in the storage industry for a while: backend of next generation storage systems look more and more like object storage.

Objects and Object storage

An Object is usually made by two components: data and metadata. Data is usually a file while metadata describes the file (excuse me for the oversimplification). This is the reason why object storage is appealing: you don’t need to know the position of the object (like in a file system) but you can point directly to it by knowing its characteristics or the unique ID of the object. Objects can’t be duplicated (they are unique) while metadata can be easily added if needed. You can have trillions of objects that live in the same namespace and could potentially have the same identical access time.

Not only the Object but also most of modern Object storage systems share similar characteristics: scale-out, single namespace domain, geo-distribution, multi tenancy, data protection and data management policies among others.

Do you see the analogies now?

Blocks are the Objects and Object storage is the logic at the backend. You can easily find this concept in many of the new, most interesting, startups (like Exablox and Coho Data, only to give you a couple of examples). They do not have a proper file system or a basic allocation table and all the consequential limitations.

Theoretically speaking this kind of architecture brings a lot of advantages thanks to metadata and the object storage like behavior of the backend:

• It can scale up and out to a very high number of nodes maintaining a linear progression in terms of performance;
• It allows to have different kind of nodes in the same cluster with different performance or space characteristics;
• It has the ability, as it happens in a proper object storage, to use the metadata to obtain information on each block and implement any kind of feature: RAID-like protection, snapshots, tiering and so on;
• Sophisticated replication mechanisms are easy to implement;
• It gives the freedom to develop any kind of access protocol on top of it;

The list is much longer than that, I’m giving you the first examples that came to my mind.

Bottom line

In a few words, an object-storage-like backend can certainly be considered as an important characteristic of a modern storage system. Especially now, that many end users are experiencing an exponential growth of data and new kinds of workloads, the type of backend should be carefully evaluated during the selection of a new storage infrastructure.

I’m not saying that FileSystem based backends are bad or they can’t scale enough or that they do not have features. On the contrary, they are good in many cases (and more mature) but they do not have all the same characteristics that you can spot on a object-defined storage.

Object-defined storage systems aren’t the panacea for all your storage problems but it’s certain that this kind of architecture opens many more possibilities for the future: if correctly implemented, it has a great potential and allows the vendor to provide more scalability and features quicker.