 Hi everybody, we're back. This is Dave Vellante at Wikibon.org and this is theCUBE, Silicon Angles Continuous, live, exclusive, independent production of EMC World 2013. We're really proud to be here. We've been going wall to wall since Monday. We'll have interviewed over 50 guests in three days. We've had all the executives on getting their perspectives. We've had independent analysis. We've had outside guests. It's been fantastic. So we're here now with a focus spotlight on backup. And we've been talking about backup as a service for quite some time now in the Wikibon community, all the way back really into the mid 2000s, sort of mid to late 2000s, we've been talking about backup and data protection as a service. I'm here with David Floyer, who's also with Wikibon, he's the CTO. And David, as I said, we've been discussing this topic for quite some time. And we're going to talk about backup going from an insurance policy to really data protection as a service. And even, as Guy Churchwood said earlier today, potentially the long pole for big data. These are some really interesting angles that I think we can take around backup. And let me start with the premise here, sort of the market angle. And you'd see this on the slide that we have put together. We've got some simple slides. You know, we won't PowerPoint you to death, but backup is broken. And data protection as a service is the fix. We've written about this extensively on Wikibon. We've done a number of videos on this. And the problem, essentially, is that backup is a one size fits all activity today. David, I want you to share with our audience, what does that mean? Backup, we talk about as an insurance policy. What do we mean by one size fits all? One size fits all is that historically, what everybody has done is say, okay, here's the backup window. We need to back everything up. So we will use a single process and we will back that up and we will then compress it or deduplicate it and send it off somewhere originally in tape, but now a lot of it is held on disk and maybe then to tape or to the cloud. Backup is that service. And to get it done the most efficient way, it was, I don't care what's there, we're just going to go through it as quickly as we can and get it off site so that the data is protected from any disaster. So to try to minimize RPO is the objective there. Minimize RPO, RTO was a sort of second level problem. Yes, you want to minimize that. And over time. We'll worry about that when we have to recover. Exactly. We'll see how it goes. Okay, so. But get it off site, get it. So the problem with that is you either are spending too much on an application or you're under protected, but it's very much unlikely that the. It's optimized. Yes. Optimized. You're giving, you're throwing an average at all the application portfolio. Okay. And it's an insurance. There's no value. Only when you have a disaster does it become a value to you. So there's a lot of pressure on to get it rid of it, not to do it necessarily or just to do it as quickly as you can. And testing of it is never that high priority. Okay, so it's insurance policy that delivers no tangible value. Exactly. Unless there's a disaster. Talk about the processes around that. They're very rigid. They're very hardwired. You typically have a backup application. Maybe even multiple backup applications. And you've got an infrastructure that is pretty much hardened, don't you? Absolutely. You, as you say, it's very rarely one backup. It's usually one here and one for this and one here because for a set of data you try and optimize a little bit. But yes, backup is complex. Backup is you need to have really hardened procedures. You do not want to experiment with anything that's working. And you take these long running jobs which are backing things up that can take eight hours or more. The less you interfere with it, the more you've automated it, the higher the chance that it will succeed. And even then, even with all of that dedication, there is still a high percentage of backup jobs that fail as one way or another before. And that particular day's stuff does not get outside. So it's expensive, no intrinsic value. It's rigid, and it doesn't work sometimes. Yeah, often. Otherwise it's great. Okay, so now the other thing about backup is that you often make this point that historical data cannot be accessed. What do you mean by that and why is that important? So you have all of this data out there, but the only way you can access that, there's two limitations to the access. First of all, you have to have the original application that put that backup data there. So what you're stuck with is forever having to keep that version of that software so that you can read it for however long you keep it. And the second is it is put there in the most efficient way from a IT perspective of streaming the data there. And you don't know what's there, except that it's a backup of a certain date and a certain time and maybe a certain application. So what you would like, ideally, if you want to be able to get to that data, is to know what has been backed up or what elements have been backed up. Have a way of getting into that data without having to restore all of it. And that's a metadata problem. And that is absolutely a metadata problem. Okay, and then we talk about backup as a service, as the fix, so what we mean by that, we're talking about essentially aligning SLAs with application requirements. So you can granularly set the service level requirement based upon the application. It is, you go from being a server to looking at an application and all of the application, the pieces around it and the databases around it and treating that independently. Obviously, often it's associated with other applications, so it's not quite as simple as being completely independent. But what do you want to be able to do is give the service to that specific application and dial it up, dial it down according to the business needs. As the business is paying for this, as the business has the best view of it. On top of that, you also want a dotted line from the security officer, the chief security officer, saying, okay, you may as a business not want that, but I need that for financial reasons. But with this method, you can then ensure that the business is paying for it and as well that it's meeting the audit requirements, the compliance requirements of the company as a whole. Okay, so I can now deliver, dial up, dial down is the way you described it conceptually, and then you can deliver this granular level of services. But then you're also saying that you've got to allow multiple ways of accessing historical data. Now we're talking about the metadata challenge, right? So there's two aspects about that. You want it to be independent of the original application that put it there. That's one aspect of that. So you want to be able to put it in a file system, if you like, instead of just a particular dump. And the second thing you want from it is to be able to know what's there and be able to pick out a particular file or a particular status in a particular time or a seat and bring that up independent of all the data. It's some kind of high speed metadata scan that allows me to figure out where the data is. Yeah, where specific data is. All right, so now let's switch gears here. Next slide, we're just having to put some questions forward and kind of put you on the spot. Just generically speaking, at a high level, what's required to deliver backup as a service? Well, it's a pretty radical change of all of the traditional backup industry. So first of all, what's required is that it's got to be something that can be changeable and done by the business itself. They have to say, okay, here's a class of service for of data and of servers, et cetera, that will meet this requirement. So I want tier one, very high level, RPO of a few hours, RTO of the- So essentially you're talking about allowing the users to define the policy and having an interface to allow them to do that. And a system that allows the language of the business to be ingested. Okay, and how about the historical data component? What's required to access historical data? We talked about metadata, is it simply a metadata problem? Is it more than that? Double click on that a bit. Well, within the backup, you've got a number of different components of that. You've got the backup system itself. You've got maybe a deduplication system. And then in parallel to that, you have an archive system, which is archiving your emails or archiving your documents or whatever it is. So at the moment you have a whole number of these different protection mechanisms and access mechanisms. What you want to be able to do is share the metadata between them in a application independent way. And there from that be able to say, okay, here's some data that I can use or here's some historical data that I can use to find out what weather was like on that particular day when people were buying it or whatever interesting thing that I can get from that historical data that's in that database and release that information so that it becomes an asset as opposed to just sitting there forever. So talk briefly about the architectural changes that have to take place in order to make backup as a service a reality. So first of all, you've got to have that layer of provisioning set up and have a standardization of provisioning across there. You've got to then have a set of products that will deliver the RPO and RTOs in the range that you want. And then you've got to have a set of products that will deliver that data to that application independent repository and get it off site and do all of the things. Okay, so how's this all going to be managed and what do you see as the roadmap for delivery here? Well, it's almost certain that what you would do is take it applications by applications and move them by relative importance or by where's most missed it. So that's what you're going to be doing is taking them piece by piece and migrating them over to a new environment. And obviously that you'll have a lot of the pieces the same as you had before as you want as little as possible to be changed in that process. But certainly you want to be able to put new applications in there, make sure all new instances have this as a service and then migrate your historical legacy systems. Are customers going to have to rip and replace to get here? No, well, that's the whole point. You want to avoid that as much as possible. So you want to make as much investment in your current infrastructure, move it over as much as possible. But each of the steps being on a clear path to an environment where you can do this application by application and where you can have the net results of this be in a platform independent mode. All right, we've just got a little bit of time here. I want to shift gears, David and maybe use the peer insight format here. What we do at Wikibon is when we do peer insights where we gather practitioners in the community, we try to give advice to CIOs, to CTOs, to the vendor community and from an asset management standpoint. So let's do that. What's the single action for IT organizations? What we came up with was back up as a service has to be a fundamental part of transformation strategies. It can't be a bolt on, it can't be an afterthought. What are your thoughts on that? Well, it comes down to app dev ops. You have to have the operational viewpoint of that application as it's delivered to you. Thought through right from the beginning. If you try and bolt on back up as a service afterwards, you are making a lot of work for yourself. So the dev department or the operations department have to work together to put this in right from the get go. Okay, I want to make sure Andrew's got this next slide up. Make sure I got that, sorry, I didn't do the Larry Ellison next slide thing, but we're good. So we're on action items here. CIOs and CTOs need to access the value, or CES rather, the value of historical information. So you're saying that there's a notion of value associated with historical information that's potentially monetizable. So how are they supposed to do that? Well, you've got to prioritize the data that you're putting out there and say, okay, where is the most likely value of those particular, which data is the most valuable? For example, if you happen to be a pharmacy company and you're going to be sued every now and again, you better have access to all the emails and all of that very, very quickly and easily. So that should be the highest priority. Now for CTOs, we talk about the technology integration strategy, spanning the application portfolio, trying to avoid bespoke implementations. Now that's not inconsistent with what you said in terms of taking it one step at a time. You've got to have a strategy across the application portfolio, implement it one step at a time and make sure that as you think about that rollout that you can actually accommodate that backup as a service across the entire application portfolio. Is that right? Yes, and there is a lot of tension. Sometimes the application wants to do the backup itself and they can often do a very, very good job of that. But unless that backup can be integrated into the architecture of the organization, that's not going to be a good strategy. So having a clear strategy and a set of products that will meet that strategy and using one of those that you've already tested out is the way to go. We're out of time, but I want to check on these other ones. The organizational action, rethink the roles of the backup admin, the DBAs and the application orders. You've got to get those guys in the same room before you implement this. Dev Ops, it's got to be the two of them are going to work together. Dev Ops is the mantra. The vendor management piece, we have run don't walk from suppliers that cannot articulate a backup as a service vision. We're going to have EMC on and we're going to put them on the spot and ask them what their backup as a service vision is. You can evaluate it for yourself as a practitioner out there. And finally, from an asset management standpoint, backup of a service is going to require getting rid of antiquated processes and of course enabling more facile and fungible service delivery. So you're going to be able to get rid of a lot of old legacy stuff. Well, at the same time, getting from point A to point B, ideally without ripping and replacing. And then the last point here is backup as insurance migrates to extracting value from historical data and providing IT as a service from a backup perspective. As a service and as the source of value. Excellent, all right. So that's the setup here for the backup and recovery, data protection as a service spotlight. Thank you, David Floyd, for joining me, keep it right there. We'll be right back. We're going live with Steven Manley, the CTO of EMC's BRS division. We'll be right back after this word. This is theCUBE.