DevOps Performance Trends for 2024 with Scott Moore

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, it's Joe and welcome to another episode of the Testkill DevOps toolchain. And today you're in for a special treat because we have the one and only Scott Moore joining us to talk all about DevOps and performance trends for 2024 as well as what the heck is DevPerf Ops? It's been everywhere. So really excited to get his view on this. If you don't know, Scott has over 30 years of IT experience with various platforms and technologies. He is one of the main thought leaders I go to for Anything performance testing DevOps. He's an active writer, speaker, influencer and host of multiple online video series that we'll have links for in the show notes for this as well. And this includes the performance tour that you definitely need to check out. He actually goes around and does education things and has a really cool setup where he interviews people on the road, which is cool. DevOps driving, which I think is new. The Security Champions, which I've just heard of, and the SMC Journal podcast which is a must listen to. He helps address multiple client complex issues and concerns around software engineering, performance, digital experience, observability, DevSecOps, AIOps and now DevPerf Ops. You don't wanna miss this episode. Check it out. Hey Scott, welcome back to the Guild.

Wow, that was a mouthful. You know, it's good to be on the show with you, Joe. I'm just trying to keep up with you, my friend. I don't know if that's possible.

Yeah, I do a lot, but man, you've been really adding stuff to your plate. So I don't even know what, like what's your main focus right now?

Well, I'm kind of all over the place and it's because a couple of things. The performance tour will continue. It's going to keep on going, but we've got so much material out there. But other companies have come to me and said we'd like for you to talk about more than just performance because there's a wide world out there in software engineering. We want to be part of the conversation too. Why they want me to talk about that, I don't know, but I'm willing to do it. So we've begun expanding into topics like DevOps security. And I'm doing even stuff with like networking and unbreakable Internet mobile connectivity and AI, of course. Got to talk about that to be in any conversation. So I'm just talking about everything, I'm interviewing people, but I'm also providing my, I guess 30 years of subject matter expertise as well.

Yeah, so I guess that's one of the trends. This show used to be called the Performance Podcast and it just felt like it was very limited and I felt like it should be part of the bigger conversation around DevOps. And actually this is, I guess we'll go into trends first and then I want to get into the perf ops things because I ran a survey that said do you think performance testing belongs in DevOps? When I did it, majority of people said no. And I thought that was crazy. I think it does belong as part of DevOps. So I guess the first thing is that one of the trends you're seeing then, not only that people are becoming more concerned with performance, but not just in maybe how we used to be back in our day against you know, really black box type of performance testing, but more of a conversation where the whole team is now involved and it's not just a specialty of one person and one small team.

Yeah, it's just such a wide net that you, when you say performance that you're casting this huge net out there. Is it the performance of the hardware that's a whole specialty in of itself? Is it the software is the end user experience? All of those things can be a specialized skill set and it takes a long time to really build up all of the knowledge you would need to get the breadth that you need. So I think we've lost a little bit in context around what is performance engineering, what is performance testing? How does that relate to microservices and new systems versus systems that are traditional or legacy systems? And now we're hearing more about reliability and efficiency and I think that's where we're going, is reliability and efficiency. Performance is all part of that. But we maybe we've forgotten about that. So that's what I'm trying to bring that to the table.

So why the focus now on reliability? Is that because of cloud native and you can't really, back in the day we could control what the software was, the services were, the hardware were. And now when you're in production, like customers kind of out of our control. So now we need to focus in on production type of performance.

I think that's part of it. I mean I think we had so much lift and shift without optimizing when you did the shift that there was this oh, what is going on moment. You know, for lack of a better term, once we got it out there into production, we started seeing those cloud bills and all of a sudden a whole movement comes out called finops. And all that is short for is managing your cloud cost, the financial aspect of it. But if there was an efficiency and there was an optimization that went with the lift and shift, you probably wouldn't have had finops come out as strong as it did because you would have had that savings from the get go. And I think that's the part where performance engineering can play such a big role in that. So it's partly cloud native and it's also these skill sets that are part of knowing how cloud systems work versus your on prem and now multi cloud as well, hybrid cloud. So there's a ton of stuff going on and we got to keep up with it.

