PurePerformance - 030 DevOps From the Frontlines – Lessons Learned

Episode Date: March 13, 2017

Brett Hofer (@brett_solarch) has been engaged in numerous DevOps Transformation projects mainly for very large enterprises. We got to talk with him on this episode to learn more about how he assesses the status quo when he walks into an organization, what the top blocking items for a successful transformation are and what the best approaches are to implement the recommended changes. Spoiler alert: we talked a lot about IT Ops Automation, building cross functional teams and understanding and defining responsibilities and roles. If you want to learn more about what Brett is doing check out his blogs about DevOps on https://www.dynatrace.com/blog/author/brett-hofer/.

It's time for Pure Performance. Get your stopwatches ready. It's time to Pure Performance. I'm Brian Wilson and with me is Andy. And yes, I am back. So hello Andy, nice to be back. Hi, yeah, good. We missed you in the last recording.

I'm sure my voice disappoints a lot of listeners who are thinking, oh, they finally got rid of him. But no, I'm back, everybody. Oh, not that bad. Okay, only a little bad. So I think today, Andy, we have hopefully one in a series. We'll see how it goes, if we can get more in. But how did you want to call today's episode?

Or what did you not have? Well, how did I call it? Or how would I call it? Yeah, I want to call it DevOps from the Frontlines. and it's actually not a title that i came up with but it's actually a title that uh brett hofer who is actually on the call with us today came up with and he's he's writing a blog series about it and i just want to actually give it the word to him and allow him to introduce himself hey brett are you with you with us? I am with you guys. Thank you for having me. Hello. Yeah. So Brett, DevOps from the front lines. I know it's something that you're writing

about right now. And maybe can you tell us a little bit more about yourself? Why are you writing about this? What your role is right now? And then we can get started with some discussion around it. Sure. So as you know, Andy, I had written a series called Art of DevOps a while back, which is a four-part series, kind of like what the battlegrounds look like for developing in a DevOps pipeline and everything else. And so kind of a playoff of that or a continuation, I decided, you know, why not start a series where I take my everyday experiences with our teams that are out here implementing DevOps in organizations for Dynatrace. So I'm the global DevOps practice lead for Dynatrace.

And the role is that we offer a service engagement where we help companies do DevOps transformations on a specific application and integrate Dynatrace into those applications. So I decided to start this series called DevOps from the Front Lines, meaning I get the great opportunity in my position to experience what it's like walking into a field of people who are trying to perform a transformation on a current application. And I get to see a wide variety of maturity and common problems, pitfalls, things that people are missing or should be doing. So I like to write about it and share my experiences. And that's really what this is about.

And I'm not sure if you're allowed to name some companies, but I know you've been working with major credit institutions, healthcare, e-commerce. And what I will be most interested in in the beginning is why do these people come to you and ask you and your team to help them? And I know you mentioned it's typically application teams. They want some help on getting application teams for a particular application or set of applications up to a more continuous integration, continuous delivery style, integrating monitoring like with Dynatrace into the process. But is there typically a pain point? Why do they need to reach out to us and why don't they do it on their own? Well, I think what we see is a very strong ambition for continuous delivery, increasing the speed of their deliverables. And they all hear about DevOps. They know that's the buzzword inside the organizations. That's the kind of the command coming down from the top saying, you know, things should be coming in and we should be embracing this DevOps concept. So because we have our technology out there, believe it or not,

we see a lot of information coming and requests coming from ops who ends up beginning the drive of this. And they're claiming, you know, we need better quality being brought over the wall because we're seeing these problems and they're not resolving them and so on. So the reason they come to us is the opportunity that our account managers are in there. They hear the word DevOps. They kind of sync up and say, oh, do you guys offer anything as far as DevOps and how does Dynatrace fit into DevOps? And that often launches a new conversation with their app managers or, you know, folks that are leading up that app, that particular application. showing us where we may have gaps in our understanding and gaps within our processes to actually deliver the software from, you know, all the way from the left to the right and create a continuous loop. If you have that kind of expertise, they are welcoming this type of expertise.

