What is Platform Engineering? with Evan Niedojadlo

Foreign.

Get ready to discover some of the most actionable performance engineering, testing and site reliability device with some of the world's smartest engineers. Hey, I'm Joe Calantonio, host of the Test Field and SRE podcast and my goal is to help you succeed in creating application performance awesomeness.

Hey, it's Joe and welcome to another episode of the Test Skill, Performance and Site Reliability Podcast. And today we'll be talking with Evan all about platform engineering, yet another extension of DevOps practices. I don't know, we're going to find out. Evan is an awesome expert. He's an engineer that's currently focused on liability, distributed systems and infrastructure with some security sprinkled on top. He also has an automation testing background. He's been on the Guild a few times already. He also co organizes the Austin Automation Professionals and Austin Computer Book Club to provide a welcoming space for folks to learn. If you don't know about it, I'll have that in the show notes because those are great resources for you, especially if you're in Austin. You don't want to miss this episode. Check it out.

This episode is brought to you by the awesome folks at SmartBear. Listen, we know load testing is tough but necessary. So investing in the right tools to automate tests, identify bottlenecks and resolve issues fast saves your organization both and money. And that's why SmartBear created Load Ninja, a SaaS load testing tool to help teams get full visibility into performance so you can release quality software faster than ever, make testing effortless and give it a shot. It's free and easy to try. Head on over to loadninja.com and learn more. Hey Evan, welcome back to the Guild.

Hey Joe. Always good to be back.

Yeah, awesome to have you. One of my go to resources in this area of SRE and automation, but this is something new I haven't heard about before, so I'm excited to dive in. But before we do, Evan, is there anything I missed in your bio that you want the Guild to know more about?

I guess, yeah. Y' all can check out my YouTube channel random thoughts Tech. I haven't been too active on there as of yet because I've been super busy with work and contracts and all of these fun things, but I'm looking forward to getting back to making some videos.

Absolutely. I will have that in the show notes as well. It's a must subscribe to YouTube channel for sure. It's like a day in the life of a that's how re engineer. It's really cool. All Right. Evan, I guess before we dive in even deeper, what is platform engineering? I don't know how many people are familiar with that term.

Platform engineering is one of those things where there's like this murky, kind of agreed upon definition similar to sre. You know, people have different opinions of this. And I mean really, like with platform engineering, it comes down to providing, I mean, kind of the providing a platform for developers. I mean, back in the day, you can think of Heroku, you know, you're essentially building these platforms for developers to kind of like make it easier to deploy. So especially, I mean, this, I would say applies hugely to something like microservices and distributed systems because you have all these different technologies that, you know, folks have to worry about now. So that's, that's kind of like the big problem, but that's kind of like the loose definition.

So is this different than infrastructure as code? I know there used to be like, infrastructure as code was a thing. Is this kind of morphed into something, its own platform engineering now? Is that completely different?

Yeah, infrastructure as code, if it's into platform engineering, without a doubt. I mean, like, as a platform engineer, you're using all of these different tools to build really a platform and you're essentially think of yourself as kind of like an operations person. That's kind of all what this kind of boils down to, whether regardless of your SRE, your platform engineer, you're given the title of DevOps, which as we kind of know, is not really necessarily a title. But what ends up happening here is you're acting as an operations person that can write code that develops a platform for developers to essentially just deploy that service without even thinking about all of those different technologies. As you mentioned, with like infrastructures, code, you know, containers, and kind of everything else.

So, you know, you are a site reliability expert. Now, is this different than site reliability engineering? Is this part of it? Do you need to have a platform in place to actually be successful as an sre?

Yeah, it's kind of interesting, right? So, like, I mean, my role during the day, like with sre, is kind of focused on, you know, observability. You know, I'm like heavily focused on metrics and uptime and all of these kinds of things. I mean, kind of like what I see SRE as and a lot of other folks do as well, is just like you're maintaining, you're keeping the lights on essentially. Right? So that's kind of how I see it. And with platform engineering, I mean, you know, the thing About SRE as well is like, I think I'd mentioned this before on another call with you, but with SRE it just depends, right? So like, you know, the problem with it in all these different titles is, you know, like you have these large organizations, these enterprise type companies like Google and everyone else, and they create these amazing enterprise platforms and then what ends up happening is a lot of these titles, you know, it's like recruiter driven development. Like, you know, you have these recruiters kind of take these titles and you know, spread it upon all these different companies, regardless of the size of the company. Some companies don't need these things as well, so that's another reality of it. But what ends up happening is sre, you keep the lights on. But sometimes at smaller companies, SRE means you're doing kind of all of the things operations wise, you know, you're, you're building the case clusters, you're maintaining your legacy instances on EC2, you're maintaining a Jenkins instance over here that nobody has really been aware of for a few years, but it's still being used for some glue work. So that's the problem. But I see SRE as like keeping the lights on. I see platform engineering as providing that simple approach to doing a deployment where the developer doesn't have to think about all of those things.