Absolutely. So Scott, when I think of you, I think of performance engineer, you and James Pulley come to top of mind. And I love performance testing. I started off as a performance tester. Is that kind of roll dead then or is it like where do you see it? Cause I was kind of not surprised you changed over.

But like, is it morphing that I changed over to. To what?

You changed over more to like in a DevOps context. Context rather than.

Well, yeah. I mean you have to, you adapt or you die. Right. And you have to look at what's happening. But whatever you call it, the same rules apply. You know, physics hasn't changed. Right. There are resources that get depleted when they do, problems happen. When things aren't efficient, they cost more. When things aren't tested, there's more risk involved. Those things are going to happen no matter if you call that person a performance engineer, systems engineer, software engineer, whatever, whatever label you give it. I think what has really bothered myself, and I'll try to speak a little bit for James because I know him so well, we've been really concerned because there's been this, I guess a cultural mentality that when you go from testing to a developer, you've made a step up, that the developer is the goal and that testers are an entry level role that just attain to be a developer. And we come from the school that a developer is merely an incubation point for defects. You're a defect creator that's creating all the work that we need to do to fix your stuff. Right. And so we Feel that an engineer that is in quality testing, performance, security, we need to know as much or more than a developer knows about even their own code so that we can say here's where you missed it, here's where you need. And that has not been. There's a cultural shift that happened several years ago that says if I don't know how to code, I'll test, I'll poke around and I'll attain to be a developer once I learn real skill sets. And I think that's a tragedy.

Absolutely. And a few thoughts came to mind here. First, one is AI. The other is this has been a battle for 20, 30 years of why do companies do think undervalued testers then? In the sense that they see as a cost center rather than a value add. And you just mentioned like all these bugs that can occur across the whole tech stack where testers are ideal to find them and actually add value so when they go to production, they're not going to lose downtime or even brand type of reputation.

Well, remember when the Agile Manifesto came out and we started moving to do more with less? When did that happen? Around 2007? Ish. What was happening with the economy around 2007, 2008. That was a reaction to that. And what we found was there were testers who were not providing value. They were charging a certain amount or cost, a certain amount of unit in a company, but they weren't providing the value in the, I'm talking about in the eyes of the executives. Right. And so the sound of money to an executive is code in production not being held up by a tester. If the tester is not seen as providing value, they will always go for the lowest common denominator. To get that, they may still have to do it because of regulatory reasons. We have to check this box and it became a checkbox. But without actually doing the real checking that needed to be done, the real wringing out of the defects out of that system. So if you're not being provided value at $150 an hour, you're going to find something for $50 an hour. And if you get the same thing, that's the point. And I think that is also a tragedy. And I, I can't take the full blame. Obviously I want to take blame, partial blame for this because I feel like it's people like me and James and the people who could be teaching classes or affecting the education system to bring this at an earlier stage where people graduate from college knowing these performance engineering and system engineering principles. That used to be part of it. Just, I don't think we did a good job in the performance community of passing that torch.

Absolutely. So as part of that education, though, you speak to a lot of people, I assume a lot of executives. You go on the road more than anyone I know of. Do you see this coming up as part of conversation then, where they're aware now, or are you making them more aware? Are you surprised by maybe how more aware than you may have thought?

I think now the awareness is because we can now see when they're on the cloud, we can see how much it costs for poor performance. And when you hit them, when money is involved, all of a sudden ears perk up and we're interested. Right. So the conversation always has to be, do you know how much money you're leaving on the table? Because you are not addressing this. And from money, then goes risk. So I can guarantee you that those are two things that will get the attention of the cfo, the CEO and the cto. And that's what's keeping them up at night. If you can address a problem that's keeping them up at night, you become valuable to that company.

So that's interesting. Like, a lot of times, I do think it's Tesla's responsibility to be an education component of their job. Do you think they should have this conversation with their Sprint teams? Hey, are we looking to performance? And if so, do you know this costs X amount of money if we don't do this and this? Do you recommend that as a way to get performance baked into the application from the beginning?

