DevOps Transformation: Culture, Strategy, and Lessons Learned with Derek Ferguson

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. Today we'll be talking with Derek Ferguson, all about DevOps transformation, culture, strategy and a whole bunch more having to do with technology you don't know. Derek is the Chief Software Officer at Fitch where he leads the development of software used by investors to identify opportunities and quantify risk. Really interesting topic. We're going to dive into that as well. If you don't know, Derek also led the creation of the software system that enables or enables creation of sustainable Fitch. I guess we'll talk about what that is as well. And he's also a best selling author and speaker at many events. He has a really diverse background. A lot of things you don't want to miss this episode. Check it out. Hey, before we get into this episode, I want to quickly talk about the silent killer of most DevOps efforts, that is poor user experience. If your app is slow, it's worse than your typical bug. It's frustrating and in my experience and many others I talk to on this podcast, frustrated users don't last long. But since slow performance is as sudden, it's hard for standard error monitoring tools to catch. And that's why I really dig SmartBear's Insight Hub. It's an all in one observability solution that offers front end performance monitoring and distributed tracing. Your developers can easily detect, fix and prevent performance bottlenecks before it affects your users. Sounds cool, right? Don't rely anymore on frustrated user feedback. But I always say try it for yourself. Go to smartbeard.com or use our special link down below and try it for free. No credit card required. Hey Derek, welcome to the Guild.

Hey there. Thank you very much for having me.

Awesome. So when I looked at your bio on LinkedIn, you've seemed to have done everything. Just curious to know, maybe how did you get to where you are now as Chief Software Officer at Fitch?

So started my career back as the intranet was coming into vogue. At the risk of dating myself for an Internet service provider here in Chicago called InterAccess, the first company in the world to roll out commercial DSL access. Actually so great opportunity, straight out of college startup, you know, let me get involved in a whole bunch of things I might not otherwise have been able to get involved in that, early in my career, heavy partnership with Microsoft as part of that, which led to writing my first book, which was actually a study guide for one of their exams. And out of that wrote some more books, started doing the conference speaking thing. And then the way I tell the story, I was just sitting at my desk one day and I got a call from a recruiter saying, today's your lucky day, Bear Stearns wants to talk with you. And my answer was, who's Bear Stearns?

Never heard of him. Because yeah, it's techies, you know, stuff like that. It's not really something that was in our line of sight, but wound up working for them. Then JPMorgan Chase and then I've been with Fitch for a little over five years at this point.

Nice. So what is a Sustainable Fitch, what's that platform?

Sustainable Fitch is a really interesting endeavor. So it is part of Fitch Solutions, which in turn is part of Fitch Group, which is owned by the Hearst Corporation. But what Sustainable Fitch is focused on is ESG ratings for companies. So as investors look at their portfolios and think about where they want to put their capital, they have another lens through which they can look at things to figure out how does this company impact global warming, how does it impact what's its governance level in terms of accounting standards, what's its social policies and all that sort of stuff. So it's just giving investors one additional lens through which they can sort of think about what they want to do with their capital.

So I would assume I could be wrong, that a software like that would be heavily regulated. Am I right or am I wrong?

Well, so the interesting thing about the Fitch Group is we've got two portions of the organization. One portion is Fitch Solutions, which tends to be our data sales. And the less regulated portion, then you've got Fitch Ratings, which of course is a traditional ratings agency and it's extremely regulated. Obviously from a standpoint of DevOps that has all sorts of different implications. So something like sustainable Fitch new build, less regulated, we can move a lot faster in terms of the way that we roll out new technologies. Whereas, you know, with the Fitch Ratings piece, because of the regulatory impacts, you really have to be careful and thoughtful in terms of how you roll out things like continuous delivery, for example, because there are some key sign offs that you have to give some thought to upfront.

Absolutely. So when you were creating a substandard bulb fetch, did you create it with DevOps in mind? Like, did you think like. Or it wouldn't have to release quickly. So I Have to make sure that it's going to be able to fit into the pipeline and be able to handle rapid releases and things like that.

