Alright. So good morning. Good afternoon, everyone. Thank you for joining us today for our webinar streamline hybrid Doctor with automation orchestration. My name is Kimberly Sack with Cutover, the just gonna be our moderator host for today. And before we kick it off, I just have a couple of quick housekeeping items to cover. So for everyone joining through Zoom, at the bottom of your screen, you'll find a q and a box. Please feel free to submit any questions that you have during the webinar, and our presenters can answer them at the end of the session if we have time. If not, we'll make sure to follow-up with you after. For those of you joining us through LinkedIn live, please comment any questions, through LinkedIn, and one of our moderators will get it to our presenters. And, again, we'll address it if we have time, or if not, we can follow-up with you after. This webinar is being recorded, so we will share with share it with you after the session ends today. And with that, I will hand it over to our presenters for today. Walter Kenrick, over to you. Great. Thanks so much, Kimberly. So, everybody, welcome to our cutovers LinkedIn live session on streamlining hybrid disaster recovery and, with automation and orchestration. So today, we're gonna talk about how we're gonna cover some of the the challenges and try to give you some key considerations for really building a robust cloud disaster recovery strategy. So before we get started, let me introduce myself. I'm Walter Kenrick, vice president of product marketing here at Cutover. And with me, I'm honored to have Mark Yeagers from AWS. So, Mark, could you take a a some brief introduction of yourself? Sure. So I'm Mark. I'm currently the manager of outbound product management at AWS for the application migration service as well as the service we're talking about today, the Elastic Disaster Recovery Service. I've been at Amazon, AWS for a few years now. Before that, I was, working in various other tech companies as well as the the Gartner analyst for disaster recovery as a service. So I'm happy to be here, Walter, with you today. Yeah. Great. So so glad that you were able to, participate with us. So let's kinda get into it. And certainly with this slide, there's there's a lot to unpack, you know, with just this one slide with these four quadrants. And but as we go through this session today, we kinda wanna use this as our foundational mental model, throughout the the talk. So, Mark, you know, as we've gone through the cutover has gone through a number of kind of studies. We did a recent survey report on ITDR that's available on our site, and we've completed a number of interviews with our customers. And we've effectively boiled down the key disaster recovery challenges pretty much into these four quadrants around app portfolios, certainly legacy systems, cloud and SaaS, and and the regulatory landscape. So, yeah, with your expertise, I I'd really be interested, and I think our audience would be interested in your views and if AWS is hearing kind of similar challenges. So can you give us some thoughts around here? Sure. Definitely. Many of these challenges are not new. Right? The they're existed for a long time. We wouldn't have legacy systems if they hadn't been around a while. However, what we are seeing today is just the sheer number of things that are possibly affected when you've got a disaster recovery situation, and you need to establish everything back in operations. You've got a number of, applications, and the that application number just keeps growing. We have a number of different places that you could be running those applications, whether they're in the cloud with AWS or they might be on prem or or in another cloud provider. And so trying to have a a disaster recovery plan that takes account of all of that different surface area is something that we see as a challenge, especially going forward. In some of those legacy environments, addressing tech debt is something that we see a lot with customers where you've got a lot of older operating systems and trying to recover those in today's modern environment is often a challenge for a lot of different organizations. And we know that the compliance schemes across the world are are not changing or they're not getting simpler. They're getting more onerous, proving that you can have disaster recovery, proving that you can make those systems come back up, validating that, showing that to your auditors, and to those government, organizations just increases the amount of work that all of our disaster rehab managers do that we work with on a day in and day out basis. Yeah. It's in yeah. Great. Thanks for sharing, around that, and, you know, I wholeheartedly agree with with what you said that certainly, falls in line with what we're seeing. And just a reminder for folks out in the in the audience, if you're doing business in the EU EU, you have, the, digital operational, resilience act, DORA, that's gonna go live January twenty twenty five. So, you need to be ready for the audits and then prep for how you're gonna deal not only with your internal systems, but also with the with the cloud. So just a a quick reminder there. So let's move on. So let's kinda actually go down a level and down to more of the, what we've evolved, more of a layered view of application complexity for disaster recovery. And so we've kind of built this through the the work we've we've done with dozens of really big financial institutions. So from a cutover perspective, you know, while you're on the cloud, the application still require the same fundamental building blocks, whether it's your compute, your storage, your network, database, identity security, so on and so on. And so it's just a case of how the different layers are really abstracted and described. And then on prem side that, you know, abstraction is more kinda hardwired into the physical infrastructure. It might be like a Dell or HP piece of hardware. And the ways of working kind of are starting to evolve over many years of, you know, separate build and run teams. Now you're on top of VMware, Windows Server. You still have to deal with mainframe. So what we've kinda looked at is how do we apply that same layered model for really the cloud hosted applications as we're dealing with when we're working with our customers and helping them, you know, in those migration teams and those disaster recovery teams move closer to the velocity of software rather than dealing, you know, with, you know, hardware aspects of it. So so, Mark, maybe you can kinda chime in. You know, maybe give us your feedback and thoughts on kind of the breakdown between that application definition and between the cloud and and on premise and kind of what AWS is, seeing out there. Yeah. So this is actually one of the things that's increasingly complex in a hybrid and especially a cloud first world. Because a lot of that platform and infrastructure, you have similar capabilities as what you might be doing on prem, but it's expressed a different way or it's using a different construct. Something like identity management on prem versus identity management in the cloud are two completely separate ways of doing things, ways of operating. And it takes much more time and understanding of how you're gonna do a failover into the cloud or from the cloud or even between clouds to know that that's gonna work. And that same construct, capacity and and making sure that you know how to do things differently works across the compute environments, the storage network, as well as the locations. In a cloud environment, you have increasing capabilities to failover not just in different sites, so different availability zones, but also in an availability zone between different data centers that might be in there. And so you can failover to different regions, different sites. It's all different different levels of complexity that you can take advantage of, as well as engineer around. So that that's something to definitely take a take a look at as you're doing your planning and understanding what needs to be done in your environment to actually get things to to function as they fail over. Yeah. Yeah. That's great. And we'll certainly touch upon maybe some of the tools a little later in the in the session on how they can actually affect that, disaster recovery and do those failovers. Being able to kind of prove those out, we'll we'll touch upon that as as we go forward here in a in a little bit. So, this is, you know, kind of interesting things that we see. And, Mark, you you alluded to it earlier as the number of applications are growing. And, certainly, in our customer base, we're seeing between, you know, maybe on the low end, five hundred applications, high end, four thousand, four thousand plus. But, you know, when you kinda break it down, it's what's mission critical, what's business critical, those important business services. And those are the ones that you really have to worry about, not to, you know, dismiss some of the operational administration pieces, but, you know, something bad happens, you need to get those, you know, back online, those mission critical, business critical back online and as quickly as possible. So how are like, from AWS customers, you know, how are they kind of dealing with that in in the cloud, and how do they break down? Because now you're dealing with much more complicated architectures and as you get into, cloud environments. Yeah. It it's quite something to to take a look at because many of our customers, in fact, many organizations globally, have asked, like, how many tiers of application should we have? What should our RTOs and RPOs be? And a lot of those are always driven by your business needs. Now I've seen organizations that have, you know, one to three or four tiers like we've got, here in this chart. But there's also organizations I've seen that have fifteen tiers. That might be a little too many, but it's up to them to manage that and organize that. What I think is important is that you don't have the same level of operational capabilities at each of those tiers because you don't wanna invest more money than you need to in a tier three or a tier four application to make sure that it's recoverable. Whereas for the tier one or tier two, you definitely wanna make sure that you can recover those within the recovery time objectives that are set by the business for those applications. And the easiest way to do that is frequently testing. And so we offer services that allow customers to go in and test something in a cloud environment without having to have the you know, subscribing to lots and lots of services, running them all the time. They can purely just use them as they need to and pay them pay for them just as that utilization is. And so having different capabilities at each of these tiers, making sure that you're you're able to test, and then when a disaster does happen that you can recover that in the amount of time that you've prescribed. Those are all clear things that we're seeing with as we're working with customers as they're going out there. So I I think it's also important to to have some of those, what we call tier zero, or just the infrastructure capabilities that you've made sure are there, whether it's things like name resolution or networking. That all has to be there when you start to do your your testing or your failover. So Yeah. Absolutely. And, you know, it's kind of the layer above, certainly just the the applications. But if the network's not there, you have problems accessing it, you can't resolve to, you know, where those applications are located. That's a a huge problem that needs to be considered as you're going through your disaster recovery, plans. And, certainly, you know, working jointly together, I think we can address a number of those different types of issues, you know, through the integrations that we have to be able to prove out some of the, disaster recovery scenarios. So let's kinda get into that. Let's talk more about these what what the way I kinda frame it out is three segments, by TDR, cloud disaster recovery, go through the assess, test, and then recover. So maybe, Mark, you know, this kinda gets into a lot of the meat of, I think, what people are gonna be interested in, how how to run AWS can help support them through these different, segments. And so disaster actually occurs. They have a plan in place that they can execute against. Yeah. The the the first step is the one that I think is probably the hardest to start, but the one that you need to actually do before you can actually have a successful disaster recovery is start with assessing. Now at AWS, we've got an application that we built called AWS Resilience Hub. Customers use that to catalog their environment, look what's out there, and then start to use the capabilities in Resilience Hub as well as our Resilience Core Program methodology to make sure that they are protecting all of their critical assets and kind of planning for what can be done there. In that test phase where you actually are are making sure that you can recover, we've got customers that are using the AWS Fault Injection Service or FIS to do proactive, you know, engineering test level, to see what happens when you unplug something or when you have a network issue or there's a DNS change. All sorts of little faults that you can inject in there, to see how your environment proactively recovers from that. We're working with more and more customers that are using AWS Lambda to do event driven architecture based testing so that they can create an event that they know when they need to go run something for a Doctor test or when there's an actual disaster. They can use those Lambda's to coordinate that. As well as the AWS service catalog, which just has all of the different services and and virtual machines that you might have in there in your environment, you can publish those, use the existing published machines that are there. And then the service that is closest to my heart, the AWS Elastic Disaster Recovery Service, That's the actual service that does the data replication either from on prem or from other parts of the cloud environment into an EC two server. We replicate the data into EBS and allow you to automate the recovery of those machines so that they boot up in a different region or a different availability zone. And then when we're actually doing the recovery operations, all those cattle all those services also work together to create a, you know, new environment that you're running in, in a different in that different area, whether it's a region or availability zone. And, Walter, you know, Hotover has done a lot of work to integrate with all of these services. So I wanna thank you all for that. But can you tell us about some of the customers that you've worked with and where they've incorporated into this? Yeah. So we've definitely had a, you know, a lot of interest in some customers that are working with us right now to expand their, disaster recovery, especially when you get, you know, thousands of different applications. You know, it makes it very hard to have kind of that single single place, that centralized place to to be able to deal with, the amount of maybe testing or actual recover. So we've done a lot of work with AWS and, being part of their resilience core program as well as part of the resilience hub, taking some of the outputs and that injecting it into our our runbooks. But the real key, I think, is is around the the testing and and the actual you know, if you actually have to recover and the integrations that we've done there. So we have direct automations that we can pull in, and connect to the disaster recovery service, the elastic disaster recovery service because, Mark, as as you know, you get into the console. I think there's a scale about three hundred applications per management segment. But if you're dealing with four thousand, there's a lot of click offs to go through. And so with our run book technology, we can incorporate all that so you kinda have that single pane of bus, that single centralized view that you can reduce a lot of that click ops and and kick off some automatic orchestration tied into that. And and, also, if you're especially in your testing, so the fault injection service. So if we can as you're going through tests, we can execute a command to fire off, you know, simulate a failed, availability zone or, the application is failing in a AZ. So you need to take corrective action and and maybe fail over to a different site. We can simulate that a lot. And we we've done that through our demos. We were working with our customers. We have really prove out that failover recovery, capability. And then what's also interesting, some of the things that we're doing, with our customer base is ingesting things like the AWS service catalog, you know, where your applications are live. There's a lot of, details about that. How can we automatically generate runbooks so you're not having to create them? Can we take in that data? We're still just, we're more in the earlier stages of that, but it's really interesting. We're getting a lot of, interest in terms of kinda taking metadata and, bringing that into automatically generate runbooks out of the cut over platform, which I think is gonna be super interesting. But if you tie that all together, you know, whether you're testing and recover, you know, this symbiotic rate of relationship we have with AWS. And, Mark, you brought up something earlier. You know, you're talking about the network layer. So, you know, integrating, you know, with, route fifty three for DNS type of services, I think, is also important. You know? You know, where's the message come that, you can need to reroute over to a different, a different site. And so having that kind of centralized, that's the role that cut over plays is, you know, through our runbooks is providing that central, organization, you know, really reducing a lot of the click ops, tied with that. So, you know, very strong story, and, you know, we have customers right now that are employing, you know, the joint services because they have to deal with such, you know, the magnitude of of the application stack that that they have, you know, whether it's in cloud. And and you know, part of it, I I know of elastic disaster recovery also plays you can play have an agent sit on prem. So as you get into that hybrid environment of, you know, failing from, on prem up to the cloud. I'd like to go the reverse so much. Maybe, you know, correct me if I'm wrong, but, you know, kind of tying that in, you really get you know, it's not just a pure cloud story. It's really kind of more of a hybrid story that that we can play here. Yep. Definitely. So I wanna just kinda recap what we're seeing on a lot of customer environments today as the challenges that we've got. There's a lot of cloud dependencies that you have, a lot of on prem dependencies. And when you're transitioning that between those different environments, tying that altogether is quite a a pain. Oftentimes, most organizations don't have a single tool for all of their Doctor capabilities. Because they have different tiers, they're gonna have a service like Elastic Disaster Recovery protecting their tier one and tier two environments. But their tier three or tier four environments, they're probably using a service like AWS backup or other backup providers to have lower recovery time objectives and recovery point objective capabilities that are not necessarily as critical. And having all of these tools, having all of these different dependencies, maintaining the view of everything, getting a visibility into that environment, what's actually going on, what the status of something is, that can be really, really hard for organizations. And then we talked earlier about the growing regulatory landscape, and now there there aren't any less regulations being invented. We've got more. We have new ways of of having to prove things out, having to prove it out for different regulators worldwide. And so, Walter, I know cut over is great to be able to to bring a lot of this together. What have you seen, our customers doing in that regard? Yeah. So, you know, kinda going just, you know, back to what I was talking about earlier, you know, where our customers see the value and, you know, and, you know, working with AWS, we've really kind of proven proven this out is having that better together story. I know it's kinda cliche, but I in this case, I think it's really, really true and especially as you get into maybe a large financials or, you know, big, retail operations. Being able to have that centralized and standardized, disaster recovery execution place, you know, whether it's in the cloud or it's a hybrid. And the goal there is to reduce some of the click ops. So, you know, if you, you know, you need that view of those recovery activities that are taking place outside of AWS. So AWS does a great great job, but, you know, if you're on prem, there's kind of people interactions, because in our view, no disaster recovery, you know, is really, truly, attainable without at least some human decision making. That's really where I I think our our strength comes in to kind of play play that role, as we in our runbooks. And so, you know, providing that single pane of glass to view all of the recovery activities, to be able to fill that, you know, that gap so you can manage it. And you're not just looking at the, integration points to an AWS service, but, you know, you're looking at okay. We're gonna, invoke DRS, but there's a bunch of other automated manual steps, including nontechnical, steps that need to be included. So bringing that really holistic view of of the entire disaster recovery process into a centralized place as well as being able to, scale. So, you know, as we talked earlier, up to four thousand applications, we have a number of customers that are definitely within that that thousand application range or or higher. So how do you coordinate those activities if, you know, the AZ went down, god forbid, a region were were to go down or just even on prem and you wanna fail over to the cloud, you know, how do you coordinate all those activities through a number of different, applications? And so we can fill the gap by being able to manage, you know, those hundreds, thousands of recovery runbooks across the entire enterprise. And I think that's that's real key because now you can really have that, again, your centralized managed, place. And the visibility so, Mark, you know, you you brought up one of the challenges, which I think is is right on is that lack of visibility. How do you kind of get everybody to understand, you know, the progress? Certainly, senior stakeholders kinda wanna know, you know, what's the progress of, any type of recovery that's gonna happen because it affects their business and that affects revenue, which is really bad. So how can you, you know, show that, hey. We're tracking along. You know, we're meeting our RTOs. We're getting these, applications online. Everybody's synced. And so by providing kind of a real time view through dashboards and when you have thousands of applications and maybe have, you know, you know, couple hundred thousand or hundreds or thousands of app runbooks. You want that view of what's going on more at a higher level for the that senior stakeholder to have the visibility in the progress. And that's that's where cutover can help fill that gap, in these large, events. And then, certainly, being able to test and prove that recovery to the regulators, obviously, is key. There's a lot of regulations that are already on the books. It's more stuff that's coming online, as you mentioned, things like Dora, to where you're gonna have to be ready, for that, which includes the, cloud providers. So you're gonna have to be able to test the in an AWS environment on that. And so where do you get those audit reports? How do you not spend, you know, number of hours combing through all these different tasks that were happening and try to coalesce and, like, okay. Yeah. We met our RTOs. You wanna be able to click, create a report, give it to the regulator, and and, reduce that amount of time. That's certainly what the cutover platform can do, in in helping to, provide those different types of, audit logs, audit reports to those regulators, without a lot of lot of, problems. So, Mark, you know, kind of coming to a close here, maybe just, you know, I'd like to leverage your expertise. You know? Can you kinda walk, the audience through some of these best practices that that we see? Sure, Walter. So one of the things I mentioned earlier, you you've gotta start with understanding what you're trying to recover. So you need to inventory your applications and understand what the dependencies are among them and what the criticality for recovery is, so what the recovery order should be for all of those applications. Now some people will do a full business impact analysis. That can take a lot of time and be an expensive process, but just starting with an inventory itself is a great thing to go and do. You also wanna make sure that you've researched and refreshed your service management framework and know how that's gonna work, and make sure that you've got automated Doctor templates. Now I've seen people and and clients and customers that have Doctor recovery books that look more like a cookbook, and I've seen some that it's more like a completely automated script. So you wanna be closer to the script. Any recovery template that anyone can run is great. One that has to have your key per personnel to run is not so great because you don't know that you're gonna have your key personnel there to do the recovery all the time. You do wanna make sure that you're using your partners and reaching out to them and involving them in any disaster recovery planning that you're doing, making sure that they have the capabilities to support you, but also seeing what they can do for you in the time of any recovery that you might need. Practicing recovery quite often is key. Doing it once a year is typically the minimum, especially for those business critical environments. Some industries, some organizations practice more than four times a year. So So it's just something that you all have to to take a look at as a customer, as a client, but practicing it regularly, making sure you can establish those services back in your recovery environment is key. And then understanding what's your responsibility and what different providers in your organization or what your different partners might be responsible for. If you're using a SaaS service, typically, the disaster recovery model for that service is up to that provider. So you just have to make sure to know what they're doing and how they're gonna work differently than what you might be doing internally. Great. Well, I know we're running out of time, so I'll I'll hand it back to you. Great. Thanks so much, Mark. Really appreciate, all that. So just to recap who Cutover is, you know, we provide automated runbooks that are really built for IT operations. We offer a solution in combination with AWS to seamlessly, provide that automation orchestration, but also human decision making in our runbook technology. And that's really the the key is, being able to provide that visibility of the entire process while keeping those, people in the loop. And our goal and what we've seen a lot of is that we can really help to standardize, accelerate those executions as Mark was talking from a best practice, perspective to increase that efficiency, reduce those costs, and and that ultimately drives the operational excellence and, cost savings. So as mentioned by Kimberly, if you wanna learn more, you can scan the QR code, but we will be sending a copy of this, tech, operations guide that we've produced around cloud disaster recovery in AWS. You can also just download from the cutover dot com, but we'll make sure everybody gets a copy of it. And with that, I wanna thank everyone for attending today, but special thanks to Mark for his support. I think Mark gave us great to have you, and we look forward to doing more of these as we go forward. Yep. Definitely. Well, thank you, Walter. Thank you, Kimberly. Thank you, everyone. Yes. Thank you, everyone. As Walter mentioned, we'll share the recording as well as that additional resource. Please reach out on LinkedIn to Mark or Walter or contact us through the information on the screen, and we hope you have a great rest of the day. Thank you all. Bye.
.webp)