No, I don't mean to keep bringing up terms because I think it's important though, so people don't get confused. They know DevOps. So is DevOps like a, a practice? And within DevOps you have SRE and you have platform engineering. Is it outside of DevOps? Is it the same thing?

Yeah, DevOps is like the principles, right? So like, you know, you could, I mean from a historical perspective you could think of, I mean, there's so much depth to it. Right. But like how I think of it as, I think of like, you know, you could probably go all the way back to the, like the Toyota process with Deming, you know, and then from Deming you can kind of look at, I mean there's all sorts of different things in between that, but I refer to it as like the Goal. And then there's a book called the Goal. And then I remember reading that and then like the visual version of that book and like really understanding process and I mean that's primarily focused on like manufacturing. But then the Phoenix Project kind of picked that up. It's another book, so the Phoenix Project. And then it kind of builds upon that as from like a software perspective and it reads like a novel which is super interesting. And then there's like the Unicorn project. So there's like these books and these steps and these like historical philosophies that kind of all tie into, you know, DevOps as a set of practices. You know, there's not really. That's why, like, there's this joke online where like people are like, oh, you know, your DevOps engineer is the title. You know, there's all the silliness associated with that. And then but like, you know, the DevOps practices ties into like what we've been trying to do ultimately is just try to get software out within a realistic timeframe. But at the same time we want to ensure the quality of it, ensure the reliability of it as well. So that's ultimately kind of like what DevOps is leading up to. And all of the, there's so such deep history about all of that that just, you know, there's a talk a couple years ago in Austin that I went to, which really introduced me to all of that. And then I just started kind of picking the books from that that I wanted to read and whatnot.

Nice. I've struggled to stop reading the goal for some reason because I thought it was just had to do in manufacturing, but you're like the third person to mention it, so it sounds like it applies. Those principles can apply to pretty much anything, so that's good to know.

Yeah, I mean, if anyone wants to check it out. I mean, I got the audiobook, like when I'm brushing my teeth and whatnot. Like, I'll just listen to that in the background. And then if you're like a visual person, they have like a visual like comic of it, which is pretty wild. It's worth checking out.

Oh, that's cool. Yeah, well, that's another good tip. I'm going to get my hands on that for sure. So can someone be a platform engineer then? Cause you said sometimes people get confused with titles. Is there, if someone's looking for a job, is there a role as platform engineer or is platform engineering once again like a high order thing that people contribute to?

Yeah, I mean, it's kind of silly. Like if you like I, I was just looking like last week on LinkedIn, you know, you type in jobs and you type in like, you know, wherever your location's at and like I think jobs like 50, I think it was like 50,000 for platform engineering or something like that. I think there's like 120,000 for like SRE specific to the US and it's interesting because, like, yeah, it's just I honestly, I think like platform engineering is just, I think it's a marketing title in all honesty. I think like I don't like Google was, you know, they're all the geniuses that were creating like the SRE process and everything else, right? And like then they kind of worked internally and then some folks from there went elsewhere and turned into a much, much larger thing, you know, in a whole role and everything else, which is really cool. But I think with platform engineering, I think it's, I really do. I think it's like this marketing title where you know a company, I'm not going to mention any company names but I'm sure if you Google like DevOps is dead and all these kinds of things, you might see these, you know, these marketed companies and whatnot. But yeah, I mean really look to see who's selling it. You know, that's as kind of like I don't have anything to sell. So like I'm just going to be kind of really transparent about these things, you know, to the best of my knowledge. But like I just see it as the needed, you know, a requirement for like larger organizations because oftentimes, you know, like really if you're to like a medium to small sized company, I mean the dream is for you to like kind of do it all, you know, you're just like, they want the perfect engineer. You're like, you're doing all of the things. You're like, you're writing the code, you're deploying it, you're like, you're maintaining it yourself, you're giving yourself the pager. So if like there's an outage or something, you know, like that's kind of like the dream, you know. And that's what I kind of did originally in my career when I kicked off my career in like software in like 2009ish, you know, so that was like what we were doing with Nagios and all these other tools. But now it's interesting because yeah, I mean from like a title perspective you can technically split these out into a different title and platform would be focused on really like your customer is the developer, right? Like you have internal customers and then you can have like these concepts of like internal service level objectives and you know, applying SRE principles on top of that. So there's really, there is a need for it in my opinion. But I do believe it was, I mean I really do think it was a marketing term. Look who owns the, you know, the domain, right? There's like websites Named after that and whatnot. But there is a need. But at the same time, I think it was like a marketing thing. I think people were selling it. There is all of that. You hear that with like, observability as well. But it's a real thing. But at the same time, companies are without a doubt, like taking it from each other and selling it ultimately.