Yeah, so it was really interesting because with the original sustainable Fitch system, the initial attempt used a lot of the existing tools and technologies that were sort of ready to hand for the tech team. And as we looked at it, we recognized that there were some definite opportunities for uplift in terms of when you think about some of the data models behind environmental stuff, that's kind of new for a regulatory agency. Like we're used to dealing with financial data points, revenues, taxations and all that sort of stuff, standard accounting stuff. When you get into environmental stuff, you're talking about stuff like carbon footprints and all that sort of stuff. So there was the need to iterate and evolve much more rapidly than we had before because it wasn't just a new set of technology, it was really a new business. And that's a lot of what drove the need to adopt some of the newer technologies that we find ourselves using around not just the tooling terraform scripts to allow us to do infrastructure as a service.

But also a whole bunch of stuff with the data technologies that we use to make sure that their schemas are a lot more resilient to versioning as we move forward and stuff allows us to back out changes a lot more reliably than we had had in the past.

All right, so it sounds like you're working with newer technologies as well, plugging it in. Is there any best practices you found to make it so as you were developing, you're developing, maybe with the future in mind that hey, down the road we probably are going to have to plug in newer technology or mess with our data technology or schemas or things like that.

One that comes to mind is probably encapsulation, but I would say you want to make sure that you have the right level of encapsulation. I have worked in my career with organizations that have been so obsessed with not becoming locked into a vendor that they have not done what I would describe as sort of the right math around vendor lock in. If you're working with a technology which is on the bleeding edge and perhaps only delivered by one or two vendors, it behooves you to think, are you sticking to the standards or are you using more of the vendor specific functionality that's offered by those vendors and steer clear of them? It's very easy to get stuck with a specific vendor choice when you start using vendor specific extensions. On the other hand, I'VE had it at the other extreme where you know, you've had been dealing with like a large vendor that's been around for decades and is unlikely to go any place in the near future. And yet you know, this, this drive to say, and you see it a lot with like cloud providers. Right. Some organizations are like, I don't want to be specific to this cloud provider or that cloud provider. And to a certain extent that you know, you can see where if there's a standard for using a certain technology, stick to that. On the other hand, if you can derive value from a cloud provider and they're established and, and they have something which is unique and it gives you a competitive advantage, I think it's real easy to go too far and get into an area of paranoia where you don't want to adopt something just because I can't find this elsewhere. It's striking that balance, right?

Absolutely, 100%. You also mentioned Terraform. Maybe talk a little bit. Why Terraform now? Do you have infrastructure issues that you saw that needed to be automated or managed and that you thought, hey, to make this DevOps pipeline really flow, we're going to have to, there's something with this. And you chose Terraform.

Yeah, the vision has been and remains trying to get to a point where developers can send their stuff to production immediately when they're done with it and not wait for any human being to get involved and click buttons X, Y and Z to let them go. And you know, circling back to the compliance question that you asked earlier, that might mean something as fundamental as changing the regulatory sign offs that we're used to, from being at the end of the pipeline against the finished functionality to being against the tests that will make sure the functionality does what it says it does. With something like Terraform, it's not so much a human being sort of thing in terms of like processes and saying yeah, this is okay. I like this as just the idea that if a developer is going to be empowered to release their stuff to production as soon as they're done with it, the package that they're sending has to do everything, soup to nuts to get that out there. Not just lay down the code on infrastructure that is expected to be there, but also to build the infrastructure. Right. So that thus part of our, you know, looking at, well actually all of our looking at and embracing of something like Terraform to say, hey, let's empower the developers to say here are the changes that we need in our infrastructure in order for this new component to go out and run.

How's that worked? Has it helped?

I would say it's early days right now. It's definitely a net positive. You get into this thing where you try to figure out, do you. And this is true of all DevOps, right? Is it better to take the developers and give them the training that they need to get more knowledge of the operate side or to take the operate folks and give them the knowledge that they need to get more into the developer side, who owns those scripts. And it gets in the whole thing with, you know, you see permutations that with qa also, do you want the sort of thing where a given technical resource is sort of a jack of all trades, who knows a little bit of everything, or do you have these specialties thus far? I think one of the nice things about Terraform is the deep integrations that it has with our choice of cloud platform that sort of already exists has made for a pretty comfortable learning curve for the techies who've embraced it thus far. I won't say that it's seamless, but as we were looking at our different options, that close pairing between the tool and the underlying in our choice of infrastructure and we tend to be in AWS shop primarily has really worked out well for us.

Yeah, back in the day we had like a DevOps CICD team and they were kind of like a roadblock almost because developers would try to push things in and you'd have this group that like no or yes. So it sounds like it's a fine line between the power you give developers and having some sort of oversight, I guess, over a team to handle the infrastructure piece.

