PurePerformance - When DevOps, SRE and Keptn go on a road-trip

Episode Date: May 2, 2022

The world is slowly moving back to having on-site meetings and conferences – such as DevOpsDays in Raleigh, NC where Andi presented on “Oh Keptn, my Keptn”.Besides presenting Andi also visited several organizations on his road trip through North Carolina and Texas. Listen in and learn what the adoption challenges of DevOps & SRE are, how to define good SLOs (Service Level Objectives) and how to explain the difference between containers and microservices. Also check out the following links Brian and Andi discussed:State of SRE Report: https://www.dynatrace.com/info/sre-report/DevOpsDays Raleigh: https://devopsdays.org/events/2022-raleigh/program/andreas-grabner SLOConf: https://www.sloconf.com/WTFisSRE: https://www.cloud-native-sre.wtf/Keptn: https://www.keptn.sh

It's time for Pure Performance! Get your stopwatches ready, to another episode of Pure Performance. My name is Brian Wilson, and unfortunately, Andy Grabner cannot join me as my co-host today because he is off at DevOps Day Raleigh or wrapping it up and doing some travel. So today, I will just get right to our guest. Our guest is joining us from DevOps Dave Raleigh, Mr. Andy Grabner. Andy Grabner, how are you doing today? Nice to meet you. Do you want to introduce yourself to the audience? Well, Brian, nice to meet you too. And I've heard about your podcast for many years, and I always wanted to be a guest on the show,

and now finally it happens. So for those people that don't know me my name is Andy Grabner been working for a company called Dynatrace for 14 years and I just I just happened to be yeah we wanted that was very fortunate to be one of the speakers at DevOps Day Rally which actually happened last week because at the time of the recording talking about something in the past so the conference is already over it was great and I moved on from Raleigh, North Carolina to some other places. But I really wanted, I learned a lot in the last two weeks, visiting a lot of large enterprises and trying to figure out what they're doing around DevOps and SRE

and just giving them a little bit of my insights on what I think will help them. And with a lot of discussions about SLOs, I'm not sure, Brian, if you've ever heard about this term, SLO? BRIAN DORSEY- No, no, not at all. This is all new to me. SLO, is that like you want the website to perform slow?

BRIAN DORSEY- Exactly. That's the counter movement to performance optimization. It's like fast food, slow food. It's like fast websites, slow websites. Yeah. BRIAN DORSEY- Farm to table, developer's laptop to your browser without any testing or verification. We're just rapid production testing.

There's a movement. How about that? No, but I want to say, so maybe coming back to DevOps Rally, because it was one of the first conferences with a live audience again. That was actually pretty cool. It was organized by the team in Raleigh. They've been doing this for many years.

Obviously, it was tough during the pandemic. But it was a single-track conference. They also had breakouts with workshops, which was really nice. So people could then branch off in case they didn't want to hear some of the keynote speakers. I think some people branched off when I was speaking about Captain. It was okay.

Yeah, it is what it is. But I was allowed to talk about Captain, giving insights on what Captain is and why we built it and who is using it and got a lot of interesting And got a lot of interesting feedback and a lot of interesting questions. But I think I may inspire one or the other

to actually look into Captain, which is our CNCF project to deliver better modern data-driven orchestration to the SRE and DevOps community. MARK MANDELMANN- So before we dive into that, because you know I like tangents, I do have to's what's stuck in my mind with everything in a Raleigh is back when I was a kid not a baby goat but a child a human child and I should mention that because I've been watching Blade Runner 2049 which is a fantastic film and replicants and all that but anyway Raleigh fingers was a pitcher I think he

was a pitcher for the Pittsburgh Pirates and this is in the 80s and his claim to fame was having a big handlebar mustache And it was just the craziest things we used to get these little sticker books for the baseball players and all that and stuff And it was always he was my favorite just because he looked the goofiest And you keep on saying Raleigh and every time I hear the word Raleigh I can't help but think of him but I should be thinking about captain instead because you know it We've talked a lot about Captain in the past, right? And for people who've been listening thus far, they know what Captain is. And this podcast is not strictly about Captain. It's going to be about a lot of things concerning the conference, but you mentioned what Captain does