Well, there should be a conversation happening about it. Anytime there is a functional question asked, there should be a performance question asked, there should be a security question asked. Those things should be in every conversation. But. And it should be ingrained. So how do we get it ingrained? We've got to start the conversation. And sometimes that conversation needs to be a large poke in the eye to get people interested. And that poke in the eye was, look at the bill, look at the cloud bill. Why is this happening? What are we actually paying for? And that's where it starts. And also people like me who start up, you know, crazy ideas and then just get people ticked off. Because I just look at what's going on in the market and I'm like, somebody created some idea that we're going to do this. Maybe it's Google, maybe it's Facebook, maybe it's Netflix. And they're great engineers. And for their business model, whatever they came up with, it worked for them and it's great. But it may not necessarily work for your company. Everybody doesn't have to be Google every for it to work for their model. And it may work better if they don't do what Google does. I think people forget that.

Oh my gosh, it's like a copycat syndrome. You're in an insurance company or a regulated company and they're trying to do what Google does and you can't. It doesn't even make sense. So yeah, I love that. And that's something you've been seeing as well then people trying to do something that may not necessarily fit to the context of what they're doing all the time.

A perfect example is I was at a Perf Tour live event and they're like, well, we do the Spotify model really well. Explain what the Spotify model, they just copied whatever Spotify did. What did Spotify do? They looked at Scrum and they looked at traditional Agile and said, this doesn't work for us. Let's change it to what worked for us. And that became their model. Now people want to do a model that was a customization of something else. Instead of customizing it the way Spotify did, they just clone it. That's not the solution. People are lazy and they're looking for low hanging fruit. It's not always that easy.

How'd that conversation go? Did you tell them, hey, you may want to rethink that?

Yeah, they. It didn't go too well, Joe. I don't know if I'm allowed back in that town actually.

Awesome. There's some other things you've been seeing. Like I said, you speak to a lot of people in this space on the road a lot. What are some other trends you've been seeing, maybe that people need to be aware of, especially in 2024?

Well, in my area, the thing that keeps popping up obviously is AI. You know, what is this? Is it going to hurt me? How can I learn this? How is it going to affect my job, those type of things? And where does it fit in? Where do I see that it's going to help? And you can't talk to anybody about 2023 without saying AI. Obviously it had a huge impact, but we really haven't seen what it can do. We're in that Gartner hype cycle, you know, model right now and it's in full hype. I think it's going faster than I think we ever thought it was going to be. To where maybe this year we'll be able to see what it can really do because we see new innovation like almost every day, but I think we're going to see it assist in automation. I've already seen that in some of the products like Tricentis has the Testim products and they have TTM for jira. You can take notes from meeting, put it in as bullet points and you've got test cases built for you, requirements built for you. And it does all of this without very much input at all. I mean it's something you have to tweak it. Obviously we're going to start seeing that same thing I think in performance testing tools, load testing tools where it provides guidance on test results and analysis. I think it will provide better modeling and forecasting and observability. Helping you tell what? Well here's where it looks like your business, how you're actually doing, but here's what it looks like you might be doing three months from now. I think we're going to get closer to that in 2024.

Absolutely. And you mentioned a good thing, AI. I thought in functional testing it's been a big buzz but I always thought it would fit better with performance type of things. Especially with the machine learning part of reading logs and doing correlations for you automatically being able to actually read a bunch of data, give you bubble up insights. So does it seem like performance tooling then is lagging behind even automation, front end tooling or is it just right now?

I think it and I think it's here's my theory. This is the Scott Moore theory because many of the load testing tools never focused on analysis first they were concerned with generating load. Anybody can generate load, I can generate HTTP traffic on a website all day long. But unless you have really good in depth analysis where you can correlate and cross reference the data, what's the value? And even if you can do that, the value of those results have a very small time window because as soon as you've made changes to the system you got to do it again and get the. That's where I think AI can really benefit in the analysis part and the forecasting and noticing anomalies, that's its big strong point and that's what we need is noticing anomalies and relationships that we never thought went together. Well the reason this transaction is high, we thought it was because we were CPU bound, but AI found that the reason you're CPU bound is this other thing upstream or downstream that wasn't necessarily showing up on any radar and traditional graphs. But it found that relationship that's where I think we're going to see the improvement.