Right? So, Evan, you're known as someone that actually starts things. Like you'll start a program, like SRE program for a new company, automation process for a new company. It sounds like. Are you starting. Is this once again you taking over an area that maybe was lacking the company? Like, you know, we need platform engineering. So let me lead that that way.

Yeah, I mean, with one of the companies I'm working with, it's kind of like that right now because it's such a, you know, it's such a small company where, I mean, I guess you could really think of it as like a couple different ways. One, you know, with platform engineering, you can kind of like ensure everything's in git, you know, all the code bases and git and everything else. So we did that, you know, and that was one of the things that we inherited with one of these contracts. And they ended up acquiring a company that had some of this already built out. And it's interesting because, like, these terms weren't even around then. You know, that's what I find to be super interesting. Or they weren't like, actively kind of talked about or promoted and whatnot. But I think what I see is it's not necessarily like I'm building out that process for this. Org, it's more so like we kind of inherited the code base that already does the thing that we want it to do. So and what I'm getting at is like, we have infrastructure as code right now that's both in Terraform and it uses AWS SDK go and go. And what's cool about that is it also uses make files and like, you know, you're just. You're running this make file and everything is really kind of abstracted away from you. You know, that's what. That's what I find to be super interesting. And you just enter in a couple of configs. So in this case, it's like the domain. You need a fully qualified domain name. You type in, you know, your access key, your AWS access key, and all that secret key, and then just the region, you know, you specify the region where you want to deploy this platform. And that is like in A way we're enabling our dev team to kind of deploy this in a super simple, simplistic way. So that's one way of looking at it. So yeah, there's that. I mean, like I. With platform oftentimes, like, and that's kind of like what I've been doing as of late. Right? Just like from a practical perspective, but I think from like more of a theory ish perspective is like a lot of folks are already kind of doing this and they just don't like, they don't have that title. You know, they might be like Operations Lead or you know, SRE or like, you know, DevOps engineer and you know, DevSecOps and all these titles. But at the end of the day, like, they might already be doing this. They might have like developed a platform with something like Terraform or some other kind of technology stack and they're enabling their developers to kind of deploy more frequently by abstracting away what they don't really need to know about. There's a couple of super smart people on the interwebs that kind of talk about this. Kelsey Hotter kind of mentioned this with like, you know, like Heroku. And this is something I actually used back in the day. By back in the day I mean like a couple years ago. So I was deploying Rails apps to Heroku and it was like, you know, it was like platform engineering in a sense where I just had to specify like dinos and these are all like Heroku terms. Just like, you know, what, what instance you want and all that kind of thing. And you would deploy it from the CLI and then it would just deploy and your site would kind of like. And there's some minor config associated with it as well. But like you just deploy your app and that was it. Like it was, you know, no ops, right? Like no ops and everything else. So like that was a platform in some sense. But now like, you know, with added complexity of distributed systems, you know, and everyone having to learn K8s and understanding all the terms associated with that, pods and nodes and HPA and erds and all these things, the problem becomes not everybody wants to learn that as well. So you're essentially kind of regressing back into throwing something over the wall and you're saying like, hey, I need a cluster, I need a case cluster to actually deploy this. How do I do this? And then platform engineering comes in there and says, okay, let me streamline this for you as best as I can. At least good companies are doing that. They're trying to streamline it so that there's no levers to pull in terms of, you know, asking somebody to do something, that kind of deal. So it's like a super long version.

Yeah, that was good stuff. You mentioned a few. But what's some skills or activities associated with platform engineering that you think someone needs to know or could work on to help the process along?

