 This is Dave Vellante, we're here at day two EMC World 2013. This is the cube where we extract the signal from the noise. We bring you the best guests that we can find. We like to talk about tech athletes. I'm here with David Floyer, the CTO of Wikibon, my personal tech athlete, and Syria Varanasi, who is the vice president of engineering at EMC. Within the new software-defined storage group, the Viper group, you were employee number one, I understand, of Project Born. You were essentially brought in to really get that project started, right? Yes, yes, I was. I was hired in from VMware to start this project. Yeah, okay, so let's take us back to the beginning. When was this now? We talked about a couple years ago? November 2011. November 2011, so. What was the language that was even used back then? Was it software-defined storage? Was it, hey, we have this idea? What do you think? Take us back to the instantiation. So back then, we were looking at two trends. The biggest trends we were looking at was, we had heterogeneous storage that we have in the enterprise, and we were thinking about what does it take to convert that to a private cloud? What does automation mean? And then we were thinking about taking objects to the next level and what do we need to do to actually provide that service to service providers? So those were the big focuses, if you will. Okay, so the name, Project Born, was it, wait a minute, for that's Jason Born. Is that right? It is, it is Jason Born. Okay, so it's a deadly killer. It's all, it's stealth. It's very efficient and adaptable. Those are the characteristics that you guys, it's survivable, right? That's right. Okay, so then, so EMC brought you on from VMware. How did Project Born evolve into Viper? So you know, before it started off being born, it started off being Storage OS. The underlying platform, if you will, on which you can lay on services. So a plan from the very beginning was to actually build a platform that does two things, provide automation and think about new data services that people want. So you know, along the way we thought, okay, Storage OS, that's very blah. We need a new name. So we had a lottery, if you will, on names and Project Born was the official name that we ran under. So that's how it came about. Because there are Storage OSes out there today, right? So what's different about Viper as a Storage OS, if you will, as a platform, than every day run of the mill Storage OS of which EMC has a number of them? For one thing, we're not tied to any platform. So we sit as a layer about any platform. We're completely on software. We manage a whole bunch of heterogeneous arrays that have their own OSes on it. And what we actually do with the platform is we try to provide services that can leverage services that are written on top of our platform across all the physical infrastructure. So that's the big focus for us. So we're actually not buried inside any system, if you will. Okay, so now your baby is born and you're seeing this product come to market. David Floyer and I were trying to, again, unpack Viper yesterday. So you talk about separating the control plane from the data plane. Why is that important? And what does that bring for your customers? So there's two challenges that we see when we go into and talk to customers. The first is they buy Best of Breed equipment today. And Best of Breed could be EMC arrays, third-party arrays, who knows what they buy. What ends up happening is they actually provide solutions that work for everybody, but managing this is extremely complicated. So the first need for the customers, can I provide automation to make it simple to manage existing infrastructure? That's the first big push for us. The second thing is, as you've heard throughout the conference here, people want to know, hey, yes, we have block and file and we consume that, we know what to do, it's complicated, but okay, I understand what to do. For things like the new data services, Bead object, Bead HDFS, how do we adapt? What do we need to do? How many solutions do we need? So we wanted to provide a single place where you can do both, and that's fundamentally... So, why? So do you want to jump in there? Yeah, sure. So you provide a set of services at that layer. So the automation and provisioning and all of that is at that layer. So where do you draw the line? For example, you could put replication there, or you could put send provisioning there, or you could put ODF from Microsoft there. Where do you draw the line between a service which you would expect to see, like for example replication, and would be useful? So for example, you take Invista, that had the services, common services for all the stuff that were underneath the virtualized level. So, what's your thinking about that? So the first piece of the puzzle for us, if you will, is physical infrastructure already contains appliances, if you will, where we can solve similar problems, right? You've mentioned Invista. So we have Vplex, which does the same thing. It sits in the path and it's an HA product. Yeah, it doesn't do much of the services, though, does it? It leaves that. But you're just giving an example of an appliance. That's right. So you have Vplex, which is actually a storage array, but it also provides these services about HA and availability. You have things like Recovery Point that provide us data protection you can copy from an array to another array. So wherever we can, the hardware underlying infrastructure, we try to leverage it. If it's not possible to leverage it, then we'll try to augment that with services of our own. That's the first piece of it. The second thing is, you know, we have solutions that actually provide consistency to applications and so on for individual physical arrays. So we provide a common set of APIs on the system so you can provide the same services across all the infrastructure, right? So that's what we do. So to answer your question specifically, do we draw a line anywhere? Not really, but we try our best to leverage what we have to get the best possible solution. But for example, snapshots will be, to me, quite a good thing to have above the line. Absolutely. To be the same across. So we provide a snapshot API. Okay. And when you take a snapshot against a Viper controller, the snapshot is implemented across any of the physical arrays that we support. So all those solutions we provide as a single place you can consume. So I have a question on Twitter. The question is, so, just clarification, is Viper an appliance? Viper is a software solution, so you download it as an OVF on ESX. So it's not, it's a software appliance, if you will, but no software. So it's a software appliance, if you will. Okay, but it's not, it's not applied. It's no hardware. So then the obvious follow-up is, okay. And it runs on the VMware. What does it run on? It runs on a virtual machine. It runs on ESX. Right. At GA, it runs on ESX. Okay, great. So that's the sort of, you've used the earlier example of an appliance, you used Vplex or any appliance. That's the difference. It's a software-only appliance. That's right. This is fundamentally, the platform is actually just purely software. It's built for scale-out and availability and so on. And as such, you can download it from our website. That's what we built it for. Is there anything out there in the industry that is comparable in concept even? Or is this a first in your view? You know, I haven't run into any, I'd have to admit. Yeah. So what about OpenStack or things like that? I mean, there they've defined a set of services and then people come in, for example, with SolidFire and they've added some extra things. So it seems to net up a lot of service there. You're saying OpenStack is a platform with an open set of APIs that can... Yeah, with the individual, the APIs that get tweaked. So, conceptually, it sounds similar. What about that, is it? So, you know, if you think about things like OpenStack or VMware, DynamicOps, VCAC and so on, these are cloud automation stacks. They are orchestrated over compute network and storage. So, what we provide is a storage platform which plugs into these stacks. So, for example, we have a Cinder plugin with OpenStack, so you can, if you're an OpenStack user, you can actually use Viper and stitch together the compute network and storage. Yeah. Okay, right. Okay, and so where are we today and where is this evolving? So, David Goulden kind of took us through the roadmap. We had a demo, you had the CTO, UBS, gave a little demo of essentially provisioning VMAX, and then promises of object interfaces later this year and then into the roadmap in 2013, can you talk about that from a technical perspective? What, you know, align what we heard there with what you're working on? Oh yeah, so, you know, it turns out it's total alignment, luckily for us. So, we have, obviously we have VMAX that we demonstrated. We have VNX, both file and block. We support Icelon, both NFS and SIFS, and third party, we are demonstrating NetApp. That's what we have. So, just to show that, you know, customers do have heterogeneous environments and they want to automatically install all of this. So, we do support that. We will have Vplex and RecoverPoint when we go out and Object. So, we have Object running over in the Viper object interface. On the Icelon, is that? It runs on Icelon, in fact, runs on any NFS filer, if you will. And we'll support S3 and Atmos and Swift APIs. And here, we're going to be very compliant. We're going to say it's wire format compatible, so you don't need to change your applications as it should just work. So, what was the hardest part from an engineering standpoint that you had to, you know, break through to make this a reality? So, you know, as we defined it as storage OS and we went to Born and then we went to Viper, at each step of the journey, if you will, we went and talked to a customer and said, hey, here's what we have. We've solved a provisioning problem. There's like, that's only one-third of the problem. I was like, all right, what's the next one, sir? You need to go program the sand. So, we go program the sand. It's like, you left the last mile out. What's the last mile? Close the provisioning with the server. It's like, okay, we'll close the provisioning with the server. And then once you go there, they'll tell you, you know, you need to replicate or else, you know, people put data, they want to move data, do something about it. So, the hardest part for us was each time we went in with customer feedback, we just got more. And we had to take a holistic view and say, we need to get this much done to make it compelling to the customer. I think that was the hardest part for us. Yeah, so storage management and data management and volume management is hard. I mean, it takes companies decade to build that out. So, where did that IP come from? Was it a combination of new stuff that you built? Or did you pick and choose from parts of the EMC portfolio? Talk about that a little bit. So, Viper, the controller aspects are completely homegrown. We use open source components, but they're truly cloud-scale and we built it ourselves. The object piece as well is completely homegrown. We had the Atmos as a starting point, so we used the Atmos APIs, but the architecture itself was quite different. So, all of this was organic. And you've talked about it being open and all the APIs are open. Does that mean that anybody can use them? Does that? Yes. And what about the openness of the stack itself? Are you selling that? Is there a license fee for that? How's that going to go to market? So, that is a discussion best for marketing at this point. But I think at this point, we're thinking of licensing it out. So, we're thinking about various options there. Yeah, we're going to get into some of the pricing a little later on. So, and we'll, in fairness, stick to the sort of technical pieces of it. So, I wonder if we could break down a little bit more when we talk about separating the control plane from the data plane. And David, you and I talked about this a little bit last night, but so, let's focus, let's start with the control plane. What are we talking about here functionally? What are the functions that are on that side of the separation? So, it's everything that you do for storage management. So, it starts from provisioning. It starts from provisioning your replication, your backup. It starts with thinking about your network and how you program it. So, your sands starts with it. You think about your host and how you consume your storage. The entire life cycle completely. So, when we talk about the data path, we're talking about the servers of storage, IO connectivity. We're not in the data path there. Very much by choice for block and file, because some of these protocols are very latency sensitive and you don't want to insert yourself if you don't have to. So, that's the control aspect. So, you're a separate control path too. Yes, yeah. So, go ahead, David. So, you've set up all of this environment. Where do you see it being adopted, mainly? I mean, obviously the enterprise could take that as a solution for just the provisioning of storage, et cetera. There are other products out there that will do similar things to that. Where do you see it? Where are you focusing this? Is this on the enterprise? Is it on the cloud providers? Or do you see a hybrid platform with some of it on a cloud provider and some of it in the main data center? What's the, where are you selling this to? And who do you think are going to take this up? We've spoken to large enterprises as well as service providers. And I think the easiest way to think about this is anyone who has heterogeneous storage and really wants to simplify how they consume storage. That's the perfect place to use a product like Viper. So we do two things to any enterprise or a service provider. We help you manage the today and we help you provide solutions, we help you by providing solutions for the tomorrow. So we think about automation complexity and how we simplify and we think about object, your HDFS and other interfaces that you may need for your business tomorrow. So a platform like that, you can use it anywhere. We also provide, as part of the solution, a way to report across all these various different solutions, your file, your block, your object, if you will, pertinent. That's very powerful, right? That's not a solution you get every day. So honestly, heterogeneous environments where you want to use, you want to solve your complexity today and want to expand tomorrow. That's perfect. All right, Surya, thanks very much for coming on theCUBE and taking us through the story of born to Viper. Congratulations, a lot of hard work. And we'll be watching. All right, so this is theCUBE. And thank you for watching. We'll be right back with our next guest. We're live from EMC World 2013. All right, thank you.