Farm to… DevOps?: How anyone can grow into a tech career | SecurityMetrics Podcast Ep 101

Join Jen Stone as she chats with DevOps engineer and Day Two DevOps podcaster Kyler Middleton about her unique journey from a rural upbringing to becoming a DevOps expert. Discover how Kyler's passion for teaching led her to a career in technology, and learn about the importance of automation and documentation in building secure and efficient cloud environments.

This episode dives deep into DevOps practices, the role of Terraform, Azure vs AWS, and the challenges organizations face when adopting cloud technologies. Kyler shares valuable insights on overcoming common hurdles, fostering a blameless culture, and the future of DevOps. Don't miss this engaging conversation!

Hosted by Jen Stone, Principal Security Analyst (MCIS, CISSP, CISA, QSA).

[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.

Request a Quote for a PCI Audit ► https://www.securitymetrics.com/pci-audit

Request a Quote for a Penetration Test ► https://www.securitymetrics.com/penetration-testing

Get the Guide to PCI DSS compliance ► https://www.securitymetrics.com/lp/pci/pci-guide

Get FREE security and compliance training ► https://academy.securitymetrics.com/

Get in touch with SecurityMetrics' Sales Team ► https://www.securitymetrics.com/contact/lets-get-you-to-the-right-place

Transcript

Hello and welcome back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. Very excited about the topic today. As if you are a long time listener. You know, I'm always excited about the topic because I'm not talking to somebody if I'm not excited to talk about the topic.

So but this one's a fun one because DevOps has a real, strong place in my heart. I, a lot of people know I spent a little over 20 years in IT operations before coming to the security side of the house, you know, strictly and being, an auditor. But, DevOps was one of the teams that was the most fun to be part of because it was still developing.

Right? It's been it's it's kind of a newish thing, and it's something that a lot of people still are not quite sure what DevOps is. So I think the best way to launch into this topic is to say, Kyler Middleton, welcome to the podcast. Thank you so much for being on the show with me. Would you please tell people about yourself?

Absolutely. Thank you so much for having me. Hello, SecurityMetrics audience. you're all you're all so cool for listening to...

They really are. They're great.

I'm Kyler Middleton, I'm a DevOps engineer based in the United States. I like to teach, I like to build. I've primarily focused on sort of like Terraform automation, DevOps, which is just automating everything, as far as I can tell. But Jen and I are going to figure out what DevOps is today, what? Just so just stay on the line and we'll we'll give you the the final word.

Oh yeah. Oh for sure. We'll have it all figured out before the end of this podcast. Okay. So one of the things that when we were talking before and and just fun fact, I got to be on your podcast, Kyler has a podcast. Maybe you should mention that first just so we can, you know, context.

That sounds great. I host a podcast with Ned Bellavance, who's brilliant, and he lets me tag along. It's so fun. it's called day two DevOps and we talk to all sorts of folks that have either succeeded wildly or failed wildly or both, which you'll find is very common in doing DevOps-y stuff, because DevOps is absolutely everywhere and operations and development these days.

Great.

And so after this podcast is over, go look for that one. Have a listen. It'll be a lot of fun. So we were talking a little bit in preparation and you said that you you went from farmer to DevOps right.

I did.

So that

There were some jumps In between there.

Well I was gonna say it seems like a big stretch, but maybe you could tell people, as everybody wants to know, how do I get into security? How do I get into DevOps? How do I how do I break into whatever it is that people want to break into? And I love the idea that you went on a journey that that a lot of people wouldn't have thought of.

Oh, I'm going to start off in farming and then end up something, you know, like DevOps. So tell us a little bit about that.

Totally. I have so much to say. Every time I tell a story, it gets a little better. So this is the best version I've ever told. I grew up very rural in, western Nebraska, where there's more cows than people. Nebraska's, rural United States right in the middle, what we call the flyover states. And, there were farmers who had computers.

Farmers are very early adopters to a lot of technologies. Yeah, you have to be, and there's no corporate looking over your shoulders. There's usually just you and your partner making do, figuring it out. Absolutely. And they had computers and the computers would break because this is, you know, 1997 or something like that. And you would have to pay someone from the “Big City”.

And those those words are capitalized to drive out to your farmstead and fix your computer. And that was very expensive. Absolutely. And sometimes it was as simple as, like, you wasn't plugged into the wall or something and wiggled loose one of the cards in the back when the PCI cards. And so I was ten years old and volunteered to mess around with our computers in exchange for Rice Krispies and brownies and stuff like that.

I, too, have been known to work for Rice Krispie Treats.

So absolutely sweet treats I would do just about anything for. My morals are very flexible when it comes to sugar. And so I of course I didn't know anything. I was ten years old, but I like to learn and I like to play, and I would just hit all the buttons and read the error logs and figure it out.

And it was a lot of fun. And that's how I got started, and more than just working on computers, which is really fun because it's logical problem solving. Yeah, I got to help people that would otherwise sort of be missed, or would not have the funds or resources or support network to help them. Yeah. And I, I got to see what it would do for them, which is sometimes extraordinary, like going from rural Nebraska to having the internet was a tremendous leap.

I mean, it's a leap for all of us, right? But it was biggest for them. And, eventually I ended up in college, and I didn't understand that working on computers is not something that comes intuitively for people, because it kind of does to me. Like I've just spent a lot of time with it. I read the error messages closely.

I like to Google stuff, and when I found that out, I thought, oh, I better they pay you money for this. Oh my goodness, they pay you money to work on computers. I better do that. Yeah. And I was initially going to be a reference librarian. Like a children's librarian I love helping people find stuff and learn and eventually I found my way through, systems engineering, telecom networking, networking for, like, decade.

I have a bunch of Cisco certs that are expired now. And to cloud and cloud sort of is DevOps. It's very heavily built for it. Heavy, tooling built for it. And I found that I can do the same thing here. There are people that are just getting started or just learning a new thing. And that's always because this industry changes.

So much and they need help learning. They need help being supported. They, want to learn desperately, but they found a lot of barriers in their way, like the stack exchanges of the world where the top voted answer is like, you're dumb for trying. This is makes me so angry. So angry. You should never make a new learner feel bad.

Ever. And if you have, you've done it wrong and you should apologize. Go fix it because I'm coming for you. So my whole, goal in life now is learn a lot of stuff and help everyone around me learn it too, because it can change your life. The the knowledge, the money, the job, careers, the stability. It'll change your life.

And I want to help you get there.

I love that because that's how I feel about my job as well, is if you're not helping people from the position that you're in, then what are you doing?

Yeah, you should be lifting up others. And if you're not, figure out how to.

So one of the things that I've noticed about you is that you put out a lot of free information online, like, all the time. So, tell me about some of your some of your passion projects, some of the things that have really interested you and, and continue to interest you, and what is the information that you share with with people?

Totally. Jan and I were talking a little bit before the show, and I am also on the ADHD spectrum here, and so I will forget this conversation in about a day. And so I started working on these projects, and you spend a lot of time framing it up in your head, right? You're like, but this thing works with this thing.

That depends on that thing. And I would forget by the next day what I, what I worked on. So I, I take really good notes. I have to or my life falls apart and I decided to start writing down my DevOps type projects. Yeah. And if I write the whole thing in my head and there's kind of a narrative in there because that's what my brain's doing all the time is telling stories, then I'll just write it down and publish it.

And that's what I started. I started writing on my own blog, and then I moved it to medium. I just recently moved to Substack, under the banner let's do DevOps. Yes, like the idea that we'll all do DevOps.

We're doing this thing together and it's easy because we have friends that are doing it too.

Yes. And the knowledge is free and it's written so that anyone can understand it. Or at least I hope anyone can. So my passion project is just putting everything I do at work as a senior DevOps engineer on the internet and make it accessible and understandable by anyone, at any level. So they can do it too. Because like, I don't want to do it again.

I want you to do it. Yeah, I want to go find something weird and novel and and write about that next.

Right. I don't want to figure something out twice. And once I figured it out, I really don't want to do it a second time.

So, absolutely.

I think that the job that I have working with a lot of different people in a year, really helps that that desire to learn about other people's environments and how other people are solving problems. But what I like is that you're figuring it out and going, hey everybody, you could apply this to the problem that you have.

Yeah, absolutely. There's a lot of Terraform in particular automation and GitHub actions and stuff that once I solve it, I build it. So I never have to touch it again because I don't want to think about this thing ever again. I figured it out. I got it all into my brain. It was a lot of work to put it in there in the first place, and I just want it to take care of itself.

And so as much as I can't, I working really, really hard to make all the stuff around me and all the platforms automated the business that I'm at now, I built our entire automation suite for doing all our Terraform deploys and storing secrets, and key rotation is all keyless now because, like, I don't want to touch any of this expiring stuff.

I don't want to mess with it. I want it automated. Yeah.

So one of the things that you're doing a lot of work with, now is, is in AWS and there are a lot of people that are moving to AWS. So maybe talk about what is the intersection between DevOps and AWS.

Absolutely. And it's both it's AWS and Azure. And I find that I'm being pulled I started with AWS. That was where I kind of learned what cloud was. The APIs are really wonderfully robust and resilient, and the uptime is excellent. And I have just nothing but good things to say. About 80 of AWS, except for the bills that I keep receiving in the mail.

Yeah, yeah, it's a little pricey.

It is a little pricey, and Azure is, much more free range. It's much more enterprise focused, and it's quite a bit less stable and less robust on the API side, I think they just want me to use ARM templates and I really don't want to. I really want to use Terraform, please. but both of them are built with DevOps in mind, specifically the ability to automate anything.

And I find that really exciting and really powerful. Like, I don't know if I'll ever need to build 100 servers in ten minutes, but you can if you want to. It's really easy to do so. And so as much as you can write these silly little scripts that I write, I don't even know if I'm a programmer, but I certainly am a very good scripter.

And that's kind of all you need, to run your automation and build your infrastructure and make a company function. And I just find that really cool. Like, I just find it really exciting.

Oh, definitely. As a security professional, one of the things I have noticed is that AWS organizations that that are in AWS, they typically have less difficulty, for example, meeting PCI requirements, and demonstrating that things are secure than organizations in Azure. I suspect that it's because of the flexibility that Azure allows, as opposed to AWS work. From a DevOps perspective, it sounds like, you know, you do have some more flexibility in Azure.

Is that is that what you would how you would characterize it?

Absolutely. But I would say that's kind of a dirty word in the same way it is for regulatory compliance. There are lots of different ways to do it in Azure, and some of them are click ops type macros. That stuff is created and configured for you behind the scenes that you might not even know exists. And that can make it very difficult, difficult to even know what exists in your environment, much less audit it and keep track of it and secure it.

And updated. so with some of the resources like that are doing Terraform, where you're literally building one resource, you need to build six more things and you need to know how they're built, where in the gooey you just click go.

Yeah.

Deploy this package and it works great for a while, but it becomes difficult over time to keep it compliant and keep it updated because you didn't even know it was built in the first place. So Terraform sort of surfaces that complex city that's behind the scenes.

Yeah, maybe. Let's talk about yeah, let's talk about Terraform. Yeah. Because I think we've we've been talking about Terraform for a few minutes now and didn't even talk about what it is. So a lot of our listeners already know what Terraform is, but a lot of them have never even heard of this thing before. So maybe tell people about what Terraform is, how you use it.

What what it's what is wonderful.

Wonderful tool to have in your tool belt. Whether you're coming at this from a regulatory compliance perspective or an infrastructure security or an infrastructure automation perspective, Terraform is a tool for building resources based on code. And it's declarative, which means you can say, I want this server to look like this, it be this size and have these disks go.

And that is really an understated superpower, because of course, that's how it works for, regular iterative code too. So if you do an ARM deploy, which is the Azure Infrastructure as code language, it works the same way. But over time, as stuff drifts, as your resources no longer match your environment, you want to revert them to the config that they're supposed to have, and Terraform does that.

It will note the drift and it will correct the drift so your environment doesn't move away from where your code says it should be, from where you you probably want your environment to be, whereas other tools just build it and then say go manage it by hand, go manage it yourself, which can be very painful, especially at scale.

In any cloud environment, you're no longer managing two dozen servers, you're managing several hundred. It's just naturally will grow to great horizontal scale. And managing all that stuff is a huge pain. So you need tools, and Terraform is probably one of those tools. It's, no longer open source. It's, source available, which I have some strong feelings about and I won't get into, but it's, a free tool to use, and you probably should be using it.

It's very common anymore.

Yeah, that that comment about, some natural drift and about, manually, managing an environment. Those are two things that can take you out of compliance very, very quickly. And that can also affect your security stance, because if you're not quite sure about how everything is interacting together or what the exact configurations are, it can be very difficult to know, am I managing the security of this?

If this has been altered in in certain ways, and I think that terraform, and other orchestration tools, centrally managed tools are the way of the future.

Yeah, I think so too. And I think it's the enablement factor that if you are manually making changes in prod, you have to have really highly trained, careful engineers. And those are expensive. Yeah. Those highly trained careful. Those are expensive folks that are just doing click ops over environment A and then B and then C and D. And if you're using infrastructure as code you can separate I have a proposed change from the approval of the senior engineers that can just read the change set and hit approve.

And it can be deployed in as many environments as you need. And you can run unit testing. There's just so much more stability and support and scalability on DevOps ified shops like that. So it's definitely the future for any kind of regulated shop. And my day job is in health care in the United States, so we have to be quite cautious of HIPAA compliance and other compliances as well.

Yeah. And HIPAA is one of the, the regulations that that I personally sometimes do assessments against, especially like risk assessments in a HIPAA environment. And one of the big struggles that I see is thought wasn't put into, how are we going to centrally deploy and manage and understand this environment going forward? Or we have third parties so we don't have to worry about it, and not even thinking about how those third parties are integrated into your environment and how the various pieces of the environment interact with third parties.

And and what could what the risks are that could take you down if you just think, just a third party. Right. And so, from your perspective as someone in DevOps and somebody who's been through some compliance things, who understands that the need for some of these regulatory things, what what do you see as some of the best ways to ensure security in an environment and and secure an ability to to demonstrate compliance in a cloud environment?

Yeah, absolutely. I think it's multifaceted. but that doesn't mean that it's really difficult to do it just means you're going to need some tools and procedures in place. So for environments that have access to protected data, you definitely need to draw a circle around those environments. And there are rules here. This is a lawful place. Everywhere else can be lawless.

Have some sandboxes for folks to just mess around in. That's great. Go to town. But those environments cannot have access to your protected data. for the environments that are protected have rulesets. clouds are great at that. So in a, local environment, in a data center, you can do anything. There's no intrinsic, you know, fence around things.

There's no bouncy runner down the bowling alley, but in clouds you can. Right. I think Azure control plane, control center. I forget the name for it, but you can write rule sets where folks can't create a public IP. Or if you create a database, you need to set a security group that only permits 1 or 2 IPS.

So you can deploy all sorts of those things that are have sort of an ongoing hard requirement to protect your environments. And then in terms of scaling and making changes, as you see, this isn't correct. We need to fix it. Say you have 50 servers and you need to make a change on each of them. Going one by one takes forever.

But if you have a tool like Terraform or some other dev ops process, you can make the change in the module in the central code that builds servers, and then deploy it to all your environments in a couple of clicks. So it can be very empowering to centralize your configuration and be able to deploy them at scale.

Yeah, yeah. one of the challenges that I sometimes run into with organizations is that they don't want to document what they have going on, and I try to explain to them that the documentation, the configuration standards, the the policies and procedures, these are not just for a third party auditor to look at and say, yeah, it looks good.

These are for, you know, if you want to bring someone onto your team, how are they supposed to know what the rules are without without having it in some way documented? So as someone who has, you know, work with different organizations and things, what what is your experience in coming into and being a useful part of an organization?

with reference to documentation?

Totally. I, I really like this idea that we see spreading around a lot in, modern organizations, which is blameless culture. And that means that if you as a single individual are able to break production somehow or leak data or do anything they would, you know, infringe on your regulatory compliance, that is not a failure of an individual, that is a failure of an organization.

The processes, procedures, technologies, training, those all should have prevented you from doing the thing. And that means it's a failure of all those things and not just you individually. So we can have really great documentation and we should create that. That's part of training our users. But you, as maybe the platform team or the DevOps team are in charge of those procedures and tools that should prevent that stuff like that from ever happening in the first place.

And I don't know if that exactly answers the question.

No, I love protection is important.

Yeah, yeah.

Because it goes beyond documentation. Right? It is just hey, you should have a configuration standard, but you should have, your tooling set up in such a way that you can't violate the standard. And, and I think that's another, other way to look at it, where sometimes I'll talk to organizations and they'll say, we don't have a configuration standard.

Okay. How do you deploy your things? Well, we use these scripts and we use these, images. Okay. So let's connect the dots between what your configuration standard is. And so I think sometimes the language around it gets in our way. Because if you have a defined way of doing things that's in your tooling that you can't violate, that's your standard.

Right? Absolutely. It just lives in your head. You need to write it down because then it's easier to convey. And if folks leave either the bus factor or the win the lottery factor, then you still have it. And you need that. You need for your business continuity plan to understand how your business operates. So write it down.

And and you know, another thing that I think is that people don't often consider is if you're writing things down, if you're documenting policies and procedures, that's another way to, evaluate whether what you're doing is the right way to do things, or it's another way to make sure everybody's doing things the same way, because sometimes you'll have people following wildly different processes and and getting, you know, mixed results depending on who's doing what, where.

If you have something documented, then as a group, you can look at the documentation and say, do we as a group want to do this this way? Is this the right tool for that? Is this the right configuration and that tool for that? But if you don't have it documented, it makes it more difficult because then you're just having a sort of ethereal conversation without concrete examples of what you're talking about.

Absolutely. And I've seen this many times before where someone says, you know, I'm this subject matter expert on this widget and I'm too busy to write it down. All of it lives in my head because I'm so busy and important. And and maybe you are, since that's someone else who has time and cycles to just shadow that person and write down everything that they do.

And you will a build documentation and be siloed that person. Yeah. To such an extent that you will make your business safer and more stable, and then maybe have that person take a voluntary leave for like a week or two, or put them on a different project and have this new person step up and then cross-train, because you have to de silo that kind of knowledge.

It doesn't make sense to have kingdoms and castles. We need everyone to be able to look in and see how things work. That's documentation, that's scripting, that's automating. When you're building tools that run your business and protect your business, you can read the rules. Those tools are operating on and see how things should work. And that can be your documentation.

You should have human readable documentation too, but it's a good first step.

Yeah, yeah, I, I agree with you. I think that, you know, you're how you described breaking up silos is it's an excellent way to do it. getting someone to document for them and then having them go on vacation. because because then they're not there is as a backstop, you know, in the room, people have to go all right, did we get this right?

Is the documentation right? And, and if it's not, then you know that they have to do something to, to fix it, but also the training that the person gets by having to understand and knowing that they're going to be stepping into that role, even if they're not permanently stepping into that role. But, these cross training opportunities, I think that that's a really excellent way to do it.

Absolutely. Particularly for deploying your software. it seems so simple on the outside. Like we just compile all the code and then we check it into an artifact store, and then we put it on the servers. But what about when one of those doesn't work and there's a bug and you need to roll back and all of those different modalities get really complicated.

Yeah. And so you're building release team in particular. Like if you don't know where to start with this, you need to write that process down. And you need to write down all the exception rules because those are incredibly complicated.

Yep, yep. There's I've told this story before, but a lot of people haven't listened to every single podcast. So I'm going to tell it again. So that was one of my, first opportunities in a as part of a DevOps team was really on working with the processes, not doing them myself, but working with the people to understand and simplify and streamline their processes.

because there was a team that was deploying code and they were doing it once a week on a Thursday, and it was taking them 12 to 14 hours. and I know how painful is that? Can you imagine being one of the people knowing that you're not tapping out? You're one of the people that is there until it's done and and the feeling that they would have when we'd get to the end in it, and then everybody would hold their breath and and they would say, oh, we're going to apply the deals.

And literally people would hold their breath. Right? So, so part of it was because this was not and I figured it out because I said, okay, where's the documentation on how we're doing this? Let's see what's where the breakdowns are. And there wasn't any. And I'd say, okay, well who is doing the deployment. And there were three different people that were doing it.

Two main and then one kind of, you know, on occasion. And I said, okay, so how are you guys doing it? And they said, well, I do it this way, but I do it this way. so. Okay, first of all.

Don't do that.

Let's. So so then I asked, all right, who is the most senior person? And they all turned and pointed at one guy, said, great. How about if you write it down while you go and exactly what you talked about where you said people don't have time to do it? He didn't. I said, great, okay, let's get someone to write down the procedures that go on while you're doing it, and then the next person who does theirs, will write, will go by that as a checklist and call out things that were missed and refine it.

And so all we did was refine the processes being used to come to a unified agreement on what to do. And it dropped down to a two hour release.

Which, oh my.

Goodness, I mean, so this was this is quite a few years ago. So now releases are quite a bit faster and more automated. This was so there were some automation. We were I know for sure that the team was using puppet and and I can't remember all of the, you know, the other tools they were using, but it was it was not fully automated, but it still just by having a consistent process, we were able to drop it down to a manageable thing that was not airing out, and they didn't have to roll back multiple times during the process.

And so, everything that you just said is absolutely I've, I've lived that myself. Where is it consistent? Can we can we document it? Do we know how this is supposed to go? Because if you don't, how do you fix the problems? You don't even know where the problems are.

Absolutely.

So, from your perspective in working in things, what are some of the gotchas that you see people really struggle with when they are, working? Maybe in a DevOps situation and, and trying to create these, these consistencies and trying to create these, like more easily managed environments.

Totally. I think there's sort of this intrinsic fear of automation that it will take my job. I'll write down all the stuff I do and I'll automate it, and I won't have a role left. And the way that I try to address stuff like that is you will automate all of the repetitive, boring stuff that none of us want to do anyway.

The stuff that's interesting and chaotic and dynamic and fluid, like you're still needed for that. You can't automate away your entire role. We'll see what AI does in the next couple of years, but we're not there yet. So all this automation, all this work that you're that you're putting in towards, you know, potentially learning a programing or scripting language and a DevOps platform like GitHub or GitLab and building it, that's going to take away the boring parts of your job that probably you didn't like doing anyway.

And you're not going to get fired. You're going to get to work on interesting stuff and learn more. So I see it as like a real big net win. in terms of gotchas, I think it's really easy to get stuck in the minutia of this thing happens once a month, and it takes me ten minutes and I'm going to have to spend six hours writing a script to do it.

Don't start there. That's that'll take you like seven years before it makes sense for that time investment. Start with this stuff that happens frequently that you need to do, like every day or every hour or something like that, and just start automating as much as you can. You will absolutely write some terrible code. that's true of all of us, by the way.

Even if you're just a brilliant genius, when you look back and stuff from a year ago, you think, wow, this this idiot, this is terrible. Oh. It's me. Oh, yeah, that was me from a year ago. So that's natural. But you have to start somewhere, so just start doing it. I find really good. I find I have really good experiences with looking at, like, reading Terraform for cloud resources to learn how they work.

You learn all the little Boolean flags that can turn on and off. I learn a little bit easier that way than reading, like the gooey and building stuff, but cloud is sort of unique here and DevOps too, because all these platforms are cloud hosted now, where you can just go do it in a way that you couldn't before.

Like if you want to learn how to do data center switching on Nexus, which is like, that's for grand, and you need six plugins to get it running and it heats a whole house up. You can't just go buy one at Walmart and put it in your house, but you can certainly create an AWS account or an Azure account with a credit card and spend like nothing for a year and learn all of it.

All the features are there.

And they have so much free education on both of them.

Yep, absolutely that we are creating like Jen and I. But also there's so much from these platforms, there's so much just on the internet that you can Google. You might have to pay $5 a month to medium, but you can find everything in the whole world out there, and that is super cool for sure.

And and I want to call back to what you said at the beginning, which was people are afraid that they're going to automate themselves out of a job, and who knows what AI is going to bring. Look, this is the same thing people have been saying since I started in technology in the 90s. It's been the same thing.

And it's how far are we from the 90s? I mean, I know in my heart I feel like it was only ten years ago, but it's.

Not I was going to say ten years ago. Right?

Right is much longer than ten years ago. but but I, I think that history has shown us that, we aren't automating ourselves out of a job where we're getting better at our jobs and becoming more valuable and more useful to the organizations that we're in, and that whatever comes down the road from AI, which is the big new thing, we are going to continue as human beings to put creative thoughts, not towards difficult problems.

And we are always going to be able to, find, demonstrate value in an organization for, for that ability. And so letting go of the fear that learning to automate and creating automation, letting go of that fear, I think is, is a helpful, useful step for people in, in DevOps.

Yeah, that's wonderfully said. I can't remember where I read this, and it was that AI itself is not going to take your job. That's not a thing. But people that are versed in AI and that are good at using it may. And I don't know if they'll take your job exactly, but they will leave you doing the boring, repetitive stuff and they'll do the interesting projects because they've got the better tools.

So go out and learn those tools. Yeah. And if you're stuck at programing, if you're just new to DevOps or programing or scripting, these AI tools like ChatGPT is free and it's excellent at teaching you how to do stuff. Yeah, if you have some public repos, you can sign up for GitHub Copilot and you can get it for little or no cost.

They're excellent at teaching programing because there's so many examples on the internet. So learn these tools, let them empower you and let them improve you. And let the fear go. Like Jen said, I love that.

Absolutely. So to wrap this up, what is your favorite thing about the work that you do?

I like helping people. I don't really care for computers. They're gremlins, you know, they're always breaking. I'm always asked to fix something that's broken. But when I can help people, not be afraid at their job and feel safe enough to experiment and test and break and build, and they are so proud of themselves for building something cool, I feel like the best person in the whole world.

I feel like I could fly, so if this helps you get there a little bit, that would be wonderful.

Thank you. All right, everybody go out and look for all of Kyler's things. plenty out there. Substack. podcast. And, hopefully you and I will get to talk again in the near future.

Absolutely. Thank you so much, Jen.

Thanks, Kyler. Thanks for watching. To watch more episodes of Security Metrics Podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.