Yeah, understanding cloud, you know, that's a big one. I know that's like kind of thrown around a lot. And like, what is cloud? Somebody can define cloud as like, you know, GitHub. Right. So like call it in the context of public cloud. So like AWS and Google Cloud and Azure and Linode and all these fun services. So I think that's a big one in terms of like tooling and whatnot. I would say the big one is Kubernetes. You know, you hear it a lot, hearing a lot of folks talking about it. And I've been working with it since like 2019 now. But, you know, I think at the end of the day, it's understanding it to the point where if needed, you can use a language like Go that's, you know, compatible with K8 and whatnot. And then to be able to work on potentially something like a custom resource definition and just being able to work on K8 to the point where you can kind of mold it into a nice system where you're kind of abstracting that away from dev. I think that's kind of like a big one is. And that's. I'm focusing on platform engineering and deployment because it's such a pain point that I see at a lot of companies that I've either worked with or work with right now there's this need for. For that. But I think as well as infrastructure as code as well, like understanding that, like really knowing, really understanding that, like Terraform is a big one. There's a whole bunch of others, like it just depends on your flavor. Like, I use Terraform and then with one of the projects that I had mentioned earlier was AWS SDK in a specific language like Go or Python or whatever. But there's a ton of tools around that space. And then there's also just the knowledge, like that cultural knowledge of understanding, like the pain points of, of your customers who will potentially likely be developers. What are their needs? What do they want? What are we trying to accomplish? And I'm going back to the goal, right? What are we trying to accomplish as a business? Because oftentimes, like engineers, we get so far into the weeds where we're just so in tech, we're in the stack, we're in the code, doing all these things, but we're not thinking about, are we building something for fun? Are we building something that's actually going to accompany the business in terms of monetization and making money and all these kinds of things? What is the goal? Do we want to release more frequently? Or are we building something just because we want to, you know, work with Rust or something like that? Right. So I think especially now, just with the economic situation and whatnot, I think that's a, kind of a big thing to remember is that.

But how do you get there? You said it's all about enabling dev teams. So I guess, obviously each dev team is different. They're struggling with different things. It's up to you to realize, okay, this dev team I'm working with is struggling with X. So let me solve for X by hopping, create a platform that's able to accelerate that for them.

Yeah, I mean, so a friend of mine that I talked to, I can mention the company, just not the name, but like Capital One, you know, there's just, there's like this effort for, you know, you kind of act as, like this, I mean, you hear the term like developer advocate and whatnot. So it's interesting because, like, you can kind of act as an internal advocate at your organization or organizations if you contract. And it's interesting because, like, you know, if you act as that internal advocate, sometimes people, you know, they'll come in, they'll do the job and that's it. You know, they'll keep using whatever technologies there are and all that, you know, without really thinking about it, just kind of clocking in, doing the job and that's all good, you know, that people do that and that's fine. But, you know, if you want to drive this internally organization, look at the process, look at the pain points of the process. If you're not like, say, for example, if like you're in test or something like that, like, you know, you should be embedded, you know, by now in like the continuous delivery process and deployment process and whatnot. So, like understand, like, you know, from a pipeline perspective, like, where are those pain points? And then maybe work with your devs to figure out, you know, what do they, what difficulty are they having? You know, are they having to, you know, write their own, write their own YAML files for every deployment in EKS or something like that? You know, that's kind of a, you know, look at those pain points for them. You know, and then kind of advocate internally, they'll say like, hey, maybe we should, we should consider, you know, doing this, this and this or something like that, you know, drive those conversations. It's worth the effort because you just, you'd be amazed at like, what you can do, really. I mean, it's, there's a lot just like, there's like limitations on like, what you can suggest. Like, I know for like a long time ago, I was like, I think I was like interested in Serverless at the time, and I was like, I was like, we should check out, we.

Should check out this.

And like, you know, some of the devs came back to me and they're like, oh, you need to rewrite the whole code base.

So there's, I don't know, you might run into some silly conversations, but it's all fun at the end of the day.

So I'm all about automation. Is this enabling developers to spin things up quickly using automation? Is that the underlining principle or is there more to platform engineering?

