 From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hi, and welcome to the CUBE studios for another CUBE Conversation, where we go in depth with thought leaders driving innovation across the tech industry. I'm your host, Peter Burris. Any business that aspires to be a digital business has to invest in multiple new classes of capabilities required to ensure that their business operates as they're promising to their customers. Now we've identified a number of these, but one of the things that we think is especially important here in the CUBE is data protection, data assurance. If your data is going to be a differentiating asset within your business, you have to take steps to protect it, make sure that it's where it needs to be, when it needs to be there, and in the form that's required. Now a lot of companies talk about data protection, but they kind of diminish it down to just backup. Let's just back up the data, back up the volume. But increasingly enterprises are recognizing that there's a continuum of services that are required to do a good job of taking care of your data, including disaster recovery. So what we're going to talk about today is one of the differences between backup and restore and disaster recovery, and why disaster recovery is becoming such an important element of any meaningful and rational digital business strategy. Now to have that conversation, today we're here with Zazala Reddy, who's a CTO at Datrium. Zazala, welcome back to the CUBE. Happy to be here, Peter. So before we go on in this question of disaster recovery and why it's so important, let's start with a quick update on Datrium. Where's Datrium today? You've been through a lot of changes this year. Yes, right. We kind of have built a bunch of services as a platform. It included primary storage, backup, disaster orchestration, and encryption mobility. So the last piece of that puzzle was the DR orchestration. We kind of finished that a few months ago, and that's the update. And also now what we're offering concretely is, it DR services to the cloud with VMware Cloud on Amazon. It is transformational, and people really are adopting it quite heavily with us, because it simplifies that what you just said about the business continuity, and it gives them a chance to like, shut down the second data center and leverage the cloud in a very cost-effective way to have that option for them. So let's talk about that, because when you think about the cloud typically, you think about, especially as you start to bring together this hybrid cloud notion of an on-premise versus a cloud orientation, you think in terms of an on-premise set of resources, and you think in terms of effectively mirroring those resources in the cloud. And a lot of people have pointed out that that can be an extremely expensive way of doing things. So historically, we had a site, we had a disaster recovery site, maybe we even had a third site, and we had to replicate hardware, we had to replicate networking, we had to replicate software, and often a sizable percentage of staff across all those services. So we've been able to do it more effectively by having the cloud be the target, but still having to reserve all that CPU, all that network seemed like an extremely expensive way of doing things if you only need it, when you need it, and ideally it's not often. That's correct. So Cloud Office is a new way of doing elastic on-demand pricing, especially for disaster recovery, it is really useful to think of it that way. In a data center, to data center DR, like you mentioned, you have to buy all these different products for you managing your data, you have to buy primary storage, backup and DR orchestration, all these different pieces, and you replicate the same thing somewhere else. All these pieces are kind of just complicated. It's called Murphy's Law. Imagine that when there's a disaster, everybody's watching you, and you're trying to figure out how this is going to work for you, that's when the challenges are, and there's the danger is that until now, disaster recovery has mostly been a disaster. It's never really worked for anybody. So what Cloud offers you is an opportunity to simplify that and basically get your disaster recovery to be fail-proof. Well, so we have the ongoing expense that we're now ameliorating, we're getting rid of, because we are not forcing anyone to reserve all those resources. One of the biggest problems in disaster recovery has always been, as you said, it's been a disaster. The actual people processes associated with doing or recovering from a disaster in business continuity sense often fails. So how does doing it in the cloud, does it mean we can now do more automation in the cloud from a disaster recovery standpoint? Tell us a little bit about that. There are multiple things. It's not that the cloud offers simplicity in that way. You do have to imagine how you're going to build software to help the customer on their journey. The things, like you mentioned, three things people do in a disaster planning kind of thing is that one is that they have to do planning, make all these notes, keep it down somewhere, and things change. The moment you make these plans, they're broken because somebody did something else. And second thing is they have to do testing, which is time consuming, and they're not sure it's going to work for them. And finally, when there's a disaster, there's panic, everybody's afraid of it. So to solve that problem, you need to imagine a new software stack running in the cloud in the most cost-efficient way so you can store your data, you can have all these backups there, and in a steady state, you're not paying very much. And S3 costs are pretty low. If you do Ddupe on that, it's even lower. So that really brings on the cost of steady state behavior. But then, when you push the button, you, we can bring up VMware servers on the Amazon cloud on demand. So you only pay for the VMware servers, compute services, when you need them, and when you don't need them anywhere, you fix your data center, you push a button, we'll bring all the data back and shut down the VMware servers. So it's like paying for insurance after you have an accident. That changes the game. The cost efficiencies of doing DR, it certainly becomes affordable for everybody. And you can shut down your second data center, cut down the amount of work you have to do, and it gives you the opportunity to actually now have a chance to get that fail-proofness and actually even work for you or not going to work for you. But you're shutting down any other data center, but you're also not recreating in the cloud, right? Yes. So you've got the data stored there, but you're not paying for all the resources that are associated with that. You're only spinning up, spinning up, spinning them up in VM form when there's actually a problem. But I also want to push in this a little bit that the, if it suggests also that if you practice, you said test, I'll use the word practice is one of the things you need to do. You need to practice your DR. Presumably if you have more of that automated as part of this cloud experience, then pushing that button, certainly there's going to be some human tasks to be performed, but increases the likelihood that the recovery process in the business continuity sense is more successfully accomplished. Is that right? Yeah, they're correct. There are two things in this DR. One is that Dino is going to work for you. We naturally have a disaster. That's why you think of doing testing or the, what did you call it? Practice. Practice once in a while. The challenge with that is that, why even do practice? Like it takes time and energy for you to do that. You can do it, no problem. But how can we with software transform that such a way that you get notified when actually there's something that's going to go wrong for you? Because we own primary, backup and DR all the three legs of the stool in terms of how the DR should be working. We can, we check continuous compliance checks every half an hour so that we can detect if something has gone wrong. You have changed some plans or you have added some new things or networking is bad, whatever. We will tell you right away, proactively in half an hour, that hey, there's a problem. You should go fix it now. So you don't have to like do that much, plan that much of testing continuously anymore because we're telling you right now there's a problem. That itself is such a game changer in the sense it's proactive versus being reactive when you're doing something. Yeah, dramatically increases the likelihood that the actual recovery process itself is successful. Yes, right. Where if you have a bunch of humans doing it, it could be more challenging. And so as you said, a lot of those, a lot of the scripts, a lot of that automation is now in the solution and also proactively. So if something is no longer in compliance or does not fit the schema and the model that you've established within the overall DR framework, then you can alert the business that something is no longer in compliance or is out of bounds. Fix it so that it stays within the overall DR framework. Have I got that right? Yes, correct. And you can only do this if you own all the pieces. Otherwise, again, it's back to the Murphy's Law. You're testing. So every customer is testing DR in different different topologies. Everybody's different, right? So then a customer is now the tester of all these pieces fitting together at different combinations and permutations. Because we have all the three pieces, we are the ones testing it all the time and everybody testing the same thing. So it's the same software running everywhere. That makes the probability of success much higher. So it's a great story, Cezala, but where are you? Where is daydream today and in terms of having these conversations with customers enacting this, turning this into solutions, changing the way that your customers are doing business? Fair enough. We have simplified by converging a lot of services into one platform. That itself is a big deal for a lot of customers. Nobody wants to manage stuff anymore. We don't have time and patience. So we give this platform called DVX on-prem. It runs VMware workloads, it's super, super efficient. But the next thing what we're offering today, which is actually very attractive to a lot of customers is that we give them a path to use the cloud as a DR site without having to pay the cost of it and also without having to worry about if it's working for them or not working for them. The demos are super simple to operate because once it all works together, there's no complexity anymore. It's all kind of gone away. And there are a lot of companies, as I mentioned upfront, that are talking about backup and restore as an approximate to this. But it seems like you've taken it a step further. Yeah, so having been in the business for a while, backup, yes, backup can live in the cloud. If you have long-term backups, whatever. But remember that backup is not DR. If you wanted to have a DR, what DR means is that you're recovering from it. If you have backup only, the challenge is- Backup's a tier. Backup is a tier. Backup is that you have to do rehydration. There are two problems with that. Firstly, rehydration will take you two days. Everybody's watching you while the data center is down and businesses wants to be up and running. Two days to recover, maybe 22 days. I recently was at a customer. They have a petabyte of data. It'll take 22 days to do recovery of the data. That's like, I don't know what's going on. 22 days. 22 days. And then another 100 days to bring the data back. So that's the problem with backup as a topic itself. And secondly, they're converting, a lot of these backup vendors are converting VMs into Amazon VMs. Nothing wrong with Amazon. It's just that, certainly in a disaster, you're used to all your vCenter, you're used to your VMware environment, and now you're learning some new platform. It's kind of refactored your VMs into something else. That is a different disaster you're waiting for to happen for you. Well, to your point, you don't want disaster recovering in three years when you figure it all out. You want disaster recovery now with what you have now. That's correct. That's exactly right. So thus conversion of VMs leads to a path of, it's a one-way migration. There's no path out of that. It's like, it's like Hotel California. You're getting in, not coming out. It may be good for Amazon, but the customer's trying to solve a problem, which is a DR problem. So by working with VMware Cloud, they've been very friendly with us. They're super good partners with them and they've enabled us access to some of the things. They're to enable us to be able to work with them, use APIs and launch VMware servers on demand. That, to be, is a game changer. And that's why it's such a highly interesting topic for a lot of customers. We've seen a lot of success with it. We're leading with it now. A lot of people just dying to get away from these DR problems and we have business community for the business and what we're giving them is the simplicity of one product, one bill and one support call. You can call us for anything, including Amazon, VMware and Datrium, all the pieces and we'll answer all the questions. Now I really like the idea and you pay for it only as, or after the disaster has been recovered from. It's like having and paying for insurance after them. I like that a lot. All right. So it's all ready. CTO of Datrium. Once again, thanks for being on the queue. Oh, thank you very much Peter for having me. And thank you for joining us for another CUBE conversation. I'm Peter Burris. See you next time.