So first, for those of you joining us through LinkedIn Live, please comment any questions, and one of our moderators will get it to our presenters. For those of you joining via Zoom, you'll find a q and a box at the bottom. So please feel free to submit any questions you have during the session then, and one of our presenters will answer it. This session will be recorded and will be shared. Next slide, please. So we're gonna take the next twenty, twenty five minutes, and we're gonna discuss how the next level of orchestration is essential for complex IT operations. Again, think of in terms of IT disaster recovery, major incident management, cloud migration, application release. So our presenter is gonna talk about really redefining the runbook and then the the level two orchestration and how that builds more resilient operations processes. And then we'll wrap it up and open it up for questions and answers. So now I'm excited to introduce our great speaker for today. Next slide, Marcus. Thank you. Marcus Wildsmith, who is our chief product officer at Cutover. Marcus, I'll hand it over to you to do a quick little intro. Thank you very much, Kimberly. Yeah. So Marcus Wildsmith, I've one of the cofounders of Cutover, and I've kinda spent my time here on the product engineering side. So as chief products officer, I look after product strategy, and, I've been kind of excited to work with colleagues and customers over the last almost ten years now around driving what we think of as the cut as the runbook and defining that within within CutOver. Awesome. Thank you. So before I hand it over to Marcus, I just wanna set the stage and talk about some of the IT operations challenges that we've seen. We've talked with customers, prospects, and partners about. So first and and most fundamentally, you know, the sheer scale of the application portfolio is overwhelming for enterprises. You know, they run on thousands of applications, and this leads to complex architectures and dependencies, which in turns really complicates critical processes like disaster recovery, major incident management, and thinking about how you can move or recover an entire business line when you're managing complex chains across thousands or hundreds of systems. And then next, the move to cloud and SaaS adds another layer of complexity. Right? So oftentimes, we're seeing enterprises deal with hybrid, multi cloud environments, which makes migrations and recoveries that much harder. So the shared responsibility model blurs the lines as well, making it really tricky to ensure seamless execution across all these components. And then there's the growing regulations. So we're constantly being pushed to minimize customer impact, adapt to evolve regulatory requirements, and then complying with emerging sovereignty standards. You know, proving compliance with traditional static methods is practically impossible. So this is then compounded by the struggle with legacy systems that we see enterprises still having. Right? So older ITSM systems, other systems, you know, aren't built for modern scale. And the lack of, you know, more modern skill sets in the workers, you know, forces teams to rely on technical debt. So all of this compounds to make a really challenging and complex landscape that we see the enterprises we speak to have to address. So with that, I'll hand it over to you, Marcus. Thanks very much, Kimberly. So I'm definitely gonna take it up a bit of a a level and really just talk about kind of what it is that we see is the the future runbook and how we're looking at that and trying to kind of take a stance of how that fits in with with what CutOver is trying to achieve. So we definitely see the the runbook and the CutOver runbook has to meet a bunch of complex operational needs in the enterprise. And as we step back and do our work in terms of planning our roadmap and where we're heading next year, a lot of that is thinking around, well, what are the pillars that we see as being absolutely critical for how do you support large complex enterprises in their IT operational needs, particularly around managing the application estate. And that's very much our focus. We see other use cases, but this is where we're we're we're bedded down. And so I'll go around this this wheel here. The first area, big complex events. We definitely see that the age and resilience of planning a testing event around, say, a data center failover that takes quite a lot of people and quite a lot of time to plan is something that is starting to be not acceptable. It provides a useful purpose, but really what we see as big events is things that you can quickly mobilize in a very short space of time that may cover hundreds of applications and therefore hundreds of runbooks. And whilst this isn't specific to automation, the ability to do that in an automated way is critical. So understanding, in a particular event, whether that be a cloud outage that we've seen recently a couple of times or whether it's to do with a data center failure, the need to establish what the impact area is and to be able to pull together the event to recover from that is something where automation can play a big role in pulling that together. The real time response for us is really about the not being the central pillar for an individual, for a human to perform that layer of orchestration, but actually the runbook itself is a place to collaborate, particularly around solving instance where we've launched our respond product, but essentially driving that real time use of assigning tasks to teams or to agents in order to help resolve the incident and bring down meantime to recovery. The third point, which we'll delve into a lot more and is perhaps kind of core to the the topic of today, is what we describe as level two orchestration. So we've looked a lot at our customers and how they're approaching automation, and we see that a lot of that is buried in technology. And we're seeing that the runbook is the thing that should be agnostic to the underlying technology and should sit above it and enable teams to build robust runbooks that can stay reasonably static even when the technology underneath changes. The next piece in programmatic orchestration is really how can you be far more hands off? We're getting a lot of questions from customers who are coming and saying they want to come get to the point where they have one click failover, and that's a term that's been specifically asked for in by multiple customers. So the idea that a runbook is programmatic, but it doesn't actually need human involvement and except by exception when something goes wrong or you need human kind of authorization to proceed down a path kind of drives a lot of our direction. And then the final one around AI and context data, runbooks don't exist in isolation. There's a whole bunch of data that exists outside in CMDB systems, in change management records that is really pertinent to the runbook. So being able to bring that in and interrogate it and augment the runbook based on that data is really important to us. And AI is starting to play a big role in that, and I'll I'll delve into that a little bit later. So as I said, we're focused on predominantly application centric use cases. That's what we wake up, and those are the problems that we try and solve. Cut over, respond, and recover are very much in the application resilience space, and then migrate, release, and implement a wider application application use cases. So when we look at the platform on the left hand side and consider those five points that we just went through, we're always doing it through a application centric lens, and we're guided by those use cases. So whilst we definitely get interesting use and we've seen things like financial month end close as use cases where the rubric is being used, that's not what drives us. So the things I'll talk about today are generally driven by these application use cases, and that's what our focus is as company. And then when I take a step back and look at application resilience, we very much see that as a spectrum. So on the left hand side, IT disaster recovery and the traditional kind of application, full app recovery exercises that get take take take place on the left hand side is what we kind of cover by cutover recover. And then on the right hand side, major incident management, which we've cutover respond, where we're much more thinking about that collaboration lens that we talked about earlier. And we see this as being a continuum that things that you do on the left hand side should contribute to being better at things on the right hand side. So being good at component recovery of an application should be used in an access in in real life in a in an instant, And you should be able to pull on the same runbooks that we'd use in a test on the left hand side as part of instant response. And that's a big part of our drive is to make this a a seamless a seamless transition from one side to the other so that there's a lot of reusability and a lot of confidence in runbooks that are built in one place to reuse them in another. So I'll now delve a little bit more into the the the five areas on that wheel. The first one around big complex events. The way we see this is that we would expect an organization to have hundreds and thousands of applications on the left hand side and for each application to have one or more templated recovery plans. The piece where automation comes in is in order to combine those into an event and to do that in an intelligent and safe way is something that benefits greatly from automation. So the attributes of those applications that determine whether they're impacted or not, So whether they operate within a within a particular region in AWS, for example, is a big part of do we know which ones we need to go and grab? What we're trying to do here is use that associated data and use automation, particularly through our API, to bring those events together incredibly quickly and without the without the need for lots of human effort. And then once they're together, the ability to execute that with precision. So this is not necessarily talking about using automation in other systems, but this is how do you automate the end to end process of bringing an event to the point where it's live. The second piece around real time response, we see this very much as being a core attribute of the runbook that the dynamic creation assignment of tasks that we take the conversation that's happening in chat tools and grab it out of chat and bring it into CutOver as tasks that get assigned and can also be assigned to automation so it gets done automatically. The things that are simple to do, such as performing a health check on a on an application before you get into the next stage of diagnosis, is something that can be done in the runbook in an automated way. We also see in this that automation plays a big role in summarizing the activity, so particularly leveraging AI here, but that grabbing all the information that's happened, so what's been going on in chat and what's been going on within cutover, and summarizing that so when stakeholders come into an instant, they get a really good update of what's been going on and don't interrupt the team to ask those questions is a big part of that automation. So anything around how can you keep people informed about what the latest stage is without kind of interrupting the people solving the problem is a big part of what we focus on. I'll now get on to the different layers of orchestration and what we mean by that. I'll start at the bottom. So layer zero, we see as very much the automation tools that are run on your infrastructure as a in a in a customer's infrastructure, generally command line based tools such as Ansible, Terraform, Kubernetes. And on the right hand side, we're saying that's actually restricted to the development team. You know, a reasonably small percentage of the organization have access to those tools or have the skills to access those tools. And so driving automation at that layer needs needs you to be able to delve into a a particular skill set. Level one, the next level up, again, reasonably constrained to technology teams. So a larger proportion of people, three to five percent of an organization, may access these tools. These are the low code tools that enable you to knit things together. And I think a lot of the time, these prove is a very good basis for building more complex automation, but don't necessarily give you the the level of how do I orchestrate something kind of that's more enterprise wide and more complex. And that's why we've coined the term layer two. And what we mean by that is a runbook that can sit in cutover that is accessible to a much greater proportion of the organization. So the whole of service management, the whole of the operations team, so maybe twenty five percent of the organization can access that. And we're really looking at how do you federate and democratize access to automation so that we grab it out of the realms of technology and make it accessible to other teams? And I think that's specifically when executing a runbook. So, therefore, it's not pre canned, something that runs every night without intervention, but something that somebody may want to run as part of a as part of a process, and they can ramp can go into that. We definitely see that often getting to layer zero, we we reach into layer one first. So I think layer one tools are often accessible by an API, and so the runbook would call that and and execute those those those automations that would delve into layer layer zero. What we also see more and more is the desire that a RUMPUT can actually just jump in and execute those much those very technical tools. We have a a piece of software called CutOver Connect, which actually gets deployed within a customer's infrastructure on a VM, and it allows CutOver Connect to directly access that level zero tooling. So to run an Ansible playbook is a is a good example. What we're trying to do there is allow technology teams to build the reliable, tested, safe automations that exist at layer zero, but surface them at a much higher level. So the operations teams who can be very comfortable in the CutOver runbook but wouldn't want to personally execute an Ansible playbook can do that in a safe way through through CutOver. And I'm gonna jump into that in a little bit more detail. So what do we mean by that, and what do we see as a an as an example implementation of that? Again, I'll start at layer zero. So we would see an organization would have Ansible playbooks, and they sit within a source code repo such as GitHub. And that exists in isolation, and those rumbots can be executed. What we do with CutOver then is bring those up to layer layer two, and there are really three steps to this. The first one is that those playbooks can be visible to CutOver. So GitHub has an API that can get exposed to CutOver as a data source, and therefore, you can be in a runbook in CutOver, and you can see what the available playbooks are. The second is that there's a task level integration in CutOver so that in a runbook in CutOver, you can have a task that you specifically select the playbook that you want. And then finally, via CutOver Connect, which I covered before, you can then go and execute that playbook. And so what we're really trying to do here is take detailed technical tooling and make it exposed and visible in a runbook where anybody in the operations team can go and grab a task associated with an ad sport runbook to form that automation. I'll go on then to the next bit around programmatic orchestration. I mentioned that we're frequently asked for ones one click failover. And so in order to do that, a runbook needs to progress automatically without needing a human to do that. And so we've built over the years a number of capabilities that tasks can automatically progress based on the predecessor completing. You only have a human intervention where something fails and the ability to set things to happen at particular times, so kind of to meet the, yeah, meet the timing in a in a change request, for example, so that you won't need kind of action something at the time that it's been been approved. I think we see this going a lot further, particularly around bringing logic into that that equation. And then the final piece is AI and context data. This is something I think we spent a lot of time thinking that there's been a real transition here. So starting at the top, the manual runbook typically contains, you know, dozens of tasks. I think when we look across our runbooks, we probably average around thirty tasks in a runbook. Automation has made that expand a lot. So by allowing tasks that are automated and hook out to other tools like Ansible we covered before starts to expose much more in terms of much more of the granular detail of what happens behind the scenes. And so what we've seen in the past is these manual runbooks. They are, by necessity, a simplification and abstraction of what sits under the waterline in this iceberg analogy. And so if ten percent sits above the waterline and ninety percent sits underneath, AI suddenly changes the ground here because whereas before, a whole bunch of data used to exist in MS Teams chat or Zoom call transcripts or within the ITSM tools or your a p application monitoring logs, all of a sudden, that information is available, and AI can synthesize it so that a runbook that maybe was thirty tasks in the past could now be five hundred tasks because AI can go and grab all the detail, put some structure around it, and actually bring it into the runbook. And thinking about how we drive that forward so that we can make sense of that. As humans, we don't get lost in the fact that there's five hundred tasks. There are still only thirty logical steps at the top. We now just have all the detail to make that happen. So I think the key pieces from this that we're kind of saying are the are the takeaways are that we see that automation tools often sit too much in the domain of highly technical teams, that automation is really most powerful when it gets federated out, that wider teams can use it in a safe way that they find accessible. And, really, that's the focus of us is to expose the automation that's being built The teams have invested a lot of time in, but make it accessible to a far greater audience who can benefit from that. Great. Jumps ahead a bit there. Can believe. No. That that's great. Thank you so much, Marcus. It's actually a great time if you can switch to the next slide, please. So while we open it up for q and a, I just wanna share a couple upcoming events with our attendees. So Cutover will be attending and sponsoring AWS re:Invent, which is next week in Las Vegas. If you happen to be attending, stop by booth two three three. Reach out to me. I can connect you with one of our Cutover representatives. We'd love to discuss any challenges that you're having, with your resilience for your AWS workloads, if you're looking for faster recoveries or streamlining major incident management. You know, if you're not attending re:Invent, you know, reach out to us on cutover dot com. Go to LinkedIn to our company page. Find myself or Marcus on LinkedIn as well. We'd love to to have a conversation with you. If you are looking to get hands on with the Cutover Runbook, we have an online two hour free workshop on December eleventh where you can build a Cutover Runbook, which includes integrations to AWS services, like fault injection service or FIS. So it's really taking the next step to learn how to improve resilience. And if you're managing your workloads on a different cloud other than AWS, don't worry about that. You know, cutover runbooks are cloud agnostic, so we can still work with you and help you. And if you're not yet if you're not attending re:Invent and you're not ready to get hands on with a runbook but wanna learn more, you know, go to our website. We have lots of our webinars and videos there. Also on LinkedIn, we have all of our cutover live sessions recording there. So reach out. We would love to engage with you. So it looks like we're right about at time. So we will take any of the questions that have come in and follow-up offline with people. I wanna thank our attendees, and most importantly as well, thank you, Marcus. I think this was great to dive into a topic that we haven't gotten into before, really going into that, the different layers and levels of automation and, you know, how cutover runbooks precisely can answer and help solve that complex IT operation challenge. So Thanks very much, Kimberly. Thanks, everyone. Thank you. Have a great day, everyone.