I would consider that to be really, you know, the end game. I would, yeah, you're developing, you know, you're developing tools that make the deployment process easier. You know, that's kind of like a big, A big piece of it or something else. You're developing tools to make the developer process easier. You know, maybe for whatever reason, Jetbrains doesn't have something in place. You know, there's no, like, you're doing a lot of glue work. You know, that's kind of what I see is platform engineering. You might be, you know, taking, I mean, a real example here would be a lot of companies already doing this where you're modernizing, let's modernize. But realistically, oftentimes that just means the company's going to distributed systems and overly complicating themselves with the whole mess of new problems. But what ends up happening there is maybe you are doing that process. And this is something I've been involved with and still am involved with in a few scenarios where you are. Yeah, I mean, you're working on a distributed system. That's the new site. And then your legacy system is on. Say it's a monolith. You know, it's like some monolith or something like that. And you have to. You have this weird dependency from your distributed system that still requires, for whatever reason, without keeping decoupling in mind here, it still requires some dependency on that monolith. Right. So now, like, now you're in the scenario where like, okay, now I Have I'm deploying to this new platform or this new case instance cluster and now I have this issue, you know, I need to deploy. If I do a deployment, how does that work? So like a platform engineer could go in there and just like create that glue work and that and you'll piece that together where, you know, you can kind of deploy without really thinking about it. Without, you know, the developer kind of thinking about it. They're focused on the code and quickly releasing product. You know, that's the end goal there. So that's, that's one like good scenario. A couple scenarios there.

I mean, so just guess came to my mind, there's unit testing, there's integration testing. Anytime you automate something in our process, is there such thing as like platform testing? For if you spin a container up to, is there like a smoke test or something that you create that's part of the platform to ensure that even though you did automate it, that it is up and running correctly as you would expect without developers having to do something to configure it?

Absolutely, yeah. I mean, that's some of the practices when you're writing the code. I mean especially like I can refer to Terraform. You know, there's a, there's a lot you can do as far as Saskny is concerned. You know, you can kind of dish out the money and use Terraform Cloud where, you know, you're using that tool and it kind of helps you focus on, you know, what matters with infrastructure's code and whatnot. Like in terms of reliability and all that, you know, drift and all these different things. And then as far as like a code perspective. Yeah, if you're really using like go and whatnot, you know, you can do unit testing, integration testing, everything else there as well. That fits into the picture because yeah, ultimately, you know, when you're doing platform engineering and all that, you know, you're developing that platform. So like all the tests and everything kind of fits in there as well. Even if there's like a ui, you know, if you built out some platform, some internal platform where, you know, there's a ui. Like I've mostly done cli. So like I've mostly done like you know, tool like makefiles and you know, bash and taking bash and kind of putting all together and all that. So from a UI perspective, I don't really have the experience to do like the end to end test with anything platform related. But I mean you could probably, if it's like some webpage, you could, you know, Tie up playwright and selenium, whatever your choice is there as well, and then kind of like your preferred language. But, yeah, nice.

Now, I know a lot of people was like another technology, another term, another thing, platform engineering. But do you see the reason being maybe the need for this is because everyone's going cloud native now and also containerization's coming into play. It's a little more. You need to have some sort of expertise in these areas now in order to efficiently develop software quicker and faster to free up your devs, I assume. Is that one of the reasons why maybe this was created, this term, or why it may be increasing in popularity?

Yeah, I mean, I think we're kind of, like going full circle. Like, I think what ended up happening over the past couple years is that there is this big shift for. I mean, it's really is like. I mean, there's a whole slew of different reasons why all this happened, but, I mean, there was. Yeah, I mean, there was like, with. I mean, I saw it happen, like, firsthand. Like, with. I mean, when I was working 2018, I was like, I was looking at it from, like, a cool technology perspective, but at the same time I was, like, concerned about the business in terms of just like, I've saw so many outages and so many issues and so many different problems where I kind of, like, was gravitated towards kubernetes and like, distributed systems and computing. And I was like, oh, this is going to solve all of our problems. And then what ended up happening was it created a lot. I mean, it created more, if you want to be realistic, to the point where, like, my job kind of turned into, like, I went from test, you know, like from test to Ops to Kate's, and then, you know, and then just working on that and finding out the issue of.