So, of course, at that point, we offer the opportunity of the service program and service engagement that my team is part of. So that's how we get introduced, and we help do an assessment on a single application. And we start finding a lot of very common problems and things across different companies. I think what you probably, when we talked a little before, is you experience that you'll go into some place that is trying to initiate this practice. And I guess just for the lack of widespread adoption, they're kind of running off the cuff, right? And winging it with a lot of whatever knowledge they can glean, but they're trying to do it from the ground up. And it seems like that can create a lot of problems in this process. Yeah, it creates a tremendous amount of challenges because if you go into an ops team and they really want this, then they have to get the invites and include other people from development. And if it's not kind of a top-down approach, they bring people to the table, but not everybody's on the same mindset or the same priorities.

Development's sitting there thinking, hey, you know, I have to get this stuff done. I have to get what's in my backlog finished. And that's what's driving them, whereas ops is like we need better quality coming out of there. And, you know, of course, all the technologies that are included, like your cloud technologies and things like that, that normally you would see in this continuous delivery pipe, you know, these pieces might be missing or the infrastructure is working on it, but these groups aren't aware of it. So there's no, nobody talking to each other to create what truly is a DevOps culture. They all want to get there, but there's just a lot of siloing.

And one person's on this initiative and the other one, DevOps is not nearly as much of a priority. But it's very important to make sure that in order to make this truly work, everybody's got to be working at the same common goal for that application. So when you – I think you mentioned you start with the assessment and you said you find common problems. I mean I know you mentioned some of them already. But can you fill us in now a little independent of Dynatrace and what we offer but more in generic what are the biggest obstacles the most common ones and and how do you then actually you know what are the recommendations that you give them or what is the approach to actually start because i assume if you find certain deficiencies and certain problems you cannot just say we'll fix this for

the whole company right away that's probably like a an approach where you start with one team or with one application so to rephrase what i wanted to know what are the problems that define your assessment the most common ones is understanding what a DevOps pipeline is supposed to look like in general. Like the true understanding that one of the core pieces to that pipeline is based on infrastructural technology, like that it's cloud-based. It's more like, you know, dynamic provisioning and configuration management, which is one of the key essential pieces to a continuous delivery pipeline. So one of the absolute most core pieces is you walk into probably one of the top, and I do this

often, their top public facing website. And it's still based on traditional, either bare metal or virtual VMs. And it's all of the infrastructure is owned by an infrastructure group and the legacy mentality of that's the way it is. It's always been that way. We can't change it. So if I'm talking to ops or I'm talking to dev and we say, you know, how do you deliver this stuff in a continuous automated fashion out? And again, this is common when I say common problems or it's only a problem or a gap between what they're doing now and trying to get to this true continuous delivery DevOps type culture for that application. So applying DevOps principles, it's the core infrastructure issue and that infrastructure is so siloed and segmented from dev and test and ops. That is a number one, unrelated to Dynatrace in general, of getting them to transform. And it's usually the first thing that they're trying to do,

but they're not telling everybody what time is this going to happen, when are these services going to be available to the dev groups, and so on. So I would say that's the first one. Yeah, and now let me ask another question to you because you just said, obviously, they say we've done it always this way and it's not possible to change now who is actually the one entity within an organization that typically says well we have to change because even though we did it that way that many years and our website runs on some physical hardware we have standing somewhere. We still need to change now because we have

a pain somewhere. So this is kind of like going back one step. Who is the one that is typically approaching us and say, we have such big pain, we need to change and we need help from the outside so that we can get everybody on the same table so all of us understand how we can move to a different deployment model. Is that business? Is that a new initiative on the application side? Who is it? So here's how it works. In an enterprise organization, if we're coming in at an app level, that is nowhere near the level to get those type of services because understanding enterprises are very departmental. It's probably one of the biggest challenges why infrastructure is because it's like the mentality has always been this is our stuff they own this stuff and in a devops world it's

the developer should have it so you need to move further up the chain where you're crossing the departments between dev and infrastructure. So to get up to that level usually takes you up to a vice president level. And it usually gets up to the VP levels because it's the VPs who cross those or talk to other VPs to coordinate the efforts because you've got security involved. You've got all kinds of decision making and what i've been seeing them do is larger organizations creating these entire coe devops groups like at a higher level who are tasked at this initiative but they're but they the true decisions become at the cto level and as a VP level in a large organization. And it's those

guys that have to come back down and say, okay, but follow what the requirements of the transformation are supposed to be for this particular app. So they will still choose a significant app to start this pipeline governance on, but you really are, to truly get a top-down, it's at least the VP level. And so, okay, cool. Thanks for that. So that means going back to the biggest pain point that you see, it's the inflexibility

