ViPR

Cast your minds back to 2009. At that time, Chuck Hollis wrote a blog post that quoted the following definition:

“Frankenstorage appears to be a new twist on [the Frankenstein] idea — storage arrays, assembled from various parts from multiple vendors, brought to life by the magic of powerpoints and press releases.”

The crux of the blog post referencing this lovely term was storage virtualisation. Apparently in 2009, storage virtualisation was bad. Why would anyone want to take the opportunity to use a consistent access method for bringing disparate data sources together under one common standard protocol? Madness.

Wind forward to 2013 and we have a very different landscape. EMC VMAX now supports external storage; VPLEX effectively virtualises other storage platforms, although we have to call it storage federation. And now we have EMC ViPR, which apparently introduces storage virtualisation too – albeit in a new form only covering the management aspect of storage infrastructure.

Project Bourne

ViPR is apparently the crystallisation of Project Bourne, a (not too secret) piece of work from EMC’s Advanced Storage Division. The marketing message tells us that we need to separate the control plane from the data plane in storage (as has been achieved with Software Defined Networking) and ViPR delivers that for us, with all the perceived benefits. I have a feeling the reality is probably something different.

Although EMC continues to be the leader in storage array sales (see my recent Gartner post covering this), they are seeing strong growth from their competition. One of the major issues with EMC’s VMAX and VNX platforms is storage management at scale. EMC’s SRM tools have never fully delivered and been complex and cumbersome to deploy and operate. As a result, many companies still provision and do migrations via scripts. This is a tedious and error-prone process, requiring significant understanding of the underlying platform to ensure workloads are balanced efficiently. EMC’s competitors have done a better job at managing the storage management issues; Hitachi have invested heavily in their software and can do tasks like migration without outages using UVM and HAM. HP 3Par is a management dream compared to provisioning storage on VMAX. Then there is the breed of new devices and startups (e.g. SolidFire) that have focused on simplified management and native API integration. Note the use of the word “native” here, not some new artificial wrapper like VMAX Cloud Edition.

iWave

So EMC needed to do something to fix this problem; they acquire iWave Software, a startup focusing on storage automation software tools. Their Storage Automator software takes some of the manual work out of storage provisioning and provides a framework into which storage arrays can be placed. Each array can be attributed to more generic technology pools (e.g. gold/silver/bronze tiers) from which storage is provisioned to hosts, including all the fabric zoning and LUN masking needed. Storage Automator provides a number of benefits; it enables lesser skilled staff to do storage provisioning within the controls of the framework established by storage architects. It implements automation around provisioning out of hours and it abstracts the view of the array to more generic tiering constructs.

I first saw iWave in March 2012 and was impressed with the product. There were a few rough edges and platform support was limited, but as a tool to reduce the time and effort of provisioning, it did a good job. What it did not do was storage virtualisation. LUNs were presented to the host directly from the managed devices with no other physical abstraction. There were no features for load balancing across pools, multi-tenancy (other than allowing portions of the pools to be provisioned by certain users), transparent migration, or any of the other features that would commonly be expected from a storage virtualisation platform.

EMC’s acquisition of iWave in January 2013 (although not formally announced) provided them the ability to make good on some of the provisioning shortcomings, however that wouldn’t be enough for Jeremy and the boys in marketing. What they wanted was a stronger message and what better vehicle than Software Defined Storage. Provisioning automation gets positioned as the control plane, which leaves the data plane issue to solve. This is where Frankenstorage comes in again. iWave has been combined with some HDFS/NFS presentation software layer to create this new product that is “assembled from various parts from multiple acquisitions [vendors], brought to life by the magic of powerpoints and press releases”.

This intention to merge what at the outset appears to be two distinct classes of functionality is probably the most confusing. At this stage I can’t see how ViPR could truly be called storage virtualisation unless they incorporate VPLEX into the mix and then we’re really into Frankenstorage solutions. At some point you have to stop bolting bits on and accept legacy technology is past it’s sell by date.

The Architect’s View™

As a $50 billon company, I’d expect more out of EMC than repackaging of seemingly unconnected components. The marketing message seems to be overtaking the technology to a point where they are believing their own hype. If you’re looking at ViPR, question EMC on what the evolution of this platform will be; question exactly how multi-tenancy, rich APIs actually work; above all, measure the value proposition of their solution against the rest of the market, because the storage landscape is much bigger (and in many cases much better) than just EMC.

ViPR – Frankenstorage Revisited

Project Bourne

iWave

ViPR

The Architect’s View™

Related Links