 Okay, we're back and this is Dave Vellante at Wikibon.org, this is theCUBE, I'm here with David Floyer, the CTO of Wikibon and we're unpacking Viper, EMC's big announcement, their software-defined storage announcement. This is SiliconANGLE's theCUBE, this is our fourth year here at EMC World and this is a spotlight, a drill down on Viper, Viper the big news of the show. Otherwise known as Project Born, EMC has been releasing bits and pieces and actually quite a bit of detail about Project Born starting around last November and now we've seen it come to fruition here at EMC World. Sal DiSomonis here, he's the chief architect of EMC's ASD which is their advanced software division. Sal, thanks for coming on theCUBE. Thank you for having me, happy to be here. Yeah, so congratulations, the baby was born, we were just talking to Suria. Yeah, never won on Project Born, yeah, so. So yeah, but of course now the fun's just beginning, right, and when you put something out like that you never know what the reaction is going to be, it seems like it's been very positive. Of course you've got the competitive aspects coming at you which is good, that means you got people's attention, you don't ever want to make an announcement where nobody pays attention, so again congratulations. So what is your role within ASD and then we can dig into the whole Viper thing? So my role as chief architect is to look across the portfolio of products that we have which now includes Viper, but also includes our storage resource management, our network resource management, and our existing object platforms, Atmos and Centera. And it's kind of my role to make sure that as we build out these different products we're actually marching towards a technical strategy that will set up our customers to solve problems that they have today and also the problems that they're going to be facing in the future and to look at the macro architecture as this evolves with a particular focus on the APIs and the ecosystem because as we move into the cloud era with the software defined data center from a storage perspective it's really about APIs and how you present the programmable storage infrastructure to cloud stacks and also how you present these newer data types object, HDFS, et cetera to the app developers. Yeah, so I remember when David and I started Wikibon with some other folks we were almost, it was like around 2006 we were obsessed with what was going on inside of Amazon and Google in particular. And we just looked at it and said wow this is really interesting and fascinating and it's probably the future of storage and put a lot of emphasis on object and scale out and the like. And now as a technologist I'm sure you looked at those guys as well that had more resources than we did to really dig in. What did you learn from observing some of those large hyperscale guys and how have you applied those learnings? Well I think from an architectural standpoint there's a whole new set of programming models for the app developers that evolved and a whole new way to think about and design infrastructure for hyperscale. And that goes to the way that you construct the hardware to the way that you build the software stacks that implement the infrastructure and the levels of automation that have to be present in order to make it practical to manage these very large scale environments in a cost effective way meaning with fewer people. So there was certainly lots of cleverness and ingenuity that those companies put out. The thing that when we looked at it though it was okay it's one thing to be able to create such an infrastructure for one company. For one app. For one app. From an EMC standpoint we're trying to build infrastructure in products that we could sell to a wide variety of customers. And what does it really mean for a company like EMC to be able to take these learnings both from the programming model app development standpoint and the infrastructure and translate it into something that is frankly usable by enterprise customers who are not starting from nothing. They have a significant base of installed. They have lots of existing applications which are not going to change. Yet they're also trying to build out a new generation set of applications. They get more efficient in the way they operate. So we're trying to take these two different worlds of the traditional enterprise IT and the principles of kind of hyperscale cloud and cloud apps and figure out a way to bring our customers along in this journey. You're kind of on a parallel path with your customers. I'm going to make an observation. You tell me if you think I'm crazy or it makes sense. In other words, your customers are observing the hyperscale guys as well. There's new programming models saying hey maybe we can borrow some of that stuff that's seeping in but they don't have a maybe a zillion PhDs running around so they need some help. Enter you guys. And I think there's really two things that these enterprise customers see. One, wow, these guys manage really large environments with not that many people and it seems like it's pretty fast to spin up infrastructure. How can we achieve the same thing? So that's really a kind of cost and automation. And second, with the explosion of data that's coming out of these social environments they're all looking at this and saying wow there's probably information there that we can glean to help us gain more insight to our business. How the heck do we even start down the path to trying to leverage it? Because it is a whole new technology base, a whole new way of thinking about designing your applications and programming them. And in many cases they don't have they don't have the grooves on the staff with that background. And so part of it is looking to companies like EMC to help them in that journey. So what are the principles then that you extracted from that learning and from your own experience? What are the principles that you apply? What are the, your rookie manager comes in? How do you tell him what are the key principles that he's got to adopt? So I think the first thing that we have to ingrain in anyone who's going to work on this product is this whole notion of the kind of cloud architectural principles in terms of being highly available, highly scalable, non-disruptive upgrade. If you go look back in the history of storage, non-disruptive upgrade is not like something that we got so well, right? So kind of fumbled that one. I'm being in the operation. Yeah, so, and then also from a building products that are appropriate for service providers around multi-tenancy and security access. So there's a whole new set of architectural principles that we have to ingrain into people. Second is from the design of the system, the thing that matters first is the API. It's not the UI. In many cases in the past, certainly with storage management, the first thing is let's create some UI. And then as an afterthought, we'll try and figure out the API. Here, it's sort of the inverse. Being a programmable infrastructure is number one, you need the API and so the criticality of the API. And then from a user experience standpoint, it's really mobile then web, then desktop, right? Sort of changing the priorities. And these are some big changes that our customers are facing in their business, but even EMC as a business that has evolved over the past several years to become more software-oriented, more cloud-oriented. These are some of the principles that we have to push. So have you created an environment where you can be managed by other? Absolutely. So again, part of the issue with Viper was to solve the storage problem, but to do it in such a way that the storage subsystem can seamlessly plug in and be a part of a broader solution. And so back to the API first. The first thing that we focused on and what my principle at the beginning, what my principle focus was, what does the API need to look like? Let's start with what's the logical model of storage that we want to present in this new way for traditional types like block and file, and also for new types like object and HDFS. What's the management model that's constructed in API around that model? And then build underneath that API to fill it out, and in parallel, create all the connections that are needed to tie our API to the things that people use today. So people use VMware, they use OpenStack, other things, we just want to make it so that the Viper controller, like out of the box, just plugs into those. You don't have to write adapters, you don't have to do all kinds of things. And from an application programming standpoint, from an object point of view, it was not about coming up with yet another object API. It's, there's a ton of applications already out there written to Atmos, written to Amazon S3, written to OpenStack Swift, written to Centera. The last thing we wanted to do was create, well, yet another object. So from an object API, the strategy from the beginning was, let's just support the interfaces that are already out there. So these applications that have already been written can just be pointed at Viper and don't have to change. And then we extend those APIs with additional Viper unique capabilities like the object on file, where once you've moved your app over without having to change it, now that you're storing your data in Viper, well, there's some unique capabilities you can glean out of it like the object file access and give people the opportunity over time to make the changes to their application to leverage this. It's really all about reducing friction and making this thing just plug in and snap in. And again, from a storage world, there's always been a lot of friction in the API and automation standpoint. Yeah, and go ahead, David. So obviously one of the key things that you're doing here is competing with the OpenStacks of the world and things like that long-term because. So I wouldn't phrase it as competing. If we look at OpenStack, there's two storage personalities. One is the block store personality with Cinder and the object with Swift. The way Cinder is structured, that's just a programming interface that OpenStack wants to call into. There's got to be something on the other end of Cinder that can accept the request from OpenStack and do something useful. So you have two options. You could plug each array directly or you could plug the Viper in and have Viper manage all your arrays. And when you have lots of arrays feeding into OpenStack, that's actually a better way to do it because Viper can do a better job of managing storage. And even on the Swift side, I mean, OpenStack comes bundled with their own object store. But to actually run a geo-scale object store, you need much more than that. So for some OpenStack environments that are relatively small, you can go with the built-in Swift and it'll be fine. For other cases where you either want to leverage existing hardware or it's a much larger scale, you could deploy Viper and you're just OpenStack, just re-point it almost as another Swift server and nothing in the OpenStack will change you. So I think we're pretty compatible as a storage provider to these cloud aspects. Yeah. The point I was going to make was that the commodity price is the thing that is driving a lot of people towards that environment. The lower cost of, compute the lower cost of storage. And that's a very significant driver. I mean, if you look at the Hadoop world and compare that with the traditional data warehouse world, there's a 10 to one reduction in terms of cost. But when you run very large scale object stores, even on commodity hardware, you need a fairly sophisticated software thing to do that. And I think we believe the layer that we're building with Viper is a superior implementation with certain characteristics and there'll be customers that find that implementation of object preferable and, you know. So you're a big consumer of open source, right? And you're playing in the open source land. It's a little new territory for a MCI. You've always been a consumer of open source, I guess. We've been a consumer, but not been an advocate or a contributor. Yeah, that's it. A committer or a contributor, right. And I think with the work that we're doing with OpenStack, our adapter, you know, our Cinder adapters and whatnot will all be part of the standard OpenStack. So you're actually contributing to that. Oh, that's good. And there's even an ecosystem around Viper to extend it to program third party arrays that will be open sourcing some pieces of that. So even some pieces of the Viper itself will be an open source component to that as we actually roll it out. And if I just want to come back to the API for a minute. So the API sounds like it's a collection of existing APIs. You didn't have to reinvent that. For the object. Yes, right. It's an existing API. And then obviously a new API for Viper, the platform. Controller, right. So that, I mean, the complaint that everybody always has is every time there's a new API, there's a new controller, right? So you're breaking that trend. Right, right. Effectively, if you think about the kind of Viper, the controller API, this becomes the sort of one API you would need to write to to control storage. If you bring in additional types of storage systems or other things, natively they'll have their own set of interfaces. But if you're coming through the Viper layer, your automation and your orchestration above sort of never has to change even though you have a wide variety of different storage types. So you've been at this a couple of years now, actually banging code out. How hard is this to replicate? So it took us a while. And it took us several iterations to get it right. Even going back a little before the two years officially started. So the controller piece has very sophisticated logic to deal with traditional storage environments. That's going to be very difficult for anybody to deal with. And in the case of the object storage, there's really not many places that have built and developed geoscale services. And sort of several of the developers that we have have actually built, they've come from some of these cloud environments. So we have our own PhDs and rocket science building some of these things. And that's a fairly high bar and people never get it right the first time. So we're pretty confident with what we've built here. Excellent. Well, Sal, thanks very much for coming on theCUBE. We really appreciate the information and congratulations on getting the project out. And good luck. Thank you. Thank you very much. All right, everybody, keep it right there. We'll be back with our next guest. This is the deep dive on Viper. We're going to keep unpacking this. Keep it right there. This is theCUBE. We're live from EMC World 2013 from Las Vegas. We'll be right back.