EMC ViPR as a Part of a SDDC

At EMC World 2013, EMC announced ViPR as the answer to storage within the software defined data center. ViPR presents multiple types of storage while segmenting the control plane from the data plane. In addition, ViPR is a head end, fronting traditional storage arrays as an automation and control point and does not replace any array, but, possibly, makes it easier to use those arrays as we move to the software defined data center. Yet, ViPR also raises several questions about how storage will be accessed by the software defined data center: is ViPR the future, or is there more to happen?
The real question in my mind is, is segregating the control plane from the data plane all that is necessary to successfully bring storage to SDDC? If so, have we not already been doing that for years? I think more has to be done. We do not just need to separate the control plane from the data plane but also present multiple types of data and controls for use by various workloads. Part of SDDC is to move from a VM-centric to an app-centric view of the data center much like we moved from a HW-centric to VM-centric data center with virtualization. The application becomes the workload of an SDDC, not the VM. We have been migrating this way for years.
SDDC implies automation of the deployment, networking, security, and storage layers for the workloads that run within. While this is the goal, we are far from that. We know how to deploy new virtual machines and some applications in an automated fashion, and we are working towards networking and security, but storage has always been the last to move. This is mainly because storage, in many ways, is still tied to hardware; specifically, types of disks within some form of array. The introduction of ViPR does not change this in the least. What it does change is how the physical hardware is seen, used, and integrated into the app-centric workloads of SDDC.
Specifically, ViPR presents data in different formats: block, object, or filesystem. The block storage ViPR supports is the type well known by most data center architects, as it is the native format of most array storage known today and used by virtual workloads to store the virtual disks. The object storage presentation is generally used by applications directly and presented as an API such as Amazon S3, which is supported by OpenStack Switch, Ceph, etc. The file systems supported by ViPR not only include NFS, once more used by storage for virtual workloads, but also HDFS, which is used by Hadoop to process big data questions. ViPR does all this by managing the underlying storage and translating as necessary. Block storage is not object storage and neither are filesystems, but objects can overlay blocks and filesystems can overlay either.
EMC ViPR provides one central place to manage storage for applications and the underlying workloads while abstracting out the physical hardware. However, it is not the only company that provides such a device. CloudFounder’s Open vStorage provides the ability to manage block and object storage but not HDFS at this time. Given both these systems, perhaps we are finally seeing a real definition for storage hypervisors coming to light, one that abstracts underlying storage of any type to be presented as any type necessary to the proper running of a workload whether that be a filesystem, block, object, or some heretofore unknown type of storage.
The real question in my mind is whether or not ViPR and similar products will become part of the software defined data center as an automation enforcement point using hardware or software. If software, will it eventually be pushed into our well-known hypervisors as drivers with further abstraction or as virtual storage appliances?
EMC ViPR is definitely one view of the future of storage within the software defined datacenter. What are your thoughts of the future?