Storage Nation

I was pleasantly surprised by the vigorous debate kicked off by one of my recent posts " The Future Doesn't Have A File System ".  Although most of the vigorous rhetoric came from an individual with a clear vested interest (Alex McDonald who is the competitive blogger over at NetApp), he did bring forth some themes that I'm sure are more widely shared.  And, just as vigorously, Paul Carpentier of FilePool (Centera) fame argued the other side of the equation. I'd like to use this post to step back a bit and lay a bit of groundwork as to why this is such an interesting topic to so many of us looking at architecture. Consider The Object Perhaps one of the simplest concepts in computer science, it usually boils down couple of standard components. – an arbitrary amount of bits (data, code, whatever) – a unique identifier – an aribrary amount of metadata to describe it to different parties – and some sort of access method to invoke or use it That's about it.  It's about as clean an abstraction as you'll find.  Application developers are very comfortable with objects (usually procedural code), and assembling application from collections of various objects.

If you're like me, you love to see the continual cycles of disruption that percolate through our industry. You might wonder why a "disrupto-phile" like me would work for a large, successful behemoth of an IT company like EMC, it's easy.  It's pretty easy, actually. First, you don't get large and successful without paying attention to disruptive trends.  And, second, it's far more fun when you are the disruptor rather than the disruptee. Case in point: a rather innocuous announcement from our Iomega subsidiary, found here