Storagebod Rotating Header Image

Reality for Scality

You know that I have somewhat mixed feelings about Object Storage; there is part of me which really believes that it is the future of scalable storage but there is another part of me that lives in the real world. This is the world where application vendors and developers are currently unwilling to rewrite their applications to support Object Storage; certainly whilst there is no shipping product supporting an agreed standard. And there are a whole bunch of applications which simply are not going to be re-written any time soon.

So for all their disadvantages; we’ll be stuck with POSIX filesystems for some time; developers understand how to code to them and applications retain a level of storage independence. You wouldn’t write an application to be reliant on a particular POSIX filesystem implementation so why would you tie yourself to an Object Store?

I was pleased to see this announcement from the guys at Scality; they are good guys and their product looks sound but no matter how sound your product is, you have to try to make it easier for yourself and your customers. Turning their product into a super-scalable filer is certainly a way to remove some of the barriers to adoption but will it be enough?

Of course, then there are the file-systems which are beginning to go the other way; a realisation that if you are already storing some kind of metadata, it might not be a huge stretch to turn it into a form of object store.

File-systems, especially those of the clustered kind and Object Storage seem to be converging rapidly. I think that this is only for the good.

 


3 Comments

  1. EtherealMind says:

    Can’t help but feel that the Storage Industry isn’t ready for change. Object Storage would require a change in approach and attitude, something that storage people aren’t good at in my experience.

  2. Martin Glassborow says:

    I can’t but help but totally disagree with you! Object Storage is not a storage problem; Object Storage changes how operating systems, applications etc interact with their data-store. This is not a storage issue; I could roll object storage out tomorrow….unfortunately there are very few applications that could use it.

    So we are in the situation that in order to get some kind of traction and footprint for Object Storage, gateways which allow applications et al to utilise object storage without rewriting all the applications are necessary.

  3. Hey Martin,

    Thanks for picking up our announcement. We do think that to raise adoption of Object Storage, we did need to offer something more standard to the majority of applications out there.
    The newer applications typically know how to speak object storage, just because they were born during the cloud era where such a protocol is becoming standard for unstructured data. But it is true that older, legacy applications will most likely not be rewritten any time soon. Not enough traction from the actual users for it.

    We do believe it is going to be the case more and more. Applications vendors of products like Email Servers, for example, which are typical enterprise and service provider needs, are becoming more and more aware of that, and start incorporating object storage as backend storage. After all, Email lends itself perfectly to Object Storage. So does Backup, Archiving…

    To your question, will it be enough?, probably not as of right now, although it is a step in the right direction and already opens up the door to a lot more applications, without a need for a rewrite.
    But for the other applications out there, we have some other things up our sleeves that will bring in even easier adoption to our object storage. Our mission is really to bring the same kind of scale our pure object storage delivers to a regular storage environment and their legacy protocols. It’s going to be a journey, but we’ll get there 😉

    Thanks again for your post, and for all your other posts. Always appreciate them a lot 😉

    Best,
    Marc V

Leave a Reply

Your email address will not be published. Required fields are marked *