 Live from San Francisco, California, it's theCUBE at VMworld 2014, brought to you by VMware. Cisco, EMC, HP, and Nutanix. Hi, everybody, we're back. Welcome to San Francisco. Welcome to the Moscone Center. This is theCUBE. theCUBE is SiliconANGLE and Wikibon's live mobile studio. We go out to the event, we extract the signal from the noise. We're here at VMworld 2014. I haven't heard what the numbers are. Anybody know what the numbers are here? It's got to be north of 25,000 people. The main hall was absolutely packed this morning, standing room only for Pat Gelsinger's keynote. And we'll be going wall-to-wall three days, Monday, Tuesday, Wednesday, so you can, there's a crowd chat going on, crowdchat.net slash VMworld, check that out. We're going to get deeper into some of the product discussions here. George Hamilton is with EMC, he's a product manager, senior product manager on the Viper side. So we're going to talk about Viper, SRM, and Aveshek Kumar works on the ExtremeIO side of EMC. We just heard a pretty high-level discussion about ExtremeIO. Well, first of all, gentlemen, welcome to theCUBE. Thank you. So, George, let's start with you. Talk about Viper. We've been hearing a lot about Viper. We covered it last EMC World. We covered two EMC Worlds ago. We've been tracking the progress. Everybody's gone software-defined crazy, which is, I guess, a good thing. Mark Endreson says software's eating the world. So that's probably a good thing to be shipping some more software-based products. But so give us the update on Viper. Where are we? Yeah, some of the really exciting things is really about extending the array support in Viper. So we've added additional support for a lot of EMC arrays, including ExtremeIO. Also, more arrays, we're already supporting NetApp. We added Hitachi support. And we're also extending support via the OpenStack Cinder plugin. All your friends. Absolutely, absolutely. So we're using the OpenStack Cinder plugin to support other arrays from HP, IBM, even Dell. So it's really about making Viper a platform to be able to manage all of your storage. We're particularly excited about adding ExtremeIO as it managed around to Viper to really add this high-performance flash array and make that part of your virtual storage pools within Viper as well. So what's happening in the customer side in adoption? Talk about that a little bit. I mean, you guys announced GA, probably ahead of schedule, I think, if I recall. Last fall, even, right? Yeah, it's actually, it's been amazing to watch, actually, working at a hardware company and seeing software take off so quickly. And it's been a big change with this quarterly software update. So really, within a very short period of time, we're already at version 2.0 of the software and now with version 2.1 coming up and being able to do all that in about a year and a half. So it's been an interesting change to see software be such a big part of EMC's portfolio. Customer told me recently that what he wants is an open source object store. The problem is they don't work. So we're going to talk about your object store and maybe how it does work. But I wonder if we could turn our attention to ExtremeIO. We just had a discussion about sort of a high level progress that's going on. But I wonder if we could sort of dig in to the product side a little bit. So maybe from your perspective, give us sort of your update on what's going on in the product, why it's doing well in the marketplace. What are some of the differentiating features that you focus on? So as Ihood was saying earlier, there has been a huge uptake in the market as far as ExtremeIO is concerned. I talk to customers every single day and there's a huge interest in terms of what ExtremeIO can do from a Flash array perspective. To say the least, you talked about some of the competitive differentiation, right? So it is one of the things that we always talk about ExtremeIO is how it is designed. We started from a clean sheet and said, let's see what else we can do. Instead of saying Flash is very good from a performance perspective, what else can we do from a storage device perspective and see what are the new application deployments that now become possible, what are the new ways we can now start providing data services like D-Duke, Compression, Snapshots. The way I like to think of it is all these data services are very common. There are probably 15 different ways of implementing these but when you're talking about an all Flash array, then what is the most optimal way to implement these data services from a Flash perspective? Even as a simple thing as parity protection, a snapshot, a D-Duke, a compression, how can you implement it in the best possible way from a Flash point of view, right? So that is what is happening from a product side. Now, when talking to a lot of customers, we all... Let me interrupt if I may. So obviously all your competitors who are born all Flash would say the same thing. What's different about ExtremeIO? So I talked about some... Let's take an example of a D-Duke for example, right? So D-Duke, there are, as I said, there are multiple different ways of implementing it. As the one way to implement it is as the data comes in, you store it on Flash because that's the fastest way to do it, store it on Flash, and when the array is less busy, you go ahead, start a background process, implement that D-Duke, and then store it again, right? So there are a couple of problems that happens there. One, it works best when it works well enough when you're working with something like a hard disk drive and you want the best performance from an application perspective. But then from a Flash point of view, think about what you just did. As the data is coming in, you store it once, and two, when you deduplicate it, you store it again. So as we all know, there's an endurance perspective of Flash that we always have to take care of. And two, more importantly, when you implement it as a background process, the assumption is the array will be less busy at some point of time when you can run that background process. What happens in this 24-hour workload scenario where the array is never less busy? Now, in Extreme IO, we understand that those constraints and say, no, we don't want to do that. As the data is coming in, we want to deduplicate it as it is coming in before we ever store that data on Flash. In Extreme IO, we guarantee that we'll never store the same data twice ever on Flash. If the data comes in, if we see that it is the same, we'll never store it again. So from a Flash perspective, yes, it is happening in memory. You get all the performance benefits. The more deduplicate you do, the more performance you're going to see. But from an endurance perspective, we recently came out with some business programs like seven-year endurance protection. Nobody else in the industry can do that because we have confidence that the kind of architecture that we have, SSD endurance should not be a concern. Now, this is just one data service. I can go in and talk about. So you could give me examples on many, many data services of how you've thought about it differently. But that one example is a good one because if I'm a CFO paying for the array, I don't want it to be underutilized. I want it to be busy, especially if I'm paying up for performance. So, okay, so that makes sense. You were about to talk about it, cut you off, but you were about to talk about the customer side of things. Please continue. So a lot of the conversations that we are having these days, I was talking to one customer where in the next, they are building a data center for their next 15 years, and they don't see a single spinning drive in their data center in the next 15 years. Again, that's just one example. A lot of our customers are going towards an all-flash data center. Now, what that means is an all-flash array is not a point solution anymore. It needs to work with the whole ecosystem. It needs to work with everything else that exists in the data center, whether that is a common management interface that works across the data center, whether that is an easier way to consume storage, and that's where integration with something like Viper and Viper SRM comes in. Okay, so George, let's talk about that. So what is the relationship between Viper, Viper SRM, and ExtremeIO? Well, first, starting with ExtremeIO, again, it's now a supported array under Viper. So we've been on theCUBE many times talking about Viper, the general premises that we can represent your physical resources in a software layer that you can then manage according to policy, and you create different performance pools of storage and provide that into a self-service catalog where users can actually go in and very easily consume storage resources as easily from a complex enterprise environment as they could from a public cloud provider. And now ExtremeIO can be part of those tiers of storage as a high-performance block pool for mission-critical applications. So unlike public cloud, that is a very homogenous standardized infrastructure which makes it inherently easier to automate and provide storage as a service, Viper allows us to take every resource supporting mission-critical applications whether it's file, block, object, and provide that same cloud experience, that same simplicity of access and automation, but do it for a complex heterogeneous and multi-vendor environment. And Viper SRM is integrated very tightly with Viper Controller in that it gives you the complete view of all of your physical resources, what applications are running on the discrete physical resources, what capacity is being used, what capacity isn't being used, and being able to blend that with Viper so that you have a complete view of all your virtual resources and your physical resources. So you're talking about integration, which is important, so what customer said to me today, I'm a CIO, I don't want to be the chief integration officer, I want to be the chief information officer. So I have to ask you, because you mentioned all your friends before, all the arrays, other arrays, the competitor arrays that you're supporting. Well, a customer of an EMC to EMC, a Viper to, an EMC on Viper, is that going to run better, however we define that? And if not, how is that possible? So talk about that a little bit. Well, really, it doesn't really change how the storage arrays actually run or any of the functionality of the arrays, because the Viper controller is simply a management and abstraction engine. The application compute layer communicates directly with the underlying storage resources as it always has. Viper is actually just making it easier to consume the storage and to automate the provisioning and provide centralized management of everything. And we understand it's a multi-vendor world, all our, many of our customers, in fact, everyone has different storage arrays that they've bought over time to service particular workloads. And we're not trying to displace anything, we just want to bring Viper into the environment to make it easier to manage anything. So, and some would say that even sometimes just buying from EMC, it feels like a multi-vendor world, right? Because there's a lot of different products. It's a big, complicated portfolio. Of course, the transaction is with one vendor. So my question is, is you've taken an approach that puts the subtraction layer in between, I've said many times, it consolidates the stovepipes. That's something that your customers want and everybody wants in the industry. Is there a trade-off from a performance standpoint, or does, through things like ExtremeIO, where you really need the performance, obviate that abstraction penalty, if you will? Right, and that's just it. There is absolutely no performance penalty at all. We've made it simpler to manage and simpler to consume, simpler to report on it. But we're actually, we're not intercepting IO, we're not actually handling the storage arrays and the compute layer work as they always have. So there actually is no trade-off required in performance when using Viper Controller. It's actually just reducing the number of manual steps to provision storage. In fact, on average, of about 63.5% reduction in provisioning times for storage, even across multiple vendors' arrays. So Avashek, when Viper came out, it was a big discussion about separating the control plane from the data plane. Do you think data planes, data services, of course, a lot of the control activity was buried inside the array historically? How should customers think differently about the stack of the future? So the way I like to think of it is we talk about all the data growth that is expected to happen in the next five, 10 years and everybody has multiple exabytes of data that will be created, right? And they're probably low. Right, exactly. So the idea is with this kind of data growth, with this kind of the explosion in data that is bound to happen, right? So things need to be much simpler, right? So when I talk to customers from an extreme IO perspective specifically, we say that we have made things as simple as possible. So George was talking about provisioning. From an extreme IO side of things, a lot of the decisions that the customers need to have taken previously, those are being built into the product itself. You no longer choose which SSDs your data lives on. You don't choose what kind of rate type. You don't choose whether I enable thin provisioning or not, Ddupe or not, compression or not. All of those decisions are built in. So you talked about the new way of consuming storage. It needs to be as simple as possible, right? Viper makes it even simpler in a heterogeneous environment. Now customers don't need to choose what kind of storage array they need to go on. They just specify certain characteristics of the storage they want, and Viper, for example, will automatically be able to choose what kind of storage array it needs to go on. So one of the big things from my perspective is it needs to be much simpler. Gone are the days when you need to have a PhD to do all the performance tuning and decide how much cash you want to assign and what is the rate of lead and write cash, sequential random IOs, these storage needs to be able to take care of that. Okay, so that's VMworld eyes, this discussion, right? So I heard this morning, we got OpenStack, we got new Docker containers. So there's a lot of discussion around orchestration. So sometimes it's confusing for people that might not be practitioners, right? If you're the CFO or maybe even a line of business person you hear about all this stuff, you're writing checks. So I wondered, George, if you could help us sort of squint through all the complexity of all these layers, these orchestration layers, the control plane, now OpenStack's in the equation. How do you guys sort of simplify that discussion for customers? Sure, well I think of the Viper software has two primary components and they can almost be thought of as two separate products. There's a Viper controller and there's a Viper services. Viper services can be thought of as just a software defined storage engine. And really it's just like any other array provided by EMC in that it includes a software stack that exposes protocols for IO on the top. It has a storage engine and then it writes to a persistence layer underneath, whether that's solid state drives or hard disks, JBOD or file arrays. So it's a truly software defined storage engine that allows you to do things like object, HDFS and block via the scale IO software and have complete hardware independence. The Viper controller software is kind of the management and abstraction engine that allows you to represent your physical storage resources in a software layer and make them available that way users can provision storage or request storage based on a class of service rather than on physical devices. And we integrate with VMware or OpenStack or Hyper-V, whatever cloud stack or data center operation stack you're using so that for example with VMware there's usually an individual VASA provider for every storage array underneath. And that will send a very hardware-centric profile to VMware to provision storage when you go to provision compute. What Viper does is it creates one VASA provider for all of the arrays that are under Viper management. And so those classes of service that you've built in Viper are now available to VMware so that when you provision compute you can provision from a characteristic based storage pool versus from a hardware-centric storage profile. So Viper exposes that metadata, if you will, those services up to the VMware level which ultimately will be a VVOL level presumably, right? Viper has its own self-service catalog that you can use or we can just integrate with VMware because most people are going to consume storage with compute through VMware. Right, okay. And so one last question if I may, where does Visan fit into this whole equation? Well, Visan, with Viper services we have the Viper block capability. And so Visan and people think of Scale.io and Visan is kind of similar technologies in that they are. Visan is a VMware-only implementation. It scales to 30-something nodes I believe whereas the Scale.io software can go beyond VMware and also it scales to thousands of nodes depending on how you implement it and what infrastructure. So, to Viper, Visan is kind of just another managed array under Viper. It's low-end and VMware-only and okay. All right, Abhishek, we'll give you the last word here. Thinking from a product standpoint, what should we be looking for? What should we be paying attention to? I don't want you to divulge obviously the whole road map but what kinds of things should we, should observers be paying attention to as milestones or indicators of progress and success? So obviously from a data services perspective we announced a bunch of new data services that are coming on. So compression, for example, comes very soon. As I said, we are looking at Extreme I.O. as more of a solution rather than as a point product aimed at solving a particular problem. So you'll see more and more of these integrations. So today we talked about Viper. There are a bunch of other EMC and non-EMC products that we are integrating Extreme I.O. with. So you'll see a bunch of those happening over the next six, seven months and more depending on what the requirements are. So expanding from an array perspective to the amount of data you can store, the amount of the flexibility that we'll be able to provide our customers. So improvements in all of those, right? So at a high risk. All right, good job. Thank you guys for coming on theCUBE. You guys got a lot of action this week. I think you got a big event coming on this evening or tomorrow I can't even keep track of all. But lots of customers and some congratulations on the success and thank you again for coming on theCUBE. Thank you. All right, keep it right there everybody. We'll be right back. This is theCUBE. We're live at VMworld 2014 at Moscone in San Francisco. We'll be right back.