and you gave a little brief mention of it. But for people who are joining who maybe don't know the history of Captain, can we just start with a summary of the overall picture? What's Captain for and why is it awesome, besides the fact that you work on it? Yeah, and not only me, there's many people working on it. But I actually want to explain it, because when I showed captain to some folks at devops days before my talk they said well this is just another uh if then then this tool right if if this is the case then do this so basically where captain originated was we internally three four years ago tried to build and connect all the different tools we see internally and externally for delivery and all the remediation where it's a jenkins a jmeter a slack different tools that basically help you in your job to get

code pushed into production and also keep it in production so we build together a lot of scripts that kind of connect them and then we realize man this is really hard yeah and especially if we are doing this and it's hard because we need to maintain these scripts and these tool integrations. And if, let's say, all of a sudden the API of a certain tool that I'm using is changing, I need to update all of my scripts. So we said one of the things we need to solve, we need to make it easier to integrate tools or to connect them. And then we said, you know, what we do as humans, we always execute an action and then we look at our logs, our metrics, our traces. So we look at observability data and then make a decision what to next. So we said if we want to build something that helps modern DevOps engineers and SREs, reliability engineers,

then it should be something where we solve the data driven aspect. So observability has to be a key component of the orchestration we're building here. And the second thing is we want to be able to connect it to any type of tool without having to think about how we connect these tools to the orchestration. So I don't want to build and maintain scripts that call tool A, tool B, tool C. And this is what we're doing now with Keptn. So Dynatrace was the main driver behind Keptn, it still is, but we donated Keptn to the CNCF, I think two and a half years ago. So the CNCF is the Cloud Native Computing Foundation.

We're just in the process of becoming an incubation, going into incubation status. So if you listen to this, we might already be there because the public commenting phase on the incubation status, reaching that status just started. So it's just a couple of days away that we actually become incubated. But really what we, the reason why the open source community is so helpful for us is because we now have an audience in the community that helps us define an open standard on how these tools interact with each other. And CaptainLess is already baked in.

It's an event-driven model, and we're currently standardizing the payload to, let's say, call a deployment tool, call a testing tool, call a testing tool, call a notification tool, call an observability tool, right? All of these, there's so many testing tools and notification tools out there, but all of them have their own proprietary API. We are now trying to standardize this through the open source community. And I think that's a big benefit for everyone who has ever written automation orchestration scripts, because it's a pain to keep them up to

date and it's also a great help for everyone that wants to bake observability into their delivery pipeline and also using it for auto remediation because that's the second big use case we cover with captain let's say you get an alert from your monitoring tool something is broken then you can have captain orchestrate the remediation bringing the system back to a healthy state. And the healthy state is defined, again, by your monitoring tool. So you have a goal-driven remediation. The goal is to keep the system back to a healthy state,

and Keptn helps you to get there. MARK MANDELMANN, That's really awesome. So beyond the idea of integrating tools so they can all talk to each other in the pipeline, and you can swap them out easily, if I caught what you said in there, you're also part of the project is also trying to standardize that API so that all vendors will be using a similar API so that for anybody who's integrating anything together, it'll be easier. They'll have a familiar API to work with. So it seems like a lot of vendors or several vendors at least are starting to get on

board with that, which is really awesome. What's it like to be part of the team driving some of that change? We often, I think a lot of tool vendors, at least try to build integrations to work with it. But what Captain is making, I guess, some headway on is getting all the different communities to come together on this API, which is bringing people together in the end. Does that feel cool? Or is it just like, yeah, well, this

is just what we do in computing? JAN-FELIX SCHWARTZMANN- No, it feels cool. And I think what's great is that we have other projects that try to solve the same thing in other aspects. So think about OpenTelemetry. OpenTelemetry defines a new standard across all observability platforms.

And it just makes it easier for the vendors and also makes it easier for the users. And this is the same thing what we want to do here. We want to define what OpenTelemetry did for observability. We want to do the same thing for orchestration. Right. And then I think going way back to the early days of Captain, one of the other cool aspects of it that I thought was really admirable was, you talked about this certain setup that we had within Diatrace in our tool sets. But anytime we talk to people, you know, different teams have different tool sets. So one might be

