 So, oh gosh, that's loud. Sorry. So, as Ryan said, my name is Heath Doober. You may be wondering why, you know, PagerDuty is talking about Rundec. Anybody wondering why? Because we own it. So, that's one of the things a lot of people will know about. If any Rundec users here today? Cool. We're going to make you Rundec users for the answers over, right? So, Rundec for the download of open source. Pager, we've acquired it as part of our core capabilities, and we've really built our entire operational stack around it now. We're pretty happy with it. So, that's what I do. So, my role is really to work with clients around the world on how do you take your existing investments you have? How do we do things around helping you build out your automation capabilities, your AI ops capabilities, your incident response, automated response. And so, really what I want to spend the time with you today on is kind of some of the problems that we're seeing out in this space, in particular around, you know, cloud, right? And we think about cloud automation and what that actually means for us. What are we actually really trying to accomplish? Is, you know, there's certainly, we've all heard and understand the easy problems of cloud, right? Very easy scalability. Great. Happens to also then lead to, you know, really remove those very easy barriers. So, now you say if I start a company right now, I would never back and start that first server. Of course, it'd be cloud, right? I'm assuming it's just rolling in cloud, right? Everybody on cloud. We're not out in the wilds. And the whole like behind that that was supposed to be happening is lead to increased business agility, right? So, here's a hint. When you're talking to your bosses about your next set of investments, don't talk to them about speed. Don't talk to them about, hey, the cool tech. Talk to them about how it's going to deliver faster. How it's going to make money flow faster, right? I love our business folks. I really do. We have an amazing job. We get to work on cool problems, do cool stuff. We really suck at telling our own stories. How do we begin to do that? So, as you begin to look at these processes and the things you want to think about and things you want to do, think about it in terms of what does that mean for business agility? How is that going to allow you to deliver faster and whether you want to get into the business of creating disruption, whether you want to be smart about things you do, whether you want to create efficiencies. This is the whole promise that we're doing again. But what does this need us to? Well, it also turns out that when we make things really, really easy to use. Anybody ever gotten your bill at the end of the month from a grab and realize you spent way too much this month? Because it's got really easy now, right? Don't want to leave your room, don't want to leave your house, don't want to leave your desk. Next thing you know, you're up 800 bucks on you don't grab. It's easy to do. So we make these things so simple, so easy to consume that things like surprise billing turned out to be a real problem for us, right? Fair. We also end up when we're making these our cloud pieces work, end up with a lot of architectural complexity, right? Because no matter which part of it, whether we're in Azure, whether in AWS, right, think about all the components that I'm going to have around RDS in my route 53 and all of the other pieces that are required in order for me to build these complex applications around that. I'm putting Docker in, I'm putting Kubernetes in, right? So the things that we're asking people to do now are becoming more and more complex, right? Anybody here part of an SRE team? Devops finally got SRE rock on my friend, right? And we see a lot of organizations are moving to SRE. But here's one of the things about SRE is that we demand an awful lot for most teams, right? The expectation is, you know, the whole stack, you know, down to the infrastructure level, right? So all of those things that are going in that, you know, require a lot of things. And so what do we do? Well, we end up then wanting to figure out the right tool for the right job. Guess what? There's an awful lot of right tools for an awful lot of right jobs. So this is one of the things I always hear people talk about, you know, cost and these other kind of complexities when it comes to cloud management, we don't talk enough about tools complexity. We don't talk enough about how hard these things start to look when we gather all of these additional pieces of information together, right? Because, you know, we stand these up our database, people want one set of management stuff, our network people want another set of management stuff, our core infrastructure capabilities are going to drive OS or virtualization or Kubernetes or Docker are all demanding other pieces of that, right? So what we end up with is a massive amount of tool ball. Don't have to begin to think about, is there any possible way we can begin to address this and think about, you know, what's next around this. So what we end up with is a set of capabilities that, of course, because we look at this as a purely technical problem. We think about this technical problem, we want technical solutions. So we won't develop or so in this case, you can see some cloud formation stuff down there for my friends that love cloud formation. It doesn't matter. This could be HONUS, Pulumi, Terraform, you know, the whole idea is we're going to deliver things as code. But here's kind of the thing that's happened now is with this promise of cloud is when the expectation is anybody can use it, anybody can deliver value from it, anybody can create this yet, we've kind of created this temple of high priests, you in this room, who get access to things, but who else does. So you know, we demand this level of familiarity down to the code level on how you want to look at and create these values from that. So what we end up with it is with this temple of high priests, what happens? Anytime you want something done, you have to go to the high priest. That means that if I'm a business person out here, hey, I've got this great new idea. I've got a new client, they're willing to pay us a lot of money. I need you to stand up my next instance of this database that I'm going to come out. It's going to be part of the billing thing that's out there. I got to come, how many requests am I going to put in? Right? I'm trying to go put in some core infrastructure requests. I need some a stamp, some additional billing. I need somebody to come up and instantiate the piece between them. I need virtual and it goes on and on and on. Is anybody about to submit those kind of requests? Wait for somebody to come back to you to give stuff to you. Right? We see it all the time, right? And here you are. This whole idea was cloud was going to make it easy. It's going to make me go fast, right? I was actually working with a client in the West Coast of the US. They put an request to just simply extend the monitoring in their environment. Four months. Four months, right? Digital business. Moving at digital speed. Four months. It's too long. Why? Because so few people have the understanding of the Indian pieces on it, right? On how we begin to drive this focus and think about what we want to do. So the other part is, we get in, right? So if you're on the other end of that request, you're the one receiving all these requests. It's awful damn hard to get work done. Because it's this constant interruption, right? We call it unplanned work. There's a fantastic book, by the way, if you're actually having, you know, want to be able to better communicate with your senior leadership on why you can't get your job done the way you want. Fantastic book called Making Work Visible. In Making Work Visible, they talk about how do you begin to surface all of this unplanned work? What do all these interruptions come? Hey, why can't you do all the things that you're supposed to be doing? Well, it's because I'm running around putting out fires all day. It's because I'm running around constantly, you know, asking, you know, standing up individual pieces of stuff that's this, this toil that's sucking up all of my day. So I need to get a lot smarter about how I do that. So I want you to think about, you know, that interrupt driven piece of it. What is that costing? By the way, worldwide unplanned work cost $1.1 trillion to businesses across the globe in 2021. So affects a lot of us. So how do we begin to rethink this, right? How do we begin to think about really getting this, you know, this overall promise of cloud that we were all supposed to have and make it so easy on us? And really, you know, bless them. But how do we reduce the burden on these business users that are asking these things from us? What does that begin to look like? We need an easy button, right? We need something that how can I make it very, very simple for people to take and consume the services that I want to be able to give them. The cloud was going to tell us, we just go ahead and snap these things in place. You put it up, you're ready to go. So how do we begin to do that? Well, run that. That's my presentation. Thank you. Sorry. What's the idea behind it? I want you to think about self-service operations. What does that begin to look like? How do I begin to make it to where I can stand up easily accessible, readily addressable, secure, role-based access controls so that anyone in my organization can make it very simple to get access to the services that I want to deliver, to be able to utilize those cloud resources in a way that makes sense, and allow the experts in the organization, all of you, to be able to design things in a way that say, hey, here are the things I want to easily expose. Where are the things that I'm actually spending too much time on? Where are the pieces that are actually making me lose focus on the capabilities in what I want to do? So if I can begin now, think about making it very easy to self-service, what begins to happen? Well, number one, I'm going to enable everyone in the organization, right, on what I want to be able to do. And I'm now going to be able to have a secure methodology, right, so role-based access control. My dear friend, Keo over here. Keo, reach your hand. One of the smartest people I know, Page2D, really smart, dude, knows a lot about this stuff. You can go find him in the booth later on, if you want to have some more questions. But I want Keo to be able to do anything. Keo gets it all, right? My dear friend Adele here, also at our booth later. Adele is going to be really, really good at networking. She gets to have all the networking stuff she wants. The woman will not walk into your database in my organization, that's where to go, right? Can't have any of that. So very, very easy to begin to segregate the kind of requests that I'm going to be able to drive and do at component level, right? So I want to do requests, how I want to tie things together, how I want to drive pieces through that. And here's what gets really interesting, you know, that this use case actually becomes generic very, very quickly. I could think about holistic service request management as well. I've actually created a methodology for how I'm going to secure access to things, right? So I need vaults to contain, you know, secrets and passwords and keys and things. I need to be able to have a way of how I do a fine role-based access control across the entire organization via SSO or whatever else. I need to be able to have a way that I can, you know, catalog and segregate various disparate pieces of things with tagging, that's everything. And I want to make it very, very easy to run. So those are the pieces that are put in place. Once you've actually deployed Rundeck, which is an OSS image, you can grab and download it today. We actually have, you know, full licenseable versions of it as well. But, you know, when you get it, great, you unpack it, you stand at your cluster, you know, now what? Well, first, what are your most manual and repetitive tasks? And I know that sounds a little silly, right? But bear with me for a second. I want you to stop and think. And here's, here's a thing, because everybody's already got automation. If I were to ask you, do you have automation? Anybody that doesn't raise your hand is a fool. Because you've got it already. It's just that today it exists out in his share drive. It exists out, you know, on his laptop. It exists out on that local server over there. It's there. But we haven't found any way to actually bring it together. So go find that stuff, right? Hey, when I send you a request to go ahead and answer into a database, what commands are you running? What scripts do you already have in place? What Python have you already written? Right? And let's go reuse that. Because this is what's key. When I find the automation, isn't that anybody believes that we don't want to automate? Everybody wants to automate. That's not the issue. It's a question of being able to make the time and the commitment to do so. Are you able to actually articulate a return on investment for that automation and things you do? Beginning to think about this in terms of dollars, not just in terms of technology. So starting with those things, they're good. You know, I want to be able to take all the existing pieces. I don't want to rip and replace anything. The second you start a conversation with an organization of, hey, I got to go rip that out of your power shell, you're done. Right? Because I've got those investments. I don't want to lose those. I don't want to go rewrite stuff. So how do I do that? I talked about this operational framework of how do I begin to think about how I want to solidify? What does that look like? How do I want to get down what level of fine-grained access control that I actually want to do? And then begin to think about how do I design that various user experience, whether they are, hey, their other developer peers of mine that don't happen at Access, they're actually maybe on-prem, but need access down to cloud resources for hybrid environments. Or maybe they're AWS engineers, but I'm doing something out of Azure. Or maybe they're just straight-up business users that you need to be able to take a product management organization and give them a way to communicate with you what their needs are to those next set of capabilities. Because here's the really interesting part of this folks. We have a credibility gap in IT because we have a visibility gap. We are the moles and trolls in the basement. Because same that is for a second. If you do your job every day, dead solid perfect, you make no mistakes, no errors, 100 percent availability, does anybody know you exist? You're completely invisible, right? So this is a way that you can now, one of the very first time show, hey, here's what I can do for you. Here's the things I can provide. Here's the value I'm driving for the organization. Here's the dollars I'm pumping into this value stream around the things that you do. So begin to think about how do you want to go to the stakeholders that carry an organization to surface to them all the hard work you do. Because we don't get enough credit. We get the blame, right? Then you're a last outage. Everybody could find you then, right? The last time something we were right, last time we were up for 30 days. Anybody pay attention? No. So begin to think about what is your journey for automation look like, right? So you know obviously all of us kind of are on the manual piece of it. That's pretty straightforward. And you know, and it doesn't necessarily mean anything bad. It just means that which probably a lot of toil we could begin to think about how to remove it from the organization and what to do. We've kind of kept automation to, you know, the high priest, you know, very limited. We want to make sure that we, you know, allow people to see the things that are there. So I want you to think about what is that first move to, you know, react to the responsive look like? Where, you know, I'm kind of doing some, you know, fairly straightforward tick and hand learning. I'm beginning to think about how I do things in the system a little bit easier. I'm beginning to set up automation for experts, repeatable sets of capabilities around the things that I have. And this is where I get, you know, a lot more. So when I start to get more responsive, this is who we're getting to standardize. And that's really the big key to automation, this standardization. How do I make it repeatable? How do I create templates that I can hand to you, whether they're terraform, whether they're harness, whether they're plumber, or there's something else that I can say, if you want to be successful, if you want to work with me, here's the easiest way to do it. And then proactive. This is where things get much more interesting, because automation today in your environment is driven in two ways. It is driven by a human initiating it, right? Which all that means is you still need a person like you that's smart enough to know which particular script to go run, or it's run by a schedule. What if instead it's a venture? What if now I go ahead and get a request from a product manager saying, hey, we would have been to spend this new piece of it. It drops that into a pub sub, you yank that off, know that your automation then says, hey, here's the next thing is I got to go fire in order to expand these sets of capabilities and, you know, begins to deploy, right? Where now automation is an extension of my observability pipeline, an extension of my CICD pipeline, and an extension of my service request. Now we're doing something really interesting, right? And this is not rocket science. I know this seems if you're if you're just kind of over here right now, seems way, way, way far away. Turns out it's not. It's actually pretty straightforward. My friends down there in the end come see with the page of the booth and they'll show you, right? So this is what we, you know, what we're really trying to get to is we're talking today primarily about what are you doing on being able to automate these service requests? And because my whole goal is, I want to get you out of your home office on your home back deck maybe an hour earlier this week. You know, it's great that we can do things for the company, but I'm not looking for us right now. This is what I want you to think about. The investment in automation isn't so much about, hey, how to create more value for the company, which is great. I'm going to create more value for us because again, we don't get enough credit for the things that we do. And also do anything about what is it now because we're talking about basic cloud capabilities, but guess what? We got to run those clouds. Same kind of thing today. Who's actually on call right now? Rock on my friend. Thanks for being here anyway. I appreciate you, right? On call is pain. On call will always suck. There's nothing good about being on call. So, you know, friends of yours, if you've got friends that are on call, give them an extra hug. They need it. Buy them a beer later. They absolutely need it. So, how do we begin to think about what does automation begin to drive in on call? If automation become the first virtual responder, guess what? My dear friend in the back, maybe gets 10 less calls this week. That's a pretty good deal. So, beginning to think about what is this system of automation begin to drive for us and not only gets us our own hours back, it can give us the capability for actually increasing overall availability. So, think about what is that journey to have been driven automation look like, right? Think about how do you begin to peel off the pieces out of here to get you to here? What you've got, happy smiling folks that it's a whole lot easier to do business with. People know what you do. You're saving time. You're saving money. You're delivering faster and you're getting that garbage out of it. There's a lot of great stuff and the things that we do. Did anybody get into IT to sit at keyboard and run commands? I didn't. We get here to solve cool problems, to do interesting things. So, let's figure out where are we wasting our time? Where are we not doing interesting things at and go out and make those things that are there. So, that's it for us. We've got that page duty booth downstairs with the very back. Make the trek back there. Come and see us. I'm sure we got some swag and other things that are there. And we can walk you through kind of some more examples of this. Talk about some specific use cases that would be useful for you and your organization and I guess I have a couple of months for questions, right? So, everybody bought all of that. Yes, sir. So, the question is can you use it towards like an L3 capability toward actually trying to resolve the issue first, you know, as part of the overall process automation, correct? So, yeah, let me answer that in two ways, right? So, there isn't an inherent ability inside of like the Rundeco SS to drive events associated with it. However, as part of the page, yes, it is. So, the idea is that data of New Relic, FD, Zabx, your favorite monitoring tool raises an alert, right? The threshold has been violated or a transaction is now trending off. I'm going to send that alert. I'm going to take that alert, normalize it, send it to Rundeco. Now, the only thing I'll caution you on is what I would say is, yes, if there isn't available, what I like to call sort of horseshoes and hand grenades fix, right? Can I make it? Can I pummel it back in the submission? Make it work? Yeah, absolutely. But what I really want you to think about is, what if I actually focused on doing automated diagnostics first, right? Right, got you. Yeah, so you can do that basic reflux action like you can do a webhook out of a datadog or something else that'll do those attempts. When you actually drive into this, what we do is we build more complex workflows that will say, go ahead and capture the diagnostics first before you attempt remediation. Because to your point, if I've tried it four times and it's still failing, I would really like to know why, right? And even if I do get it back into a working state, I would like to know the failure conditions. So, our suggestion is, inside of Rundeco, like you would define the automated diagnostics first, then begin to attempt remediation, like you said, inside of a try loop, you know, in being able to identify we've got multiple failovers. But you think about the kinds of remediation you could do. So, for example, by leveraging a more complex automation instead of a webhook, what I could do is I could say, hey, let's say I want to fail over a cluster, but I could actually check the health of that cluster first. And if it's a four-way cluster and I've already lost two of them, I don't want to fail over, right? Because now I'm down to single point. So, I can begin to think about remediation in much more complex ways than what I do. So, we start with to your point, fail over a cluster, you know, then we build to, you know, and say capture the diagnostics for it, then attempt the failover only under certain conditions. But yeah, that's exactly the direction that we're headed and what we're trying to do. That help? Yeah. And that's what, and that's what kind of best and breed. I've got clients in financial services in the U.S. that they'll drive down their MTTR for their nginx clusters and their web server clusters down to 60 or 90 seconds because of these kinds of complex methodologies in Rundec. Exactly. Other questions? They said, I'll be around the rest of the day. My friends on the page really booth, look forward to seeing you all. Thank you guys. So, it's your time and attention day. I appreciate you all.