Thanks for the reply. I personally do understand the differences between EMC Compression and Deduplication and NetApp Deduplication and Compression features but it's always good to point out to customers. With ALL of the technologies from both vendors, as with anything in life, there are cases where the benefits outweigh the drawbacks and cases where the opposite is true. I was using compression as an example enhancement of the 64-bit aggregates, of course maximum usable capacity is another major one.

Disclaimer: EMCer here - Compression, 64-Bit Aggregates, and DataMotion all sound like great features from an upgrade. A Few Questions: Can you convert existing 32-bit aggregates into 64-bit aggregates after the upgrade and then increase the size? Or do you need to create new aggregates on different spindles? Can you use DataMotion to migrate existing LUNs from 32-bit Aggregates into 64-bit Aggregates to take advantage of compression for existing data? Thanks!

I would assume that Microsoft will ensure that Windows Guest VMs will work well with this approach. However I wonder how that will translate to non-Windows guests? VMWare's approach is nice in that it supports pretty much any guest and if Hyper-V Dynamic Memory only works well with Windows guests, VMWare will continue to be preferred in large orgs. Regardless, this is an interesting approach and might provide better overall results for an all-Microsoft environment.

Good post, I'm also frustrated with the use of the term Cloud lately. Disclaimer:I work for EMC, so the positioning of cloud to my customers is generally around building flexible infrastructures to support their applications. However, my personal, more simplistic view of cloud when it comes to storage is that it needs to be globally distributed to qualify as cloud. Right now within EMCs portfolio that product is Atmos, a massively scalable, object-based storage system, built specifically for the purpose of allowing applications to read and write data, against a single shared pool of storage, anywhere in the world, at any time. As far as most storage and virtualization vendors go, it seems acceptable to simply "enable the cloud" by lowering costs, or adding multi-tenancy, etc. These are valid solutions to valid problems but I don't think they really qualify as Cloud products or solutions. This is my own personal opinion of course.

Thank you for the kind words Barry. My blog topics have obviously shifted a bit since coming to work for EMC but I'm finding that for the most part, discussions I have with customers make for good blog topics. Oh and the VPLEX Local discussion I had with that customer turned into a VPLEX Local and Metro Proof-of-Concept that we're ramping up soon. So I should have something to write on that in the next month or so. Richard

Vaughn, I really appreciated this post, and combined with all of the comments you received, we all, as vendors, should be educating our customers on the different approaches so they can understand where each will help them.

@StorageTexan, To give you a quick answer to your question.. The intent of VPlex is to do what traditional storage virtualization platforms from other vendors don't, which is to allow you to leverage the technologies inherent in your existing storage platforms - Symmetrix SRDF/Timefinder or Clariion SnapView/MirrorView, for example. Since Vplex is array aware and preserves the array's cache functionality, while enhancing performance with it's own cache, you can still use those tools. That is something you can't do with SVC and USP-V, with those products you are forced to move all of the intelligence into the virtualization layer which may not work for all of your applications. This is a differentiator for VPlex, not to mention VPlex Metro federation which is entirely unique.

The interesting thing to me is that there were essentially two contradicting claims... 1.) that tiering is dead/dying 2.) that dynamically moving blocks between SSD and SATA is the future, anything more is pointless. Regardless of which disk technology you are using (FC, SSD, SATA, CDROM, DVD, etc) anytime you store data on more than one of them you have tiering. Whether it's SSD+SATA (2 tiers) or SSD+FC+SATA+DDUP (4 tiers), you still have tiering and automating the movement of data between those tiers (be it 2 or 10) is the future. The underlying technology doesn't really matter.

Vaughn, I suspect that there is a lot of inference occurring here when it comes to the CIFS-vs-Disk IOPS and price/performance argument. Specifically, you can't infer that the backend VMax was actually servicing 6 million IOPs just because it's configuration is theoretically capable of doing so. As you know, CIFS and NFS Ops are NOT disk IOs. It is pretty clear from the sizing of the VMax in this test (and supported by Storagezilla's comments) that the goal here was to test the performance of the NS datamovers, NOT the VMax, and as such the VMax was configured for far more throughput than necessary for the test. That being said, making any sort of argument that EMC must need 50 IOPS for a single CIFS ops is impossible with the data at hand, and would be unbelievable anyway. Further, the context of the test being on the datamovers themselves also makes any sort of price/performance conclusion impossible. A customer requiring 100,000 CIFS Ops would work with EMC to size the backend appropriately and I would venture an educated guess that the backend would be smaller than what was used in this lab scenario. The only way to get a valid price/performance comparison between two systems is to size the front-end AND back-end for the workload. The beauty of the EMC approach is you have the ability to address bottlenecks where they exist rather than rip and replace or having to purchase a disparate system.