of provisioning the resources and the inflexibility, but also the manual efforts, processes in place. So infrastructure as code is obviously what you're talking about and being able to, in a very flexible way, get what you want, what you need for development, for testing, and for production, and then either on, I assume, either a cloud environment or a public or private cloud environment basically.

And do you then help people making the right decisions as well, like in which direction they need to go? I mean there's a lot of options out there. Do you then coach? No, we don't. point out the fact that this is a missing principle and make lighter considerations. But because there's so many factors involved in whether you're talking with an insurance company or a financial company, they may only suggest private cloud instances for security reasons. So we don't go as far as that, but we will, as far as the logical and the mechanics of what they're missing, we'll discuss that in the assessment, but won't

go as far as to picking technologies and things like that. Okay. And obviously, I mean, you have to experience and you know what kind of capabilities from a monitoring perspective are necessary for monitoring a cloud environment versus, you know, an on-premise versus a public cloud, a container technology versus an instance technology, a pass or whatever, you know, I mean, obviously, you know, the requirements and obviously, you know, our capabilities as well. That's great. Yeah. And the reason we include this, Andy, and you have to include it is because if we are to promote and advocate the fact that we can produce faster, you know, this whole method can not only produce faster deployments and numerous deployments per day or whatever.

You have to embrace the full impact. And as a performance perspective, there are significant, you know, things that you gain by dynamically provisioning something, testing it, and then looking at the metrics versus keeping a managed VM out there, testing on that, it may get dirty and then you deploy it again and again, and that can alter your performance metrics every time you run on a system that that's not refreshing. So there are, there are several advantages to that cloud thing to get even more value out of metric, um, you know, measurements, build over build measurements. So it has to be part of the comprehensive view of how do I, how do we get customers to do not only integrate the performance monitoring, but make sure that you let them know here could be the optimal way to do build over build metrics without maybe tainting some of the results. A lot of it all relies on some of the advantages you get from a cloud-based environment.

In terms of some of the other issues, I know one of the ones you speak of in the blog as well is this real strong sense of groups being siloed, which also leads to this whole non-cross-functional teams. What have you seen? How have you seen any of the customers overcome that issue? And how do they overcome that? Because we've heard, you know, in the past from Finn Lorbeer of ThoughtWorks and some of our own team members, Anita and Bernd, about building these cross-functional teams. I was curious to what you see on some of these engagements and how they go about addressing getting over that idea. Because as you mentioned, the developers, if operations is taking up the charge,

the development team might be sitting back thinking, well, we just need to get this stuff out and we don't want to start sharing our information. You know, I guess what I'm really getting at is, you know, what are some of those steps that you see is critical to fostering that relationship and making it work? So this is the second thing I was going to talk about. And that is, this is probably one of the biggest hangups. And the funny thing is, is that in enterprises, this is already going on as far as cross-functional teams. It's a very common practice, except the mentality of a team member offering services for a particular application, there's a wall there. To take the wall down. What happens is in larger organizations, your development teams have a development lead. And then that's exactly right. What you said, Brian, is they're worried about get their backlog issue and then QA gets it and they have a QA lead and people are doing their QA specific things that they're tasked to do as a department.

And then they either let it pass through or they send it back versus. to make this work and where it does work is when you have a top-down you know view of things at an application centric pipeline so now your roles are so where you have one lead who has empowerment across the different functional areas so they have the say in what can be done and not be done on let's say the infrastructural piece. They can say they govern across like a product manager is a common practice where they can say, this is what I need from testing. And you guys work together. You don't you don't have this mental walls you're passing. It becomes more of a OK, it's a team around the application versus a team around the departments. And when they can actually do that, then when you do things like training and you start rolling things out about here are the tool sets, here are the processes.

If we introduce Dynatrace in to monitor unit testing or to monitor functional testing and load testing, you are going to get these screens instead of just the testing department seeing that if it's application centric, it's the whole app team is then exposed to it because things are being socialized at an application centric level versus a departmental centric. And that's how they do those transformations. But it has to come from the top because you, again, have to span departments to make that happen. And I think it's also exactly what we, I think, Brian, you mentioned, it's what we also heard from Finn and from others out there that say DevOps transformation meant we transformed our organization structurally to reflect the applications and the features we're building, meaning you have teams that are responsible for an application end-to-end. Within these application teams, you may have feature teams that are responsible for individual features end-to-end. And that means coming up with the idea, implementing it, testing it, running it for the pipeline,

