 The Cube at EMC World 2014 is brought to you by EMC. Redefine VCE. Innovating the world's first converged infrastructure solution for private cloud computing. Brocade, say goodbye to the status quo and hello to Brocade. Okay, welcome back everyone live in Las Vegas for EMC World 2014. This is the Cube, our flagship program. We're going to go out to the events, to extract the signal from the noise. I'm John Furrier, the founder of SiliconANGLE. I'm John Michaels, Dave Vellante, co-founder of Wikibon.org. And our next guest is Manavir Das, VP of Engineering at EMC's Advanced Software Division. Welcome back, again this year. It's great to be back with you again. This is 2.0 for the Cube interview from last year's Viper 1.0, I guess you could call it 1.0, but a lot of conversation last year on Viper. First of all, last year I was super impressed by the slides. The slides were very impressive. Slideware was great, I mean the diagrams, how you guys thought about the architecture was really well thought through. And a little bit different than what I might have expected. So give us the 2.0 version one year later, you're out in market, you're out pushing the envelope now. Give us the quick update of all the quick highlights. Yes, and I think I would second what you said. The story was great and the story was all in slides. And what's changed in the last year is number one, we're in production with a number of customers. And two, we have really built out the platform to the level that we were intending to from the beginning. And we just had a stage delivery model. So if you recall last year when we came out, we said Viper's a storage system that can run on top of your existing storage devices like your arrays. What we've done now with Viper 2.0, it's a full-fledged storage system of its own, which means that it runs directly on the metal, it runs on commodity hardware, it does all the data protection, all of the IOPS itself, and it provides a variety of different protocols like object, HDFS, et cetera. But it's also modern in the sense that it's completely in software. And so from a customer viewpoint, you can take it as a piece of software and apply it on your own servers and scale it out as you go. And that gives you a flexible model. At the same time, we also announced the ECS appliance, which is really, it's exactly the Viper stack, but it's pre-bundled by EMC with commodity hardware because we think we're pretty good at sourcing effectively priced commodity hardware, and then we put it in a bundle that we provide. Jeremy Burton says, don't fight fashion. Fashion is elastic right now. The word elastic, being elastic is actually good too, if you can be elastic. So it's a box, it's not a service, it's not in the cloud, it's not a cloud service, it is a box. But it's an elastic box because the way Viper really works is you give it as many servers as you've got. It will lay itself out over all those servers and that's as much capacity as you get. The more servers you add, the more capacity you get. It so happens that with ECS what we've said is we'll put some servers in a box and give them to you, but that's just a unit. And so you're going to have as many of those boxes as you want, and you're going to get more and more capacity. The other thing also that was not, we didn't go into that detail in David Gouldin's keynote, within each of those so-called ECS boxes there's a number of servers. And if you open the door, you can keep putting servers in. So you can put one server at a time, two servers at a time, as many as you want, it's completely elastic. Right, so thinking about ECS, it seemed to me that, so you're drawing a comparison from a TCO standpoint with the public cloud, it would seem to, what struck me is that a lot of your service provider customers would like to take that box. Is that really where the target is, or is it as much sort of on-premise big shops wanting to duplicate the capabilities of the box? It is very much service providers, but there are two kinds of service providers. There's the one kind that we traditionally think of, which is I want to compete with the public cloud, so I want public cloud in a box so that I can offer it as a service, but there's also internal IT being a service provider. You look at a lot of the big enterprise IT shops, they're serving hundreds of internal customers building applications, and what they're seeing is, the internal customers are moving to the public cloud because it's more convenient and it's cost effective, and the internal IT customers we talk to, they're struggling with that because they're the ones saying no, no, you cannot go to the public cloud because of regulation, compliance, and all of that, but they don't have a weapon in their own arsenal to offer to the internal customers, so for them, the ECS is a great model because they rack and stack these, and then they effectively offering a private cloud version of that public cloud just for their own set of internal customers. And you've incorporated things like Chargeback in there. Yes, it's all built in. Do you expect a lot of customers will take advantage of that? I absolutely think so, and that's definitely evident from our customer conversations because you think about internal IT, you know, you've got the finance department, you've got the HR department, everybody's consuming, and they have to be built in some fashion, so that's a Chargeback model. And of course, for traditional service providers, you know, exposing it out, they clearly need Chargeback because they've got third parties who are creating accounts, right? So definitely see that, yeah. So one of the things that all the CIOs I talked to pretty much look at, Amazon's web service, and saying we want some of that, they all got a little nervous because there's a lot of issues involved around being fully enterprise grade, and they're working on that, they're trying. You guys are kind of coming with the hybrid cloud, but they're all kind of saying I want OpenStack, and I always ask, David, I always talk about this, I always ask the CS, why do you want OpenStack? I want to look under the hood, I want to be able to play with it, I want some comfort. So in a way, it's a hope, it's a dream, it's a bridge to the next platform. OpenStack is one of those I call maybe a small bridge because of the bridge that you guys are promoting. So what is the OpenStack support? You guys, I saw some buzz about Cinder, is that official, what role do you guys play in OpenStack? So that's a great question. So I think number one, we do see that growing movement and Viper philosophically from the beginning has been about choice. So what we've done with OpenStack is two levels. Number one, everything in Viper is exposed through REST API, okay? And so in that way, it is integrated into the full orchestration system of OpenStack. And actually, we've done that work ourselves, it's available, you can take Viper and plug it into the rest of your OpenStack environment. So Viper becomes your storage plane. The other thing we've done is at the bottom, so when we came out with Viper, there was the question about there's a plethora of different storage devices and data centers and how do you build support for all of them? And so we kind of had this sort of plug-in model at the bottom. And what we've done with OpenStack is we've said, okay, there's an evolving standard like Cinder which a lot of people are using. So what if we built in natively support for the Cinder model at the bottom of Viper? And so what this now means is you take any storage device, if you've got a Cinder plug-in built for that thing, then Viper will automatically be able to talk to that device and integrate it into the storage pool, right? So that's the kind of integration. Another example at the top is OpenStack has an object protocol called Swift, right? So Viper object natively speaks Swift. So if you've got any application that is working with OpenStack Swift, it is also going to work with Viper object right off the bat, right, without any modifications. So what kind of, what kind, you run an engineering organization, you've got developers working for you, all software guys, what kind of resources can you commit? Are you wanting to commit, are you able to commit to OpenStack? So I think for us it's an important direction, right? So from that point of view, we don't have a problem committing resources to it. I think the interesting issue with OpenStack is that we have to have a way of participating in that ecosystem. And it's certainly something that we are eager to do and we're just trying to work through sort of the mechanics of how that gets done. But we certainly build Viper with a view that we're interested in contributing. So are you negotiating? Is that what's going on now? Or are you sort of, I mean, not that you're negotiating, but you know what I mean, are you trying to sort of, when I say negotiate, sort of find the right path, figure out where to add value, understand where you're going to be able to have the biggest impact. So I have an easy answer to that question, which is I'm the engineer, so I don't get paid enough to solve those problems. So what I'm making sure of is that we build the product in such a way. We write the code in such a way that it's friendly to that. And then, you know, the others decide what to actually do. Okay, but you're applying your engineering resources to that point, not necessarily saying, okay, go off and write OpenStack. Correct, correct. We're building our code with the view to the fact that like every developer I hire on my team, the first thing we tell them is you have to have pride of ownership. The code you write is like the painting you produce, right? That means when other people look at it, you want them to feel impressed by what you've done. You got to have pride of ownership. So, you know, we write all our code that way, right? With the view that anybody could be able to see it and feel like, wow, these guys really know what they're doing. How do you evaluate good code? What are the metrics you use? Simplicity. I think the only things that truly work at scale are simple things. So when I interview an engineer, and he describes to me a really complex algorithm that he put together to squeeze the last 1% out of something, you know, I'm not impressed. You send them to the competitor. Yes. And when they talk to me about how they boil something down, do its essence, and implement it something very simple, I get impressed. And actually, one of the things I'd love to talk to you about is our geo-replication algorithm, which is an example of that, right? And so, yeah. Great, let's talk about it. So, I think, you know, that's one of the things I'm particularly proud of with Viper because we think it's truly unique in the industry. If you think about, you know, how you protect your data across data centers, right? So you want to protect yourself from, there's a meteor or whatever, you lose an entire data center, and you got to have your data elsewhere. How do you do that? So there's a fundamental trade-off, okay? So on the one side, what you do is you say, I take my data, and I locally protect it. I do some amount of RAID or erasure coding or something within my data center. And then I take this whole enchilada, and I copy it a bunch of times into other data centers, okay? Now, if I do that and I make full copies of my data in different parts of the globe, the advantage is that if I lose a full data center, I've got a whole copy of it elsewhere. And furthermore, even within a data center, if I lose one disk or two disks or one server, because I did local protection with erasure coding, I can reconstruct the data without having to go to other places. It's very fast, but it's high overhead because I've got all these copies, right? The flip side of that is what is called geoerasure coding, where you take that same local erasure code, but instead of spreading it across servers in one site, you spread it across servers across many sites, okay? Now here, the advantage you've got is that the overhead is much lower because instead of full copies everywhere, you took your original data and you sort of spread it across, okay? But the downside of this approach is, now imagine I lost some disk drives in one data center. In order to reconstruct the data, I have to fetch the rest of it from every other data center. Now I've got WAN traffic, right? So it's a fundamental trade-off, and I think the state of the art is- Cheap but slow. Cheap but slow, right? And so the fundamental trade-off the industry is at with the state of the art is I got to pick one or the other. And every storage system you see out there, all these storage startups, et cetera, they have a long menu of geo capabilities and it's all or, either you go with this and it's good here and bad there, or you go with that and it's bad here and good there. And the algorithm we've invented for Viper is actually the best of both worlds. So we have a model where we spread the data in such a way that we've actually got full copies of the data. So you don't have to go across the WAN. And yet in terms of overhead, it's as low overhead as anything you would do by distributing your erasure code. And so that's unique instead of the art. But what I'm especially proud of, David, is in terms of simplicity, if I were to actually take an engineer and describe the technique on the whiteboard as I'll be doing in my sessions at EMC world, they would look at me and say, there's nothing intelligent here. Duh, why don't I think of that? And that's my whole point. Those things work well at scale. So this is math. This is new math. New math. Yes, new math. Organic built in your, in your group. Yes, yes. Not something that you borrow somewhere or buy in somewhere. You know, we've patented the heck out of it and all that kind of stuff, of course, but yes. Okay. So how hard is it to pull that off? I mean, explain to the folks, I mean, you said you're most proud of it. Yes. What's so hard about that? The full of geo, the geo-distributed with multi-site with protection. Right. Because if you think about it, right? Whenever you build a system where you're balancing two extremes, right? The thing that you only get by having done this before is what is the right balance point, right? I would say most things in technology as in life are like an 80-20 game. You're never going to get 100% of both things that you need, right? So you build a sort of a curve where on this end, I get 100% of this and 0% of that. And the other side is flip. And I want to find that point in the middle that says, okay, I'll get 80% of both. And that's a great solution. And so the art, if you will, here in this computer science is, how do I find that right place on the dial to get 80% of the effect of each? And that's sort of the difficult thing. Thanks so much for coming on theCUBE. I really appreciate it. Great technology. Again, last year, you know, we kind of joke. And we love to call it Slyware. We're impressed with your architecture. You guys put some meat on the bone, some great science behind it. Computer science, some data science, some engineering, obviously with services is fantastic. I'll let you get the final word in. Explain to the folks out there this year within your group, why is this trend right now so important? What is the main thing that's happening in the marketplace that's enabling you guys to capture this opportunity? I think people are realizing that it's not just enough to have data, but data is of no use if I can't actually do things with it. If I can't do things like analytics on it. And so in order to take advantage of that trend and to prepare people for it, we've built a storage system that says all your data is sitting in one place. It's a very high-scale system to ingest data, but it's also a very high-scale data warehousing system on which you can do analytics so you can extract the most value out of that data. And I think that's really the trend that we're after. So you think customers want real-time actionable insights? I think they want insights into the data. And they need a system that can give them that, yes. And thank you very much VP of engineering, tough job. I'm sure you got a lot of pressure on you. Doing a great job. Thanks for coming inside theCUBE. As always, fantastic conversation. Viper 2.0 and more software-driven, software-eating the enterprise. This is theCUBE. We're doing our best to broadcast that software and that data to you right back after this short break.