Original URL: https://www.theregister.com/2013/09/06/netapp_sidesteps_vipr_snakebite/

Don't bother competing with ViPR, NetApp - it's not actually that relevant

ONTAP is all NetApp requires

By Chris Mellor

Posted in Storage, 6th September 2013 18:07 GMT

Blocks and Files NetApp doesn't need to compete with EMC's all-singing all-dancing ViPR product. Why not? NetApp only has one storage array product – ONTAP – whereas EMC has an entire family of arrays, which ViPR virtualises into a single resource and delivers to server apps needing storage.

Look at it like this: the EMC storage array product range includes different arrays designed for different use cases. For example:

NetApp's idea is to cover these use cases, except object storage and deduped backup, with its clustered ONTAP-driven FAS arrays. It has object storage in the works with StorageGRID, (although we hear little about that particular project), its all-flash FlashRay array development, and it has its E-Series for HPC-like data ingress speeds - an area where EMC is lacking, it seems to me. Yet the overwhelming majority of its business comes from the ONTAP arrays.

Server apps needing storage provisioning in NetApp's world get it from the one-size-fits-all ONTAP software environment, which provides block and file access, scale-out through clustering, and third-party array embrace through the V-Series ONTAP head systems.

But in EMC's world they have to talk to multiple different arrays. One way around that will be to use ViPR as the abstracted storage (provisioning and management) control plane and have underlying arrays - EMC ones or third-party ones - deliver data services. It makes perfect sense inside EMC's environment. ®