running it in production, and understanding if they build the right thing or not the right thing, or if they build something that is not efficient enough, but basically making these cross-functional teams, these application teams, feature teams, responsible end-to-end. And that obviously requires them to have support from something like a pipeline that automates a lot of this stuff, including, you know, like starts with compiling code, well, actually starts with, you know, change management, right?

Starts with the Git repository, starts with test automation, continues into some type of load testing environment that they have available through an API, starts with provisioning either a staging environment or a production environment through an API. And I believe, Brad, this is what you said when we go back to what you mentioned all in the beginning, is that it seems one of the toughest challenges right now is the inflexibility of the infrastructure. And we need to have the infrastructure be available as an API because only then can we enable everyone out there

to build applications faster, to test them more efficiently and react to changes in production with, you know, hopefully with an automated script even and not having to go through change management processes that take days or weeks. Yes, and just to point out, it's also the

unification of the processes. That's, that's probably even the bigger thing because, and I'll give you a perfect use case scenario of this, which is all across the board, probably eight out of 10. If I go in and I say, Hey, what's your backlog on, you know, your tier one public facing app, and, and you went to development, they'll give you their Jira agile. They may show you what their backlog is. And then you say, well, where are all the testing tasks? Um, well, the testing folks, they, they track their own thing in some project file. So they, you know, there's no unit in a lot of these cases, not all, but in a lot of these cases, there's no unification test.

And then you say, OK, well, in order for me to roll that out, you're going to need a new environment. Well, why isn't the environment on the on the in the backlog as well? I mean, all these these processes that pull an application pipeline together need to be unified, not only at the project level or the agile management level, but it needs to be done at the source code level. You know, you've got change management people having their own source control, but all that source should all be on the line with the apps. It should all be app-centric. And I think that's the biggest transformation that needs to happen and needs to come from the top or from some kind of an enterprise dev ops coe and when then when we go in to apply a lot of the stuff that you go over

in a lot of your things and we implement to on our in our in the practice um they're they're even more effective because it's being not just applied by one single person in one single group, but it's being socialized across the pipeline and the entire app team, which is often missing when they do this. You know, what's interesting, we had in the previous recording, we talked with Tom McGonigal. He used to work for CloudBees, you know, Jenkins Enterprise, and is now working for F5. And what he's been advocating through meetups and other events is actually showing the infrastructure teams how to use things like Jenkins to automate infrastructure provisioning, how to use infrastructure as code, whether it's Ansible, Puppet, or Chef, to provision infrastructure provisioning, how to use infrastructure as code,

whether it's Ansible, Puppet, or Chef, to provision infrastructure, configure load balancers, configure proxies, all automated, but teaching it by using the same tools, like at Jenkins. So yesterday, I was then invited to do another podcast with him, where he was actually showing a Jenkins pipeline that was rolling out a new application version. But part of that rollout was also a change a while now, also for infrastructure provisioning. And that's just perfect, right? Yeah, that's exactly what I'm talking about. And that's exactly what I was saying as far as unifying and getting dynamic provisioning because that's a huge piece of this. And you mentioned Jenkins, but I will say

I have numerous accounts that actually have Visual Studio and the whole ALM by Microsoft. And it's amazing to me to see that in many of their cases, they have all the tools out there and implemented and they can you know, they can connect to the Azure's and everything else, but they don't actually use any of it. They use a very small portion of it. And the only reason they use a very small portion of it is because only a certain number of people have access to it. And there's been no overarching vision to implement what they have. And it's a shame because, you know, there's a lot there, just like with the Jenkins and that whole process, you know, it's all been

well thought out and defined. It's a matter of education and, you know, an initiative with a vision that comes down and says, this is what's got to happen, you know, and taking it and making a priority because it will definitely change a lot of the, and help the quality and the speed of deployments and everything else that the business is really needing. And correct me if I'm wrong, Andy, because you know, I had to miss yesterday's recording, but in our lead up to that conversation with Tom, he was kind of coining, I don't know if he was coining the phrase, but he was using the phrase network as code, differentiating a little bit from infrastructure, because I think a lot of people, whether or not they're doing infrastructure as code, as Brett was just mentioning, the idea of taking that to the networking components, I think is a little bit