Absolutely. I know like I don't want to bring up JMeter and things like that, but a lot of these open source tools, I think we come from enterprise background where we have enterprise performance tools that actually had analysis and the whole piece is built in. So it is a struggle. So with AI then do you see that because it's a lot of them is not open source that the adoption is smaller or do you see people actually seeing it as a value add where let's invest some money in some AI tooling then to help with this?

I think they will eventually have to invest money in something that will give them that good analysis back. And JMeter alone would never be, in my opinion considered a true performance engineering tool. It would be a load thrower, it would be a way to generate load. But as everybody knows, you have to combine that with other solutions kind of as a bonded solution together to get that value out of it. And the value comes when you start adding things like Grafana and other types of, you know, visualization products. That's where the key is now when you get that and you can apply AI to that now you've got something but it is lagging behind. Back again to why I said because these tools have not focused on analysis first and that's what should have happened.

Absolutely. You also mentioned something that's really interesting is that there's many kinds of performance out there. And one thing I see is a lot what I think is a good trend, I'm just curious to get your thoughts on it, is functional automation tools being able to bubble up insights on performance of a transaction over time. I've seen some companies that implement telemetry and tracing in the background of a functional test. And then even though you're doing a front end test, it could tell you hey yeah, you did this activity. But you know, in a service or database layer down here below, the milliseconds were are increasing or something like. And I think that's an awesome win win of functionality. Do you see that as a trend going forward, leveraging functional tests to get you some performance type of information?

I do. I think it is awesome. I think we need much more of it and I think we need to emphasize that. And every chance I get to talk to a functional test product maker, I always mention that I'm like this is a great automation tool that you've got. Do you have a way to put a little stopwatch timing around stuff in here? Whether it's from an end user perspective or do you have a way to monitor something, some way to come. And a lot of times they kind of look at you sideways. They're like, well, we're not a performance testing. I understand that, but do you realize just by putting that one little feature, you might save your performance testing group a week's worth of work? I mean, wouldn't it be great to know that it's already not passing for that one single virtual user running through that automated script? I think that would be great. And I think every functional automation tool needs to have a way to have timers in it of some kind.

Absolutely. So I'm trying to come up with a concept. You know how we have the testing pyramid? Like how about a performance pyramid? Like you said, there's many kinds of performance. Is there a way where like the base is minimum performance baked in, then mid layer and top layer is it all. Is that concept not really scaled to performance type of mindset?

I don't know if it's a pyramid. I think it's more like a circle, like a pie. There's. It's kind of encompasses everything and you just have to find out what are all the slices of that pie and where do they overlap. And I think that's something that. I hope that with some friends of mine we can start helping to define that and maybe come up with some agreeable standards on what that all means very soon.

Awesome. So what are some other trends then? Observability obviously has been big in opentelemetry. What are you seeing in that regard?

Well, at first I watched this all last year and I reported on it that the observability tool sets were saying, oh, you know, we've got AI. Basically what they did was implemented a chatbot that Talked to Chat GPT the way that you could from ChatGPT. You know, just throwing an API call out there and giving you some type of answer with the same amount of accuracy and context that ChatGPT 3.5 had. And of course it's getting better over time, but we're still without context. I think what's going to happen in observability Dynatrace was the first one to mention that I heard of is moving from just having generative AI built in to look at stuff or even just create custom graphs for you from a text. In other words, you don't have to learn some SQL query, you can just say computer create graph of blah blah blah and it'll. I mean that's great. That's Almost Star Trek, but I think really it's the language and text that's been modeled on that's called causal AI. Right. So I don't know if you've heard of that, but Dynatrace is saying, let's train this AI on the right documentation, the right information, and without all the extraneous stuff, so that we know when we ask this question about this topic, it knows the topic, it knows what the context is. I think causal AI is the next step for observability.

Love it. All right. Causal AI. Nice. Now, you mentioned developers earlier how you need to know coding with AI. I guess you need to understand coding, but it's not. I don't think it's going to be be like you need to be aware of coding, but not necessarily an awesome coder because you can kind of use AI to assist with that. Do you see that as a viable future plan or do you think that's all bs?