using Jenkins, one might be using some other pipeline tool, one might be using whatever different tools in there. And number one, maintaining that coldness code is very, very difficult. So standardization is going to help there. But then also, once you have these, I think you called them uniforms in the past, right? The idea would be, if you want to swap out, maybe Team A is using tool X, but they want to swap out to tool Z, it's just going to make that swapping

and changing a lot easier. So they don't have to go back and start from scratch and write everything that's, quote unquote, plug and play, if we go back to that old phrase. I guess there was some good in plug-and-play. Yeah, and in this case, it's plug-and-play. For us, it's event subscription. So the core of Keptn uses events, so it sends events,

and then it can subscribe to a certain event for a certain project. And as you said, as an organization, I can define my DevOps process, my auto-remediiation process once with Captain. We call it a sequence. And then the individual teams for their respective apps can then decide, OK, what type of tool do they subscribe to for the deployment, for the testing, for the notification, for observability?

And the process never changes. It's just the subscription of the tool changes. MARK MANDELBAUM- Yeah. So I imagine after your speech, did you get a standing ovation? but the process not never changes it's just the subscription of the tool changes yeah yeah so i imagine after after your speech uh did you get a standing ovation and you have to sign any autographs afterward uh no well i did something uh something else to motivate people because we had like a box of captain t-shirts and i was lining them up and then people kind of rushed and i think that was the only reason why i actually cut them off their seats. The power of the t-shirt. It's amazing. It's a beautiful t-shirt too though. Right. I mean, and yeah,

now it was, it was a great conference and I got to say thank you also to, to our Dynatrace team who helped me in North Carolina because, you know, the initial motivation to, to fly over to the states was DevOps State Rally but then I said hey if I'm already in the states what can we do so we did a lot of visits and workshops with customers in Charlotte in Raleigh itself and then this week because it's already the next week after the conference I spent four days in Texas and did Houston and Dallas. It was just phenomenal. We spent typically between two and four hours with individual organizations and showing them our best practices or what we think they should do in order to become better in their DevOps

practices and their SRE practices. And it was great. That's awesome. Yeah, I miss doing all that stuff. I haven't done that kind of stuff in years, but it's always fun getting out to the teams using all this stuff and helping them see things they hadn't seen before and opening up paths for them to move forward on.

So that must have been exciting. With the conference, I imagine you had a chance to check out some other speakers and talks. Were there any topics or trends that you saw that really caught you? Or not just topics that were like, hey, that's a really cool topic, but are you starting to see any new trends based on what you're seeing at this conference? I think what I've seen there was one talk about observability, actually enterprise-wide observability for microservices. That was great. And it's kind of, it just

shows that observability is a key topic that is very relevant for the DevOps community. The second, and I think we've invited her to also do a recording at a later stage on our podcast, was around chaos engineering. I mean, we had Anna Medina on chaos engineering a couple of months ago. I think chaos engineering um i mean we had anna medina on chaos engineering a couple of months ago but i think chaos engineering is yet another great discipline that helps you know devops engineers sres to really ensure that the systems are resilient um but mainly she was talking she's from pager duty she was explaining basically uh her talk was around planning the unplanable

because outages are, you know, I'm planable. There's a lot of, you know, they happen and then you have unplanned work. But obviously if you are doing your homework, if you're doing chaos engineering upfront, and if you do game days, which means you can get the practice, first of all, if something bad happens, but it can also detect any problems early on so that they never make it into production and I'm really looking forward to having her at the pond the podcast in a couple of weeks from now but what I also I think that the conference was one great thing yeah

DevOps days but what I was really what I really liked was again the interactions with with the accounts that we visited and here the big topic was SLOs, so service level objectives. Oh, that's right, yeah. See, there was one more thing. What was interesting for me, I'm not sure Brian if you know, but we recently