newer, or maybe might have been something that people just never, never thought of yet. So I just wanted to bring that up. Yeah, no, we talked about this. We talked about the aspect of using application metrics. Like we know which features are used at which particular point in time during the day by which users around the globe and how much data needs to be transferred, right? If we know feature A, the homepage, on average takes 100 kilobytes and they're used by that many people at 8 o'clock in the morning,

then we can anticipate that next Monday as well. And so we can automatically provision the right network. We can provision the right rules for the load balancers to make sure we have the capacity. Or what we actually thought would be even cooler, when we talk about A-B testing, when we talk about blue-green deployments, if I'm a developer and I have my pipeline and I roll out my new feature,

but I want to only enable it for 5% of my people because I'm doing a blue-green deployment, then I can, in my pipeline, use, and I call it now, network as code. I can make these changes to my load balances and say, please route 5% of the traffic to these two servers here because they run the newer version. And then, you know, depending on what the monitoring data tells me, people like that

version or not. If they like it, maybe I automatically run a pipeline script that bumps up the number of users, which means provisioning more application servers, because I'm expecting more load, and changing the infrastructure configuration, in this case, the network switches or the proxies or the routers to push more users in on these servers. So yeah, we talked about this concept, and it was fascinating, because there's a lot of things we can do and um and all of these the vendors i mean he was from a5 uh they all at least they're five now i know i'm sure others do it too but uh they provide rest apis they provide scripts

for ansible chef puppet and you know true powershell and all the other stuff as well so you can automate the configuration of these network-centric components. And that's pretty cool. Yeah. So go back and listen to that episode if you haven't. Brad, I did want to talk to you about the idea of information being stuck in silos. I know that's another kind of point you like to bring up. And I wanted to expand on it a little bit. You know, I think there's definitely part of the concept of, you know, each team's looking

at a set of data, but they're not looking at each other's data. But also taking that beyond looking at each other's data is coming to breaking down those walls and coming to a common set of data, right? Obviously, each team might have specifics in that environment that might not imply to a different environment. But overall, there's definitely certain metrics that should be being tracked all the way through. And this kind of crosses back to the cross-functional team where, you know, developers, and I don't know if you're seeing this so much in your engagements, but our developers starting to become testers.

Our tester is starting to understand some of the development and everybody looking at operations. Is everyone starting to take a stake in all the tiers or in the engagements you're kind of coming across? Is it still like, hey, we'll all work together as a team, but I'm just going to write my code and the testers are going to test it. Yeah, that's, that's pretty much the common theme running theme in many of these. Um, you know, and these are some of the largest tier one systems, you know, I mean, and people make advancements within their own areas and evolve and improve. But this is, this is absolutely one of the biggest things I've promoted for almost 10 years and have been involved in in numerous um you know efforts and and always promote uh is the fact of sharing information but in a very consistent way so one of the big things that we you know that that often gets promoted is um you create if you if I have a devops governance DevOps governance or any kind of informational governance about my applications, one of the consistent things we can offer you for each application,

business analytics, operational analytics, testing analytics, or health and development. Okay. Now, if I were to go to each one of those groups and said, give us your best dashboards, give us your best piece of information that you have, that you could offer to the rest of the people that would look at this one central site and you were to present that in a very easy fashion to get to that information, you can form, which is often I've seen this done in SharePoint where you just have, all right, here's the list of applications. I click on it. And when I go in there, I can choose from an array of business ops, testing, dev. And if i go into test let's say business

analytics i could see maybe uh you you show the the screenshot of our user experience management and describe it and then that's presentable to everybody and then they send out that one link and there's a consistent thing that you offer for every application. I'm just using this as an example of what I've seen done where it offers this information in a very consistent fashion to the whole organization. And now next thing you know, you have people doing things like here's some Dynatrace screens. Here's our dashboards that we've built for business. Here's some health dashboards we've built for testing. And every one of the apps that have gone through this governance will have this available to them. That's not what we normally

see when we go in because everybody, and the surprising and the unfortunate part is each one of these groups have, like if they have Dynatrace, for example, have a tremendous amount of information, but I don't know how many times I've been in meeting after meeting with director levels and up and even business who go, I don't even know, I don't even have any idea we had this information. And, you know, everybody's kind of going, we never heard of this. And everybody's like, yeah, we've had this for forever. There's no socialization. And there's a lot of value that's just not being

