Object Storage not yet defined
The ExecEvent Object Storage Summit earlier this month continued to generate buzz on the industry, which is very exciting. Amplidata was represented – in spirit – at the Summit by our partners Intel and Quantum; due to an insane travel and show schedule this fall that kept us from attending personally. We’re grateful for the mention in Storage Switzerland’s sponsor briefing articles. Very cool! With all the great stuff that has been happening for Amplidata lately, including the awesome performance test results by Howard Marks, we felt a bit like we were missing our own birthday party. We’ll be there next time!
The event fostered a few “What is Object Storage?” posts from, amongst others, George Crump. Jim O’Reilly also posted a very interesting article, although I’m not sure if he was at the event. If he wasn’t, he should be next time!
Both articles add to the body of knowledge that is rapidly evolving on what object storage is, and why customers should adopt it – so, every article helps. With a topic as technical as object storage, it’s easy to evangelize with a deep technical dive. But that misses the “elegant simplicity” point. Hence we love George’s use of the car park analogy which we ourselves often embrace. His article was a helpful at-a-glance overview. On a more technical level, Jim’s explanation of such concepts as immutable blobs, “the original version is the only version”, objects still look like files etc. offer more on how object storage really works. George’s analysis on how “Objects are given unique ID numbers” is what’s missing in Jim’s article. I guess, what we’re saying is “read both articles.”
But read them critically, and you will see that we’re not there yet. As you can read in Jim’s article, the paradigm has been around much longer than many of us know and we’re not complete in defining the best use cases, implementations, architectures, etc. For example, I’m not at all sure about the reduced metadata George writes about. I believe that over time, as we start using richer applications, we will be storing more metadata, not less. To me, Jim’s statement “To be an object, a blob of data needs a much more detailed descriptor record than what file systems use.” is more accurate.
Both articles also cover the “why” of Object Storage. I’m not sure I see the use of Jim’s deduplication paragraph, and I think we are missing erasure coding as an alternative to RAID in his article (replication can be expensive too!). Jim accurately mentions that block storage was I/O focused, but omits the exceptional throughput performance some of the object stores deliver. A good thing is that Jim sees the scalability, flexibility and cost-saving opportunities. Finally, I very much like his use cases: Google Picasa, Amazon S3, Genome etc. and it is very interesting to read that Jim sees potential for object storage in the Big Data analytics space.
So back to George’s take on why we need object storage. Agreed that object storage platforms scale better than file systems & NAS but, again, not so much because of the metadata. File systems have different challenges, such as the granularity of the hardware, limitations on numbers of files or the number of levels in the hierarchy. Distributed file systems tried to solve some of these issues, but object storage is just a much simpler approach. Agreed that adding NAS heads is an expensive and not so great solution!
The second topic I thought was interesting was the issue of “bit rot”. Bit rot is a real problem and will lead to data loss with traditional storage technologies, but not every object store will solve that. How I understood it is that it is the underlying data protection scheme that solves the problem of bit rot, not necessarily Object Storage. Erasure Coding detects bit rot and prevents data loss. I don’t think you could restore the content of an object using the identifier, but maybe there is some really cool technology out there that I don’t know of. As George wrote “The storage system does not need an elaborate RAID protection algorithm nor do its administrators need to suffer through long RAID rebuild cycles”, I think he actually alludes to Erasure Coding but didn’t want to go that deep in this article.
Another interesting point in George’s article is the issue with backups. Once you go into the petabyte range, it becomes very unwieldy to backup data. He mentions the backup window, but add to that the overhead cost. George promotes using the unique IDs to make sure “that there are always copies of each object available on-site and off-site.” Again with the proper underlying protection schemes (erasure coding) you can rule out backups altogether!
I’m sure both George and Jim will appreciate the feedback – I fully agree with the benefits object storage brings to track iterations of files and the paragraph on geo dispersion, which we have termed geo-spreading. Finally, I hope to read some more of George’s thoughts about how object storage can help to monetize archived data as that, to me, is a key argument for this new but then again not so new storage paradigm. This is obviously not the end of the discussion; a lot will and needs to be said about this new paradigm. I’m looking forward to attending the next Object Storage events…
Clouds and Beer 