I really have mixed feelings about it, Joe, because I've asked it so many different questions and I've tried to get it to do certain things, and there are some things that it has done a fairly good job of, but there are other things when I actually know all the context behind it, some of the stuff I'm getting is very, very scary. And I'm thinking when you don't have that context and you blindly do stuff, especially when it's with code, you know, that's the problem. It's to the trust but verify. Right. And I think you just. You have to be that way. If you don't have the ability to verify, you may be taking a risk. And I'm. I'm just not comfortable with that right now. But I am a born skeptic against that already. I'm not a Luddite fully, but I, you know, I go begrudgingly into the void.

Absolutely. Once again, back to performance testing is. I had this on my list a few years ago as a trend shift left. Do you see companies actually shifting performance testing left, and if so, what kind of performance testing on the shifting left, if at all, that you're seeing?

Yes, but not enough. What we have found. And I've actually had this conversation many times with companies that are doing the testing and companies that make the testing tools. Roughly 4 to 5% of companies have successfully shifted left in the majority of their performance testing. I mean, they really get it and they're seeing good results from it. Now those who are doing it are seeing phenomenal results, very advanced stuff, and it's great. It's 4%. That's the problem. It's easier said than done. And you have to step into it very slowly. It's just. And it's. There are certain things that just aren't ready for prime time to shift left yet. And that's something that I tried this year for the Performance Advisory Council. One of my presentations was, can we actually use this new thing called. Well, it's not really new, but it's new to us, some of us. The extended Berkeley packet filter, the ebpf. We keep hearing about where you can get all this monitoring information, whether it's performance or security or whatever. At the Linux kernel level, a lot less overhead and can grab anything, create flame graphs, create all kinds of good stuff. And it's great for kubernetes, right? But it's not really ready for prime time. From my experience, actually implementing it line by line, we will get there. But that's another part of the problem. Trying to shift something like that left. You need to shift it left because EBPF can get so detailed it can trace every little tiny thing. You want that as far left as you can. Getting it working and getting it all running. You kind of have to hold your mouth, right, go through all the little tiny steps and hoops and you might get something. We need to make it easier for people to do that, in my opinion.

Absolutely. So judicial performance testing from a stress test, a load test perspective is getting easier. Back in the day, I used to do tests in a staging environment and then you released production. Never the same results because the environments were so off. Do you see containers being a way to enable consistency performance environments? So if you do get a result in your staging environment, it's basically just a duplicate of production, so you have similar results.

Yes, I do see that and I love that part of containerization because in 85% of the companies I ever consulted with, the environment itself was the biggest problem that they had and a lot of unknowns out there. So being able to just clone an environment and also being able to create a test environment only when you need to use it. So you're only paying for it when you need it. So this dynamic capability of creating dynamic infrastructure, that is a game changer to me. That's amazing and I would like to see more of that.

All right, so if someone does go with containerization, other tools now, or do you see tools coming out that can help you almost self healing to make it more resilient so that it automatically can adjust to do. Hey, this is a Bad role, a bad code deploy, let's roll it back. Or let's restart this live container or take care of the predictive auto scaling automatically. Or is that still a pipe dream?

I think we're starting to see some of that. I only know of a couple of companies but they're still sort of in startup mode. They really haven't garnered a lot of attention yet. But I think that's the kind of stuff that's in the works that we will start seeing this year. I don't think it'll take till next year, but we will start seeing that all of these rules that trigger things that will happen that will self heal. We really haven't seen a lot of good self healing stuff yet, but I think that's what's coming next.

Nice. All right, so I guess it's time to dive into dev perf ops. This concept I've been seeing everywhere and I never know what to. Because you're kind of like a. Not a trickster but kind of like a. You have a fun sense of humor and I never know if you're being serious or sarcastic with a lot of things. So what is devperf ops and is it a real thing?

