Tuesday at EMC World I had the chance to catch up with Amitabh Srivastava at the EMC Backstage set. It was a great chance for EMC World customers (physical or virtual) to Tweet their questions (and there were many) about the new ViPR technology that Amitabh's team is developing.
It's worth pointing out that Amitabh's background has two themes: (a) he has a strong research background (developed at companies like TI, Digital, and Microsoft), and (b) a strong track record of product delivery (Windows Server and Windows Azure being prime examples).
As a technologist I was looking forward to asking a few of my own questions, given that I had heard several things during Amitabh's keynote that I wanted more detail on. So my first question had to do wth Amitabh's assertion that ViPR will allow applications to access data written in one protocol (e.g. object) with a different protocol (e.g. file).
Amitabh answered this first question with a real-world customer use case: video editing. He described a customer that used public cloud, object APIs to store a large amount of video assets. During the editing process however, the customer had to insert non-film collateral (e.g. credits) into the video files. The customer needed to use file APIs for this task, so they
- dragged the current video out of the public cloud using object APIs
- stored the video into their local file store
- used file APIs to manipulate the video image
- moved the file back to the public cloud object store
This migration approach is slow and costly. Amitabh explained how ViPRs solution to this use case is to keep data in place and allow applications to "open" specific objects using a file API, perform the edits, and close the file.
At this point I could have spent an hour asking him how specifically ViPR accomplishes this task but it was time to answer questions from the Tweet Stream.
Storage System Questions
Amitabh moved on to answer a lot of Tweets related to ViPR's storage capability. Several of the Twitter handles I recognized as EMC employees expressing concern with the ViPR approach:
"Does this mean that there is no need to innovate at the storage level"?
Amitabh's answer was no. Many workloads will still require more and more innovation for increased intelligence within the array (think of the "sideways" additions to FAST that Brian Gallagher mentioned).
"Will EMC lose business to customer's purchasing commodity devices"?
Amitabh's answer, again, was no. He pointed out that historically EMC doesn't play in the storage market for commodity devices, but with ViPR now EMC can. This capability can actually extend EMC's business into new markets.
Reliance on the Ecosystem
During his keynote Amitabh highlighted that ViPR will need to rely on a partner ecosystem to add value. The Tweets from the crowd asked him for more detail on this point. His response was that we need partners to innovate in three different ways:
- From the storage integration standpoint (e.g. different vendor arrays)
- From the management framework (e.g. plugging into different management paradigms like OpenStack, VMware, etc).
- From the data services standpoint
Later on in the discussion I asked Amitabh about his keynote claim that ViPR would be "open", and I asked him how the partner ecosystem would engage with ViPR. Amitabh responded that this process is being worked out with the customers currently evaluating the technology, and the process will be shared once these current partners finish their deployment and integration into the system (they have access to ViPR's current restful APIs and binaries).
The session was packed with technical content but I'm quite sure we didn't get to answer everything. Throughout the rest of the week customers can continue to use the #emcbackstage hashtag to ask questions about ViPR, and the EMC Social Media team will do their best to follow up.
Perhaps the most interesting question focused on how his experience with the Azure platform applied to ViPR. Amitabh said the following: the lesson of Azure was that "things fail". This drove Amitabh to guide the ViPR team with a heavy focus on software resiliency.