published the state of SRE report from Dynatrace. I haven't seen that yet. You should check it out. You should check it out um you should check it out yeah because we did a survey um across 450 sres globally we actually had you know who we had we had stephen townsend um uh from iag he's down in new zealand he's a good friend mark tomlinson he's been yep and also henrik so he was actually also giving some feedback on that report in a quote but what was interesting slo service level objectives is kind of the big thing in in in sre right you want to define your objectives and based on that you decide you know also focus your

actions when um and out of that report we learned that 99 of people that responded to our question on whether they are good with defining slos 99 said no it's challenging right for multiple reasons too many metrics too many sources to choose from not a good definition of what a good slo is and so part of my um my tour the last two weeks was with every organization I talked to, we went through a little workshop on, first of all, what RSL is, what RSL is, what's an error budget, why is it such an important thing to define? And then we walk through the exercise of picking a critical app and then starting to define a top-level business objective.

So, for instance, the example that I brought was if you have a new mobile app that you're building, what's your objective from a business side? Maybe it's adoption of that mobile app. So you can measure that. And if you say you want to have this mobile app adopted by 50% of your user base by the end of the year, then that's a good business objective.

Then the question is though, all right, what are leading indicators? Because we need to break it down into something that's more tangible. So leading indicators would be app rating so rating on the app store what could hinder what could result into a bad rating versus a good rating crashes so we actually took an example of one existing customer where they told me they need to increase adoption that was the top level goal then they told me right now they have a two-star rating which is why the adoption is not as going as fast as necessary so we said okay the goal has to be to get to at least a four-star

rating like all the competition then i asked them what is the root cause of what are people complaining about they said mobile crashes so then we said okay we need to get mobile crashes down because if we get mobile crashes down we get the rating up and we get the adoption up. So we started defining a top level business objective of adoption, and then we broke it down into more technical metrics like crash rate. And then we went further and said, the first thing you do on the mobile app is you are probably authenticating yourself

with the backend system. So we need to define good SLOs for the backend system. It needs to be available. It needs to respond fast and it shouldn't have errors. And this was like a nice exercise that we ran through with all of our customers we visited. Then we showed them how you can do this in Dynatrace, how you can monitor those SLOs and how you can also shift left.

And this is where Kepton comes into play again because the core technology of Kepton, remember, at the core, it can evaluate key metrics against objectives so we can evaluate slis against slos and so i really had great great conversations um and i'm just very happy again to the diana trees team so helped me get in front i think we had 12 workshops in the last two weeks and we had a lunch and learn we had a two dinner event so three dinner events so we we made a lot of organizations from all verticals all different side different different level of maturity but everybody was clear on SLOs is what is important and they have a challenge

right now defining good as silos but they learned a little bit more about how to start with good SLOs. And that was good for me. Yeah, I think that's always a challenge. Anytime I talk to anybody, any of our customers about SLOs, the question is, well, what should we do? Right. And I think to your point, there hasn't been any strong guidance as of yet that I've seen in terms of here are the generic SLOs everyone should have.

And that's something that maybe you'll start coming out of this because there's two factors to it. Factor one is that maybe there are a set of good practice SLOs for anything that can be defined. And I think it's going to take the community coming together and putting together some best practices and people like yourself, helping them promote that so that people can go in and start with a basic set of SLOs. But then the second level of it is exactly what you're doing is teaching people to have those conversations to understand beyond the basics. What is our goal? What is our objective? And how do you have that conversation and turn that into more specific SLOs for that business requirement or that business need? And examples of those conversations and or learning how to

have those conversations and how to take those verbal requirements and then translate those into the proper metrics. That's going to be a little bit harder, I believe. But I think that's the thing that we have to help teach people how to do, how to have those conversations, how to translate that into the metrics so that you can then get not just the quote unquote out of the box SLOs, but the more powerful ones specific to the goals you're trying to drive. So yeah, it's funny that you mentioned that, that 99% of people didn't think they were doing it well. And when you think about it, it all lines up because it is, you would think it's an easy thing, right? Just need to monitor, right? But it's not. That's what