Exactly, exactly. And I think one of the interesting things, and maybe this is something you're going to get to later on, but up to this point we have really relied on pull requests and human beings from different roles to take a look and to say, well, yeah, that, that seems like a safe thing to do. Or, you know, you think, think twice about that. It's not necessarily that we're going to move away from that, but with the advent of generative AI and its capabilities, really interested in the idea of AI pull request reviewers that are able to be given specific instruction sets to look for things that would have been very difficult to have done programmatically before. Like you've got all the security scanning software and it knows how to look for very specific patterns in the code and that's fine and everything, but I always wonder about the case where somebody has, maybe not intentionally, but if you've implemented something which Fits the design and the design fits the requirement, but the requirement was something that should never have been done in the first place.

Yeah, yeah.

Code review is rarely going to catch something like that, right?

That's true, yep.

But if you have this sort of neutral AI arbiter that looks at every pull request and you've given instructions, you know, under no circumstances, for example, should private data be published out on the Internet, that gives you another sort of last chance exception to look at everything that goes through and really understand more of what's going along holistically and, and give sort of an independent third party opinion of is that what's really going on? More big picture stuff. So I'm super excited about that.

All right. Yeah. So let's get into AI. It was on one of my thoughts to ask you about. It seems like you are trying different things. So I guess with ChatGPT, probably AI has been around forever, but it really took off probably November 2022, 23. So how are you applying AI then? Are you still in the early phase of evaluating it and seeing how it's going to help? Or have you actually built it in like you gave this example? Is that something you've already done?

There are a couple aspects of AI that I can and probably would flag up. One is its use for coding assistance, the sort of copilot use case. We have embraced that. It's rather interesting, you know, as you see the same patterns across the industry. I think many of us thought as soon as these copilot tools, I mean, I'll just say for myself, like on weekends I do a lot of personal programming. No surprise there. I love it. You know, to me, I cannot possibly get enough assistance with the stuff I'm doing. If it lets me move faster, that's great. Not everybody has that same immediate embrace of the AI coding tools. Right. It can sometimes be a matter of habit that folks just know how to do something and they want to do it the way that they want to do it. And who is this algorithm to be telling me otherwise? Maybe in some cases it's the shortcomings in the tools that like to me, I don't mind working with an AI and having to ask it five times to get the right answer because I know if I have to ask it five times, but at the end of the day it gives me two pages of code that do what I want. Well, that cost me three minutes of arguing with the computer, but I got two hours worth of code out of it by the end of it. That's A great trade off. Right, but that's like I said, I. We're not unique in that. Everything that I read across the industry sort of reflects the same slower than anticipated adoption in that side of the tools. And the other side of course is, you know, one of the things that we do as an organization is we publish and we, we sell research. Typically our customers in the past have used standard search to find based on keywords, the information that they were interested in. Now we're bringing out this next generation of what we call genies, which allow our customers to ask questions the same way that you see with like, you know, Google that now you can go and you can ask questions or. And so that we have AI adoption both on the patterns and practices in technology side and on our product side. And of course I'm much more involved in the patterns and practices than in the product decisions.

I think AI is very underhyped. Even though people say they're sick of hearing it, it's almost like, I don't know, you probably remember when the Internet first came out, you're like, ah, it's not a real value, businesses not making money. And then all of a sudden, you know, it is what it is now. People undervalued it almost even though it was all hyped, but it became real. I think AI's even taken off quicker than that. So how do you balance then AI with human expertise, say people that maybe over rely on it, or people that just completely, you know, ah, I'm not going to use it at all.

