Very Early Thoughts about EMC ViPR

EMC announced ViPR today, the culmination of the not-so-secret Project Bourne and its lesser-known predecessor, Project Orion. Although I used to work at EMC before I joined VMware earlier this year, I never really had deep access to what was going on with this project, so my thoughts here are strictly based on what’s been publicly disclosed. Naturally, given that the product was only announced today, these are very early thoughts.

Naturally, Chad Sakac has a write-up on ViPR and what led up to its creation. It’s worth having a read, but allocate plenty of time (it is a bit on the long side).

Based on the limited material that is publicly available so far, here are a few thoughts about ViPR:

  • I like the control plane-data plane separation model that EMC is taking with ViPR. I’ve had a few conversations about network virtualization and software-defined networking (SDN) recently (see here and here) and the amorphous use of the term “software-defined.” In fact, my good friend Matthew Leib wrote a post about software-defined storage in response to an exchange of tweets about the overuse of “software-defined [insert whatever here]“. If we go back to the original definition of what SDN meant, it referred to the separation of the networking control plane from the networking data plane and the architectural changes resulting from that separation. SDN wasn’t (and isn’t) about virtualizing network switches, routers, or firewalls; that’s NFV (Network Functions Virtualization). Similarly, running storage controller software as virtual machines isn’t software-defined storage, it’s the storage equivalent of NFV (SFV?). Separating the storage control plane from the storage data plane is a much closer storage analogy to SDN, in my opinion. I’m sure that EMC hopes that it will spark a renaissance in storage the way SDN has sparked a renaissance in networking (more on that below).

  • I like that EMC is including a variety of object storage APIs, including Atmos, AWS S3, and OpenStack Swift, and that there is API support for OpenStack Cinder and OpenStack Glance as well. It would have been the wrong move not to support these APIs in ViPR—in my opinion, EMC won’t get another opportunity like this to broaden their API and platform support.

  • Obviously, a key difference between SDN and SDS a la ViPR is openness. While EMC proclaims the openness of the solution based on broad API support, 3rd party back-end storage support, a public northbound API, and source code and examples for third-party southbound “plugins” for other platforms, the reality is that this separation of control plane and data plane is being driven by a vendor rather than as a result of collaboration between academic research and industry. The reason this distinction is important is that it’s one thing for a networking vendor to build OpenFlow support into its switches when OpenFlow wasn’t and isn’t created/controlled by a competing vendor, but it’s another thing for a storage vendor to build support into their products for a solution that belongs to EMC. Whether this really matters or not remains yet to be seen—it may be a non-issue. (Yes, I recognize the irony in the fact that I work for VMware, some of whose solutions might be similarly criticized with regard to openness.)

  • Hey, where’s the network virtualization support? ;-)

Anyway, those are my initial thoughts. Since I haven’t had access to more detailed information on what it does/doesn’t support or how it works, I reserve the right to revise these thoughts and impressions after I get more exposure to ViPR. In the meantime, feel free to add your own thoughts in the comments below. Courteous comments are always welcome (but do please add vendor affiliations where applicable)!

UPDATE: It was brought to my attention I misspelled Matthew Leib’s last name; that has been corrected. My apologies Matt!

Tags: , ,

  1. afidel’s avatar

    Scott, I’d say you’re spot on with the EMC ownership being an issue, for the framework to catch on it’s going to need to be handed over to one of the vendor neutral open source groups. With that said I think it has the potential to actually give some traction to object storage. One of the biggest fears around the adoption of object storage from what I’ve seen and talked about is vendor lockin and buying into a potentially dead end platform. If we have a universal access layer to various object platforms that will go a very long way to easing those fears.

  2. Kenneth Hui’s avatar


    Great insights as usual; to piggyback on some of your comments:

    1) Totally agree with you that their is difference between SDx and hardware virtualization. In addition to the separation of control and data planes, I would assert that SDx means the underlying infrastructure is programmable via APIs so that it can be automated and configured on the fly. Eventually the programming should be done by the application, dynamically and according to policies, without operator intervention.

    2) If EMC really wants to open up ViPR to the community, they should seriously consider turning the technology over to a standards body or even open-sourcing it.

    Thanks again.

    Kenneth Hui


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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>