we've been doing for years. And that's why we're where we're at because it was, I remember going way back, I forget the guy's name from uh from cloud foundry way back at one of the performs what was his name uh bowtie um josh long maybe no no no he was uh from cloud foundry pivotal uh um oh yeah yeah sorry yeah yeah yeah he mentioned the one about like way back on the early days of the internet people used to have the uh the counter on how many people visited the website like that was some sort of metric. And it's like, metrics change as these things evolve. We all have to evolve and change what we're thinking.

And that, I think, is always a challenge in any aspect of this IT landscape, changing how you develop your code. Maybe, hey, I'm used to monolith. I've got to get comfortable with this microservice architecture moving there. Same thing with monitoring. Monitoring is not just throw something on and capture data. It's knowing what to capture, what to look at, how to use it, how to make sure through chaos testing that you're capturing everything you need to be capturing. So it is a practice that I think often gets overlooked because people are just like, oh, I just throw something on. It's going to tell me what I need to know.

As monitoring gets more advanced and more capable, you have to have people who know how to drive that. So it's interesting that it all bubbles up this way. Yeah, and I want to add one more thing to this, why this is so important. I had two conversations this week and they were saying, hey, we get a lot of alerts and a lot of problems getting detected and they have a challenge in knowing what is the one that they should basically tackle first and that's the way the slo's come in again right and we are now tying problems to slo's in the energy space meaning if you have five problems coming up then focus on those that actually have a business impact which is that is actually impacting the slo because the others might not be that important another conversation i had um was he was he showed me like all the work that he's doing it was awesome like performance optimization then i said but why do you optimize do you have a business objective for this like is business asking for a better performance because right

now you're losing people no we don't really know this but we're just making things faster and it's great to make things faster but then the question is might there be other goals that are more important to actually fulfill the business requirements and and then they all realize it is definitely a gap between what they're doing on the technical side with their business objectives and so i think that was just a big realization that the gap here yeah it's funny it's funny you mentioned that one because we used to talk about that a lot when we started talking about DevOps and then BizDevOps and all these different aspects of communications opening and performance team talking with the product team to understand what's important, not just monitoring. but optimizing blindly isn't necessarily going to drive better business or better revenue, or maybe even getting the recognition that you hope to get out of it, because if no one's seeing it or noticing it, they're not going to notice what you did.

So having those conversations, breaking down those walls, breaking down those silos, going back to that thing, which, you know, let's face it, we still see silos all over the place. I even see silos within different areas of Dynatrace right it's and it's it's a hard thing to get past but when you have those conversations if you're looking at I want to optimize when we talk to the business team let me talk to the product team about what they're driving goals are and then start aligning it to that that's when you really start excelling but you also just build those friendships and those bonds and the awareness and it's it's a fantastic thing

yeah i had one more one more kind of interesting conversation it was over dinner and maybe i already had two or three too many beers and wines but an analogy came up because there was one one of the people on the table he was saying he he really you know he he had the challenge of microservices and containers he said microservice is a container. So he kind of thought that the two go hand in hand. And while they often go hand in hand, what he didn't understand, what we tried to explain, is that microservice is the way you build the app and container is just the way you decide to deliver the app.

And the analogy that I brought up is, I can also deploy a monolithic application in the container that's not no difference and the analogy that I brought up you know you can go to Amazon or whatever you retailer you like and you buy ten items because you want to buy I don't know pick I think maybe we talked about kitchen like putting buying kitchen equipment table chairs and everything and I said you, you can order 10 things, and then Amazon can decide to wait and put everything in one big monolithic thing,

and then it ships to you as a container. But the other thing is what you can do, you can break this offer or this order into individual pieces, and then maybe the tables can already be deployed to you via drones because they're smaller. But maybe Amazon still decides to ship everything in the container because that's the better way. So my analogy was that containers is the way you deliver things and microservices is just the way you architect and break down a larger problem into smaller pieces. And there was just a confusion on the table that they thought containers equals

microservices and that's not true right and i just wanted to bring this up because i think we still need to educate people um and a lot of people are thrown into this new terminology now and they all of a sudden have to deal with this these topics in the organization and therefore we need to educate them what this really means. Yeah Yeah, that's very important and I'd be curious to see what these tables are that are small enough to be delivered by drone but Maybe those beers are still working. No, I think that's a really important one because we see that all the time, right? There's I was just having a conversation with somebody as well who did a lot of