It's an interesting question. So there are two paradoxes I recently became aware of. I'd been telling folks pretty much the same story for the past, I guess, 18 months about AI. And then I happened to read, oh wait, these are paradoxes that pre existed. So these things have names that I've just been saying in English. And the first one is what's known as the Menos paradox. Apparently this was a Plato thing, but he talked about if you're trying to figure out the answer to a question, the paradox is you sort of need to know what an answer looks like in order to find the answer. But if you know what the answer looks like, why didn't you just do it? You already had it. I talk about this a lot with the adoption of AI and perhaps managing expectations and also managing fears because a lot of, you know, technologists, it sort of falls into two camps. There's the folks who underestimate it and aren't worried at all. And then there are the Folks who, I hesitate to say overestimate it, but have what I would regard as unwarranted fear. Because in alignment with this paradox, I know when I do my weekend coding and I'm using ChatGPT left, right and center, it accelerates me tremendously. But if I think just for a second about the guidance that I'm giving the tool and what a non technologist would have to do in order to get the same results out of it, it's not there. And I don't think it will ever quite get there. Because to the extent that somebody is willing to go with something which is if I want a website and I'm happy to go with something which is very opinionated template development and I don't want any customizations from it, you can get that, that's easy, but you can get that without AI today. I think for non technologists, AI is going to accelerate that and make those sorts of things a lot better. But then you get into another set of phenomena which is covered by something called the Jovan paradox, excuse me, the Javon paradox, which is the more you have of capacity, the more demand comes out of that capacity. So the way I sort of see this playing out is AI is going to give folks the ability to create so much more with so much less time than they had before. But that's just the start of all of these new systems where we'll see software everywhere, everywhere, everywhere, say a hundred times more software than we have today. But then it needs customization, it needs maintenance, it gets into the things that are like the integrations that weren't considered and can't be known by an AI in advance, which is going to drive the need for, I think, more software engineers. So I tend to be an optimist in general. But the whole thing about adoption and what lies in the future for AI tools, I can see it creating a lot more software than we've ever had before. But along with that, I think will be increased demand for folks who can take that next level. And you mentioned the Internet. Something else I always tell folks, which really dates me is my senior project when I graduated from university was creating a website. And I'm not talking fancy interactive website here, I'm talking static HTML pages. I think maybe we had the scrolling banner at the top or the dancing baby, but you know, that's now we accept that, well, gosh, you should be able to do that in half a day at most, right? It's going to be the same thing with build a mobile application with these 10 functions. It's today that seems impossible to us that that could be a half day task. It'll get to be to that point, but as a result, our businesses are just going to ask 10 times more of us. Right. So maybe 20 times. So maybe that's more than you were asking. I apologize.

No, I love it. A lot of great points there. I love the paradox that you brought up. I guess one thing is I was pretty optimistic as well, thinking it wouldn't impact jobs. But then like last week I saw Zuckerberg saying he's actually going to replace mid level engineers with AI. I don't know if it's all gusto, if it's real or not, but any thoughts on that? Because it's almost, to me, it's almost like a paradox where as well as in order to get the most from AI, you need to be a good coder or a good Tester, a good DevOps person, because it's spitting things out. But how do you know what it's spitting out is what you really need? It's almost like it works best if, you know, coding and things like that to get the most out of it. But I don't know being completely replaced, if that's even possible. But I was wrong because there it is, that news story.

Yeah, I do. Well, that gets back to the Minnows paradox, right? That in order to know what, in order to find a solution, you need to know what good looks like, right?

Yeah, yeah.

I can't comment on a specific, you know, statements by any specific company. I think in general, just as a technologist, it seems to me like pundits get a lot of value out of making sensationalistic statements. What I get, what's. Where do you use Bravado? It's, you know, it's the. So you have to take all of that sort of stuff with a certain grain of salt because the person who comes out and says, hey, I'd like to talk about how AI is going to make some slight changes in some of the stuff we do, some of the time isn't going to get nearly as much media coverage as the person who says, your job's going to be gone in two years. Yes, that's. What's the media saying. If it bleeds, it leads. Right, right.

Yes, for sure.

Yeah. So, so, so there's, there's a lot of that sort of stuff going on. Which isn't to underplay, you know, the potentially civilization changing capabilities of AI. Particularly, you know, once quantum computing gets to a point that it's, you know, you put those two together and theoretically find the answer to anything in a trivial amount of time. So. But I think, you know, from my standpoint, I fall back on that Javan paradox where the more capacity you give folks. It was apparently originally fuel efficient cars that drove that caused folks to realize that because people were sick of paying so much for gasoline and so they were driving less and then they came out with fuel efficient cars thinking, oh, this will really help folks with their gas prices. But people just said, oh well, if I had $100 or whatever to spend now I can use that hundred dollars and go twice as far because my car gets twice as much mileage. Same thing. I think with AI, it's just going to drive a lot of demand.