Okay, well let's get one thing straight. I am always being sarcastic. Even when I'm being serious, I am always being sarcastic. You're not supposed to ever know if I'm being serious or not. And so when I started, I wasn't serious. It was actually an exercise in just making an extreme statement and just trying to see if I could tick everybody off with it. That's what it was. And as I ran with the idea, you know, if you take an idea that sounds like a decent idea and you just run to each extreme with it, you can start shooting holes in it. But when you take something to the extreme, you can't really shoot a lot of holes in it. You might actually have something. And so I was actually at the Performance Advisory Council about a month ago and I was with the Mr. James Pulley and four or five other noted performance engineers. And I just got ticked off because I started, I was looking up some things when I'm working on the Security Champions, I'm talking about DevSecOps. I just finished an interview with somebody and their whole platform is about DevSecOps. Their whole website is about DevSecOps. And I thought, hold on a second. I thought everything was just DevOps. I thought everything was either going to be in development or operations and we're all in one big kumbaya Room. Working together and testing gets encapsulated in that. But it's assumed that that is part of this. But in reality, we all know what happened. It's devs and it's ops and it's however your company defines that. And if it doesn't really have room for test, well, that's just what it is. That's again, Scott Moore's opinion. So I just kind of got ticked off and I said, well, hold on a second. If DevSecOps is really a thing, how do they get their own piece of that? How do they get to insert themselves into this title? So I go out there and I look, I said, well, who really supports DevSecOps? Guess what? You look on Amazon, one of the largest companies in the world, has a what is DevSecOps? They explain what it is. Go to any observability platform, go to Dynatrace, go to Datadog, look at their websites and look up what is DevSecOps? They got a page out there capturing all the SEO to explain to you what DevSecOps is, which means they endorse it. So you know what I did? I went out there to generative AI and I said, look at what DevSecOps is and change everything to be performance engineering instead of security, with the same importance and the same emphasis. Copy Paste created the domain devperfops.org because com wasn't available, created the website. Three hours later it was up. And I said, I'm the person who's going to say, so somebody somewhere came up with the term DevOps and said, it shall be. Why can't I be that guy? So I said, devperf Ops is now a thing. Put it out there and guess what? We already have like 20 companies who have already endorsed it and said, you know what, that's actually a good idea because it's at least as legitimate as DevSecOps. If DevSecOps can be a legitimate subcategory of DevOps with an emphasis on security, so can performance. So it is now a real thing. So I am in the process of working with legal and we are creating a 501C6 which is kind of what chambers of commerce. And we're basing it on the model of FinOps. Both the CNCF Cloud Native Computing foundation and FinOps foundation are both run by the Linux foundation and FinOps, actually before it was adopted by the Linux foundation, was a 501C6. And I looked at what they had and I thought, this is Brilliant. This is exactly what we need for the performance side. So I'm modeling it right after these same organizations doing the same thing, but instead of security, we're focusing on performance. That's it.

So I'm just surprised about the amount of. You're not getting. It doesn't. I'm not seeing a lot of pushback where people like DevOps should include security and performance. There shouldn't be these distinctions. There's always test ops, there's AI ops, there's all these ops, ops, ops, ops, ops, ops, ops. It's got to stop somewhere. So is it because people don't understand what DevOps is, that we're asserting all these things? Is that what it is?

Exactly. That's exactly. Somebody came up with something and then somebody adopts it for their own purposes and says, well, this is what I think DevOps mean. Words mean something, but they mean something different to certain people. Whoever's in control and got the biggest company and a lot of money, I guess they can do that. So I want to attempt to find out, like security, why did they come up with SecOps? You will find that they said, well, they're in DevOps, all these pure DevOps shops. We're still getting hacked. We're still having security issues. So you guys aren't including it, at least enough. So the security community got together and said, we're going to make sure you do take care of it, because we can't afford to get hacked because we're out of business if we do. So they were able to legitimately create that element to it. Now, I would agree security and not being owned by hackers is probably more important than having a fast website. But if your website is hackable, but only one is not hackable, I should say, but only one person, two people can use it, you're still in a lot of trouble. Right? Is it really functional if it can't do that? So we get back to the importance layer. Maybe it's not. But if you have a culture of performance like Google does, like Walmart does, like other companies, who Netflix did or does, why can't we have something that has that same sort of emphasis? You weren't handling performance, so we're going to make sure that you do handle performance and we're going to. So really, should it be included? No, I completely agree. But neither should security have their own. So when DevSecOps finally says, we give up, we're not going to have it, we will call ourselves DevOps and we will just have a guild inside of DevOps and we'll call ourselves Security Guild. When they're ready to do that, I will give up devperf Ops, shut everything down and go back to the way it was. But until they do, if they get theirs, we get ours. End of story.