Migration from people's data centers to Amazon or whatever cloud you want to put in there. But this conversation was specific to that. But what we're still seeing a lot of, and this person was mostly working with, was the literal lift and shift, not the cloud native transformation at the time. It was just take whatever I have, now I'm going to run it in containers. I mean, I've even seen people, and I'm sure you've seen it too, where they'll spin up Kubernetes and they'll run their monoliths in containers on pods. It's like, you can do that, but that helps define it, right?

Because the fact that you can run a monolith in a container helps put that piece together. I do like your analogy. That's going to be a useful one because we're actually helping trying to have some of these conversations with the sales team so that they have more of a basic understanding. And I'm going to steal that analogy, if you don't mind. No, that's good. I had a second analogy, too.

Yeah. And again, this was after one more beer, I think. And the analogy was because we said, I don't know, of the conversation of harry potter came up so magicians and i said you know jk rowling the author of harry potter could have decided she is uh waiting all these seven years and write like the whole story in one big book this would have been a monolithic approach and then you could buy it as a big big book and then just read it or you know you break the big story into individual chapters like she did and then from a delivery model you can decide do you buy a paperback or do you buy it on your kindle that's the difference between monolith and microservices and the way you

deliver it it can be paperback or it can be electronically. There you go. I had a whole one I was trying to work out through my head for the difference between bare metal, VM, container, and then Kubernetes, all based around a plot of land, a house, multi-dwelling units, apartments, and then a hotel.

And relying on shared utilities, just all this stuff. So I haven't gotten it. I think these years are so much simpler because mine got really complicated. It was one of those shower thoughts I was having, and it got really, really complicated. I'm like, you know what?

This is getting really ornate. But there's a lot there to it, but I think yours just go a lot clearer. But I like the hotel and energy because I assume what you're meaning with hotels, if a lot of rooms and they need to be managed and this is where kubernetes comes in yeah yep but each room could have its own each room could have its own kitchen or bathroom or whatever it needs in it it only has what it needs into it if you want to do one of those longer stay hotels you can have

rooms with the kitchen in it with as well um so that's in terms of the you know the vm versus the full os or the bare metal is that you have only the pieces that you need running in that small section. But meanwhile, the hotel needs the entire infrastructure underneath. And you have people who manage running the hotel. And then you have a separate staff who are the developers who are managing the rooms and the guest services and all that. Yeah, I mean, it all fit in. But it just got really, really ornate. So if you built a house, you would need another plot of land to build a second

house which is you know bare metal as opposed to maybe doing multi-dwelling units would be vms like you know anyhow yeah going back i think i overthink things andy so you're fantastic you are the summer eater after all um so you've been traveling how you know, and I know you just, I'm trying to think, how was the, in general, I mean, I think people are going to start going back to conferences, right? Obviously, there's still some issues to mitigate, and there's still some risk for a lot of people, especially if you have health concerns and all that. But what was the general mood? Were people just, like excited was it uh was it that like you know a roman orgy of people being excited or was there some caution like the general tone what are you seeing people coming back into this yeah i think the general tone was really positive that people

see each other again yeah it was one thing and this was true for the conference as well as with the meetings with with clients because for most of them it was the first time after two years to actually go back to the office and see people again. The downside was some people were complaining about the traffic is so bad and they had to waste an hour to get from their other meeting that they did at home to their meeting in the office. So there's always a give and take from a conference perspective what I've seen already in the past but you could decide in the beginning based on the lanyard, the past, but you could decide in the beginning based on the lanyard, different colors, and you could basically say you're okay with,

with handshake, you're okay with, you know, as you can basically say, what level of comfort do you have in terms of social distancing? I thought that was really good. So I could immediately spot people, those that I can hug and those that I rather, know be be careful with because they aren't comfortable with to being too close so i think that was good um no but overall it was it was great right and um and i'm sure we will uh hopefully we'll keep the hybrid option yeah because it just opens up things to a larger audience but there is an advantage for certain things of just being face-to-face with people. Their socializing is different. The interactions are different.