That's interesting. I totally agree. I'm from the testing side and I think the more code you have, the more it's going to need to be tested. Whether it's AI assisted or not, that's fine, but I don't think replacement is optimal. But like you said with the quantum chips, I think Nvidia came out with the quantum chip. If it does replace coders and testers, then I assume it could have replaced anything. Then we're all going to be in the same boat reading Plato like you said and probably just staring out at belly buttons and contemplating things, I guess.

You know, I think the other thing is I, I just, I find ChatGPT just such a super interesting or even Claude. I mean, you know, any of any of the different. You can do just so much interesting stuff with them. Now there is that bump in quality of life that like the Internet, it's easy to sort of forget how much better things are when they start changing and forget what things used to be. Like, my daughter was talking about going to the library a few weeks ago.

Oh wait, yeah, that's something we used to have to do to get access to any information. I don't know about you, but I couldn't live without generative AI assistance at this point in time. I mean, that is my go to for every answer.

I use it for everything. Yeah, I use it for every aspect of my business. It's crazy. I mean, I don't necessarily trust it all the way, but it's like it's a complete assistant. Helps work alone, so it helps bounce ideas off of and go, that's a good idea. That's a bad idea. But I use it every day. I think it's awesome.

Yep, me too.

So I guess let's. I kind of Got off on a different path here. Let's go back to DevOps really quick. We started in the pre show you were talking about DORA metrics. I know a lot of people always looking for metrics and ways to know or indicators how the DevOps efforts are going. So can you talk a little bit about dora? Maybe we can wrap it all up and maybe how that can assist people listening with the DevOps efforts.

Yeah, if you are going to embrace the path of continuous delivery. And I sort of see things like agile and microservices architecture and the DORA metrics and cloud adoption, those pieces are all intended to sort of fit together because unless you have, I won't necessarily say microservices architecture, unless you have a decently decoupled architecture, it's going to be difficult for you to have teams that operate independently. And unless you have teams that operate independently, you're going to find it very difficult to get that sort of constant releasing into production because everything remains this. We all have to hold hands and jump at the same time to get anything to production because everything's intermingled. Right. So the DORA metrics have presented, not just us, but to many organizations in the industry, a great way to sort of empiricize our progress in the areas where we want to move forward with continuous delivery, I would say. And predictably, what we see when we look at those metrics is the applications we have, which are newer and more decoupled, find a lot easier to adopt that working style where they're pushing things out constantly. And when you look at something like lead time to release, you see that stuff going left, right and center, the stuff that's, you know, older technology. With the more older technology and the older way of doing things, a lot harder for it to do those constant releases. Because every piece of technology that gets rolled out within those applications is linked to everything else. And it's harder to say when you do this, is it going to affect 10 different things? One thing that I did find surprising as we were rolling out the DORA metrics, which was a real sort of discovery for us when we got serious about tracking major incidences, which is, you know, two of the four door metrics are really about your incidences. You know, how often do things go down and how long does it take you to recover when they do go down? If you had asked me prior to our adopting those and studying, I would have thought that when things break, it was typically a result of code that we were pushing. Like, you know, hey, everyone, be more careful with the Code that you're pushing, we've had a bunch of outages recently or something like that. In actuality, like what you find and what a lot of organizations find when they do stuff like this is your tech debt can be a liability just sitting there because other things change in your environment, you know, operating systems upgrade or whatnot. And a lot of the outages that you find, a lot of the expensive outages that you find are as a result of that tech debt more often than code pushes. Because when you're pushing code and knowing that you're from a testing background, that's the stuff that's gone, you know, that's where your eyes have been, you, you've done the testing on it, that's where your focus is, that's where you're being careful. So you actually stand a pretty good chance of success with that stuff going out the door. What Dora sort of showed us was actually, you know, what we need to be looking more at the stuff that hasn't changed in X amount of time. Because unless you keep up to date with some of the stuff, it can become a liability to your uptime.

Oh, that's a good point. Also, I would assume your software relies on a lot of third party services, are consuming others data. Maybe I'm wrong. So it's almost outside your control when you're coding, making assumptions here. And if that's the case, how do you test or anticipate issues with non deterministic kind of, you know, dependencies that a lot of modern software relies on nowadays?