All the problems associated with that. So, like, yes, I think what ends up happening is a combination of things. I think there's this marketing perspective of, like, people, like, kind of saw this happening where, like, people were kind of gravitating towards distributed systems and kubernetes and whatnot. And, like, the issue with, like, developing for it was a problem and, like, just simplifying that process and that approach. So that was a big problem there. So, yeah, I mean, I kind of see it as like, we kind of, you know, when we were, like, using before, we were kind of using tools and, like, kind of easier approaches to things. We'd like, deploy monolith and, you know, there are scaling issues there, of course, but oftentimes like how large do some of these companies even need to scale that run case? Like that's the other big problem there. So yeah, I think there's, there was a need for it, but it was kind of like this self inflicted need which just we saw ourselves kind of doing all of these amazing distributed system things and then we're just kind of back at like oh wow. It actually is kind of, it's really difficult to develop for a lot of this stuff and to kind of deploy in these platforms and to learn, you know, the learning curve for these platforms and everything else. Yeah. So yes and no.

I guess. So that being said, what do you think is the future of performance engineering? Is it going to be a thing? I know you said it may have started off as a marketing term, but seems to me it makes sense. So do you see this as something maybe someone get in on early, like maybe when SRE was just starting or DevOps?

Yeah, I think I do think so. I do think that there's going to be at least the term thrown around in like job descriptions and whatnot. But I mean if you've been working in like operations and you know, like in writing code and you know, doing SRE ish things, I really think that, you know, you're probably already doing this, you know that. So there is that reality. So I think that large companies who have very large teams are going to be hiring for this type of role. But at the end of the day I think platform engineering, I just think a lot of people have already been doing this, they just don't realize it. You know, even if you're using like a managed service to some degree, you know, like you're just kind of like the point behind that that I see is you're just in further and further abstracting away like all of these technologies that you know, we're using like especially like in the cloud native space, you know. So that, that's kind of how I see it. So even if like I did like last week, even if you're like searching for like the term, you might see that title, you know, as you might see like you know like the site reliability engineering title and all that. But at the end of the day you might have already been doing these things. It's very possible especially if you're like, if you're doing some operation stuff.

So 7 I know a lot of times I talk about automation or anything in general, there's always metrics or KPIs. Even with SRE, I believe there's certain KPIs you can use to make sure your team is going in the right direction. Are there any type of metrics or KPIs for platform engineering to make sure that people may be focusing in on the right things or how do you measure things to make sure you're on the right track?

Yes, absolutely. So with, I would say DORA metrics, I mean that's kind of like a big one, right? Like with it's just across engineering in general. I think DORA metrics are pretty solid, you know, from that just looking at like deployment frequency and everything else. I think deployment frequency is like, is a big one. It's huge. Especially, you know, especially with everything going on. Right. Like you want the business to ultimately succeed and all of this technology, you know, that we've layered and layered and layered and layered on top of everything we've been doing prior to any of the simplicity we were doing back in the day. Thing is, yeah, deployment frequency is probably one of the bigger ones in terms of like platform engineering versus like sre. I would say like SRE would be focused on uptime. So like over there you'd look at, you know, literally like throughput and you know, memory percentage and CPU utilization and all these kinds of things. And just ensuring from an SRE perspective you have like your auto scaling set up and then from like a platform engineering perspective, you know, you're just ensuring deployment frequency. You know, like I wouldn't. The worst things you could do would be like look at like lines of code and you know, all of those, like bug count and the terrible metrics, you know, those kinds of things you want to avoid. But yeah, absolutely.

Kevin, before we go, is there one piece of actionable advice you can give to someone to help them with their platform engineering efforts and what's the best way to find or contact you?

Yeah, I mean for platform engineering, yeah, just look who's speaking about it, look who's trying to sell it. You know, just ensure that you're not, you know, buying into something like especially a title or something like that where like you're essentially buying into an organization or a company. You know, I think that's a big deal, especially for practitioners, you know, like ourselves. You know, it's just a big, it's good to not to get caught up with all of these new terms and titles, but just to kind of understand it as well. You know, I think that's like a big piece of advice because like oftentimes you might already be doing these things.

So.

And then as far as reaching me, I am on Twitter, so reach out to me there. Email YouTube is random thought stack. Yeah, pretty much kind of getting back into making some YouTube videos, so keep a lookout for that.

Thanks again for your Performance Testing Awesomeness Links to everything of value we covered in this episode. Head on over to testguild.com P1.03 and while you're there, make sure to click on the Try them both Today link under the Exclusive Sponsor section to learn all about SmartBear's two awesome performance test tool solutions, Load Ninja and Load UI Pro. And if the show has helped you in any way, why not rate and review it in itunes? Reviews really do matter in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Performance and Site Reliability Podcast. I'm Joe. My mission is to help you succeed with creating end to end production full stack Performance Testing 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, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing SP 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.