And just the general networking too. A lot of times with these conferences, it's a great place to network and help just meet people in different areas so that you can branch out. And hopefully people aren't looking at it like, oh, I don't want my employee going there because they might get stolen somewhere else.

As opposed to having the idea of like, hey, if my employee is learning and growing and finds a better opportunity, I would encourage them to move up instead of me holding on to them. It's always painful to lose somebody, but it's much more rewarding to see them flourish. But yeah, that's fantastic. It's great to hear. We're going to have our own event by the time this airs. I think we're going to have been in L.A. for some traveling. Are you going to L.A.? No, I'm flying home now. I've been here for two weeks.

You beat. No, not beat, but I think I'm good now. I've done my job here and I think there's others at SKO that cover the topics that I cover. I was looking forward to hanging out with you, but I guess not. at SKO that cover the topics that I cover. That's all good. Oh, well, I was looking forward to hanging out with you, but I guess not. I imagine a million people would have been looking forward to hanging out with you. But, all right, yeah, well, you go home and rest.

You look a little beat. You sound a little beat. You sound exhausted. Yeah, it's been two long weeks. And as you know, when you travel internationally, I still cover the time zones that I normally cover so it's early days and late nights

awesome any wrap ups any takeaways you want to bring up no maybe just you know don't forget that whatever we do as an industry we should make sure we align it more to the business needs because that will really help us to focus

on what's really important. I know we can do 10,000 things, but let's focus on those that actually have an impact. That's my advice. Yeah, and keep a lookout for Captain on the CNCF, everybody. Hopefully, that'll be out there soon.

Come to KubeCon. If you can make it to Valencia, we are at KubeCon in Valencia. And on the SLO topic, both Rob, Henrik, and I, soon come to cube con if you can make it to valencia we are at cube con in valencia and on the slo topic both rob henrik and i we have speaking slots at um open slo and also wtf is sre so what the fuck is sre i guess that's what the wtf stands for yeah no, what the fudge? No. What the fudge, yeah. I did a, speaking of SRE and DevOps and all that, in showing the difference between smart monitoring versus old-school monitoring,

I used to have a dashboard up that had maybe 100 metrics on it. It was just like an awful, awful dashboard. And I called it the WTF dashboard. And I would always introduce it to say, I call this the wtf dashboard because when i look at it i say wow that's fun wtf you know because i could i didn't want to say that in front of customers obviously so i would i would get them thinking i was gonna say the awful thing and then switch it but yeah um cool awesome so everybody in valencia valencia is in sp Spain, right? If I recall correctly? No, you got your geography right.

I'm sure there's a Valencia in the US as well, but I'm talking about the one in Europe here in Spain. Yeah, I like Spain. Anyhow, all right. Well, everybody, if you're comfortable getting back out to conferences, go for it. It sounds like it's very rewarding, very enriching and get back to a little bit

of the old way of living but not too much of it I guess. Let's leave the bad parts of the old ways of living and embrace a new paradigm of good ways of being with each other in public and treating people with respect. I love the fact that they're adding those what I'm comfortable with tags on the stuff.

That's really awesome. Anyway, Andy, thank you so much. Now you're going to catch a flight, Mr. Jet the stuff. That's really awesome. Anyway, Andy, thank you so much. Now you're going to catch a flight, Mr. Jet Setter. Enjoy getting back home. Enjoy some rest. Enjoy reuniting with Gabby. And hope to see you at some point soon. Thanks for being a guest on the show, Andy.

I really appreciate it. Yeah, it was an amazing experience. Maybe we can have you back on. Yeah, maybe. Well, let's let the audience judge, right? Yeah. See how I did as a lead interviewer. This is why I don't lead these as much people.

Come on. All right. Thank you, Andy. We'll see everybody next time and stay safe. And if you have any questions, comments, pure underscore DT at Twitter or pure underscore performance at dynatrace.com. Love your feedback. Thanks a lot, everybody. Bye-bye.

Bye.