Yeah, it's an excellent point and I would say you would be right were it not for the fact that we are sort of data experts and that is an aspect of our business which has been the same for many, many, many years. So that's the sort of thing where like data cleaning and data structuring and all that sort of stuff that's, you know, we got that down and we've had that for a while. I think when we think about the testing of it, the one area of acumen that I would really sort of like to try to get to is this idea of point in time testing and more unit testing. Because no matter how hard we try to try to get every possible test case in, our data is not always feasible. So trying to push more back to the development side and say you can do a lot more on the unit testing side with your code to feed in and you know, mock up different scenarios than we're ever likely to get in the database, I think is, is Sort of, you know, that's almost more important than trying to get the different model, every different permutation of data. Something that's interesting. So I've worked in both. So in finance, you know, there's fixed income and there's equities. In equities there are test symbols that are recognized out in the marketplace where you can send a test trade like I want to buy a thousand shares for $50 of I think it's symbol like XZ VBT or something like that.

Okay, cool.

Yep. That doesn't exist.

Right, right.

And the markets have agreed that that will just be a test symbol.

Oh cool.

And they'll give you back fills. So for something like synthetics running in production, that's great because you can, you know, and I think most of the major equities tradings organizations will have something that like every minute goes through and you know, buy 500 shares of this test symbol, sell 500 shares of it and just keep doing it for whatever reason. It doesn't seem like that has been, that has caught on as much in the fixed income space. And that's a real irritant than something, you know, would like to see sort of more of an organizational wide change to get that same acumen in the cause. Testing in qa, testing in uat, all that sort of stuff is great. But ultimately what you want to be able to do is in production have that constant monitoring and assurance that hey, everything is still running. Particularly when you're worried about breakages caused by tech debt as opposed to changes. Because if you know that something might break just by sitting there, you want to have something that's constantly going through and doing that, that test loop very difficult to or it's much harder to arrange, I would say in fixed income than it is in global equity. So make that what you will.

Yeah, no, great, great point. I've been seeing a lot of applications of AI in production as well to listen to what users are really doing with the application. So when you are shift left and you're telling developers to do unit tests, they're not just testing things to test things or testing things that maybe that you know your users are really doing. And if you don't have cases around it, then you probably want to handle it for sure.

Usage analytics is huge and we talk a lot lately about like, like DORA plus, which is this concept of when you got the DORA metrics, you're measuring what we in software engineering would consider to be goodness. But DORA plus is sort of extending that to the business and saying, are we really building the stuff that our customers want? And that sort of usage analytics stuff that you talk about is super useful there to say, you know, We've added these three buttons and this button gets clipped 10,000 times a month. The second button hasn't been clipped by anyone. Why did you have us build it for? Sure, stuff like that. Super useful.

Absolutely. Okay, Derek, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps pipeline CICD efforts? And what's the best way to find or contact you?

I would say it will seem perhaps not as relevant specifically to DevOps, but to our topic earlier about AI. This is what I'm telling everyone right now. Dig in and understand more of the under the covers. With AI, it's the same as every technology that has ever come along. The more you understand how to build the tools that you're using as opposed to just be the end user of them, the better you're positioning yourself in the labor market and competitively to sort of understand. Someone said your job won't be taken by AI. It will be taken by somebody who knows how to use AI better than you do.

I think that that's the advice of 2025 in general is just understand the internals and that will allow you to be a better user and apply it more places. And as far as my contact information goes, you're welcome to connect to me on LinkedIn, send me a message or whatever. I would be remiss if I didn't mention my employer. We just found out today Fitch has been listed for the third year in a row by Built in as the best place to work in technology in Chicago and New York. So we're always on the lookout for great talent. And definitely, definitely ping me if you're looking.

Great point. We'll definitely have a link to that because I know a lot of people are looking for new opportunities. So definitely sounds like a great company, great technology and a great organization and people to work with. So thank you, Derek, for that.

Thank you. Great being here.

All right, before we wrap it up, remember, frustrated users quit apps. Don't rely on bad app store reviews. Use SmartBear's Insight Hub to catch, fix and and prevent performance bottlenecks and crashes from affecting your users. Go to smartbear.com or use the link down below and try for free for 14 days. No credit card required. And for links of everything of value we covered in this DevOps Toolchain show, head on over to test guild.com forward/p181 so 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. AwesomeMess. As always. Test everything and keep the good. Cheers. Hey thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation, software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit test guild.info to explore how we can create transformative experiences. Together. Let's push the boundaries of what we can achieve.

With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.