So I don't mean to keep hammering this. How's this different than SRE then? Because I thought SREs are like the new performance type of champions.

I thought that as well. But as I investigated it more they're like, we really don't care about that a whole lot. We are site reliability engineers. We are there to make sure the site is reliable. Yes, we want it to perform and we will try our best to take care of that when we get around to it. But it's a matter of being up, being reliable and, and make sure that we reduce the toil out of the organization and the system and that's what we're going to handle first. And I have never met yet a site reliability engineer who has the same depth of skill sets around performance as any performance engineer I've ever met. And that's the problem. And neither will an sdet. An SDET is great at automation, mostly concerned about functionality. They don't have the performance engineering capabilities and skills and that's what we're missing. And again, we're back to it's foundational skills that should have been taught in school, in college, in a graduate IT degree, but it's not. So we have to change that. And if I have to piss everybody off by calling it devperfops until they pay attention and do something about it, shut me down, shut down devperf Ops by making this thing right, make DevOps right and we'll go away completely agree.

That's why every year at Automation Guild, the last two days I include performance testing topics, observability topics topics I think all testers should be. I think testers should own it. And so I definitely agree with you there. All right, Scott, before we go, best way to find or contact you, Ian, what are you most excited about or working on in 2024 that you jacked up? Up besides the devperf ops obviously is very cool.

As you can tell, I'm passionate about this. I'm excited as a mongoose and snake pit about this right now. No, that's just one of the things I'm doing. Got a lot of things going. I'm easy to find on LinkedIn. Helpcottmore Consulting would be a good email address for me, but you can find me on my YouTube channel and all these other sites. Performance tour is the performance tour. Thesecuritychampions.com, devopsdriving.com I mean, there's all these shows. I'm excited because I'm working with Tricentis in two aspects now we're continuing the performance tour, so you'll be seeing new episodes of that. You will be seeing also some parodies. I'm working on some new parodies right now, and they're going to outdo anything I've done before. Just be patient with me. I'm also working with tricentis on their DevOps line. So they have a line of business in tricentis specifically over DevOps and testing in DevOps cultures, and it's part of the testim acquisition. So I'm working with them on this DevOps driving show. So we're going to be discussing everything around DevOps, not just around the testing aspect of it, but that'll be a big part of it. Excited about that show. And then, of course, we continue to do the SMC Journal. The security champions. I was approached last year about doing something around security. I was sent to Black Hat and defcon, which was a huge learning experience. A totally different crowd than the testing crowd. And also Black Hat, totally different crowd from Def Con. Right. So I. That could be a whole interview on its own. The company said, we want you to do a show around security. And so that's what we're doing. We're interviewing thought leaders in that area and we're going to talk about all aspects of security. And then finally, I'm working with a company called West Networks and they make. And they work with a company called peplink to create these mobile cellular providing routers and switches. They. They do all kinds of infrastructure, but they will go to mobile units where there has been no Internet connectivity. And they make it almost unbreakable with multiple cellular providers. Plus Starlink, 24 Starlinks on a cruise ship. They bond them together as one big Internet connection. And I think 36 things have to go wrong before you won't get any Internet. I love working with these guys and I use their stuff when I'm out on the road to keep my Internet going as well. So we're going to be doing a show with them this year called Mission Installable. And it'll be sort of like something you might see on hgtv, but instead of a demo of a house renovation, it's going to be installing unbreakable Internet in some weird place and doing it in record time and for links of.

Everything of value we covered in this DevOps Toolchain show, head on over to test guild.com p.

That'S it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head on over to test guild.info and let's make it happen.