Rather than answer this on a product-by-product level, the answer is architectural.

EMC is trying to put more storage functionality in the storage network, rather than the end points (arrays and servers).

Visible examples today include Invista (storage virtualization aka volume mgmt), RecoverPoint (local and remote replication), and the wire-speed encryption technology we announced with Cisco last May, but is not available yet.

On the NAS front, you’ve seen us move functionality from Celerra (NAS endpoint) to RainFinity (network-based file virtualization).

Understandably, this is a long journey from a product perspective. To the best of our knowledge, no one is taking this quite as seriously as we are.

So, given this long-term direction, any comparison / positioning etc. has to be very dependent on the use case we’re talking about, and also measured at a particular point in time.

How I’d compare, for example, RecoverPoint and SRDF in 2007 will be very different as to how I’d compare them in 2009 or 2010.

You’d have to agree that putting advanced storage functionality in intelligent networks is a bit ambituous.

As an example, I was looking at your various network topologies, and I saw ways to do this with a classical approach, as well as perhaps with newer approaches.

Each would have its pros and cons. Neither would be perfect.

Let me know if you want to go deeper — thanks!

http://storagezilla.typepad.com/storagezilla/2007/09/the-future-is-v.html

Here’s the quote:

“EMC aquired Kashya to get it’s hands on the CDP and Remote Replication functionality and what they got was a product whose support of intelligent switches made it a perfect fit for offering Fabric based services. With Invista you don’t need to use array based replication but you can if you wish, if you’ve made an investment why throw it out? But if you haven’t or want CDP and Continuous Remote Replication running with Invista in your Fabric RecoverPoint allows customers to replicate or protect whatever they want regardless of if it’s virtualized storage or physical storage.

I see these (Volume mobility, storage virtualization, CDP, CRR, and so on) as heterogeneous services you can add to your SAN and make available as you see fit when you see fit. That’s my take on it though the people paid to think deep thoughts about this stuff might see it differently”
—

I see a logical fit with Invista as RP offers long distance replication but I don’t see RP clashing with SRDF. SRDF is SRDF. It does what it does in the market at which it’s aimed.

While RP is not aimed at the same market if you want bi-directional replication between Symm & CX or between EMC and non EMC arrays, (Customers use it to replicate between non-EMC arrays), RecoverPoint would be EMC’s solution there.

I’ll regret asking this but should I put together a post on RecoverPoint technology or is it just positioning is a sticking point?

I don’t want to speak for EMC here, but — as a very close bystander, I think there’s another view.

First, the notion that we’re somehow “protecting” our core products is misguided at best. If that’s the case, then we wouldn’t be doing RecoverPoint (replication in the fabric), partnering with Cisco and Brocade on switch-level encryption (also in the fabric), and many more examples. Why would EMC spend many millions of dollars on R+D for switch-based storage technology unless we were serious?

Second, I am of the personal opinion that “storage virtualization” has been way oversold by the industry. It has its use cases, but it does not solve global warming (as had been suggested), nor does it eliminate the need for storage management (as has also been suggested).

It’s just another tool in the toolbag. And — thankfully — we’re being successful at helping the EMC sales force to pull out the right tool for the right job, rather than blindly shoving square pegs into round holes.

I would agree with Chris that — ultimately — many forms of storage functionality belong in the network, virtualization (or volume mgmt) being one of many.

I would not agree that the product has not been successful. We have many happy customers, and — for them — the product does exactly what we (and they) want it to do.

I would argue that happy customers might be more important than bragging rights on unit counts. We all know how to play that game, don’t we?

Thanks for the discussion, guys!

SVC does indeed have a non-disruptive upgrade path. As we support any hardware model in a cluster / IO group, you simply stop one node in an IO group. The cache on the remaining node in the IO group goes write through. Power it off remove it, replace it with a new hardware, use the front panel to change the WWN back to the old node’s WWN (no zoneing changes thus needed) and power it up. The node then ‘appears’ to the cluster as the old node and re-joins the cluster and cache returns to normal on the IO group. Repeat for all nodes in the cluster.

I think you hit the nail on the head here. My view is that EMC ‘have’ to have Invista in their portfolio, however they don’t want to impact their sales and licensing revenue from their core products. Its there and if anyone asks about it they will tell, but its definitely a customer pull rather than sales push product.