presented to other other areas that's very valuable wow so um the silo the silo the silo issue obviously uh and then i mean i i also see the i also see the problem that uh that people just you said, I think it was – I mean I'm just – sorry that I have to take a second to phrase this correctly. But what you just said is not only true obviously for our – what we are doing for providing monitoring data. But because we live in silos, we never really know what the others are doing, what data is available, and what better decisions we could actually make. And that's true for monitoring products. It's true for many other things that people are using. So breaking down these barriers. And I thought, even though we've been talking about breaking down the barriers for

so many years now, we as a company, but we as an industry as well, it still strikes me that so many people are just still not there at all and not trying to tear down these walls. I remember Gene Kim in November. He said, based on his stats that he has, the companies that he works with, only 2% of companies are embracing DevOps best practice. It's only 2%. So there's still a long way to go, right? And it's Gene Kim. I mean, he sees a lot of people out there. Yeah, and like I said, it really, this comes down to, you know, some of the VP levels really,

you know, making it a priority initiative and believing that this can help some of their tier one apps. And, you know, it doesn't have to be every application that they have to apply it to. It usually is targeted towards the ones that would value the most from high competition, you know, high change rates, things like that. So, and again, even the other thing I would say about DevOps and their, you know, them choosing whether it's initiative or not initiative is they do run into a significant thing with enterprises where there are certain enterprise resources that will always be on quarterly release schedules and things like that. And so no matter how many times you publish as an independent app, you will still be at the mercy of other enterprise resources

that are out there that you may rely on. So, Brett, I know your blog series you're writing, I'm sure there's a lot more stuff in there that that's coming to um to sum it up for today's episode i believe what i heard at least and correct me if i'm wrong a lot of companies are aware that they need to change uh you go in do your assessments one of the critical things that always comes up in the beginning is the inflexibility of the IT team, of the infrastructure team, because having infrastructure as code, having infrastructure available as a REST API that can available, if you're not looking into more, let's say, cloud-based technology. But you also said from the bottom up, it's very hard. It needs to be a top-down management direction that enables either individual teams first and then spread out to more teams and maybe the whole organization,

but it needs to have a management buy-in from the top down to say, we need to change. We need to figure out what it takes to change and we need to make these changes from the infrastructure perspective, from the development best practices. And then also, instead of having these these silo teams building cross-functional

teams or application and feature teams that feel responsible end-to-end for what they are delivering which is applications that make their end users happy and end users hopefully then make the company happy because they pay obviously for the services is this kind of a summary that makes sense that's a that's that's Yeah, that's a very good summary. The only other thing I would add that we did not discuss would what the testing strategies and coverage will be, like unit integration, functional, and load, and making sure that they adhere to the testing criteria. That would be the one big thing I'd add.

That's usually a gap in these organizations. But, yes, it's a great summary. He's very good at summaries. At least one thing I'm good at, right? The Summaryator. The Summaryator. It's a terrible word. Hey, Brett, if people want to find out more about what you do

and also what your team is doing, what's the best way to get in touch with you and your team? Well, you can either write me directly uh at brett.hofer at dynatrace.com or you can actually go out to the uh dynatrace main website and see under services you can uh kind of explore the services that we have to offer and the devops accelerator happens to be one of them. Great. Cool. And I know this is going to air too late, but anyway, next week we are going to be in Vegas and I'm sure we'll come up with a lot of cool stories

because DevOps is a big theme. DevOps digital transformation is a big theme and you are there for the Performance Cafe and more stories for your blog. And then we'll look out for your blogs on blog.dynametries.com, I guess. Yes, perfect. We will see you out there in Vegas.

Great. And as you develop more of these tales from the front line, we'd love to have you back on to discuss some more. We'd be happy to. All right, excellent. Yeah, I've got no final thoughts. I think you all said it all. So I'll just leave it as DevOps is a tough journey,

but it can be gotten through, and the rewards are great. There you go. All right. Thank you, Brett. If anybody has any questions, comments, or feedback, you can tweet them to at pure underscore DT or send us an email at pureperformance at dynatrace.com. We'd love to hear from you.

If you have any of your own tales from the front line to steal Brett's title there, we'd love to have you on and talk about it. So get in touch with us. Thank you, everybody. Thank you. Thanks, guys. Bye. Bye-bye. Get in touch with us. Thank you, everybody. Thank you. Thanks, guys. Bye.

Bye-bye.