Aug. 29, 2022

How To Become A DevOps Engineer (And What The Job Is Like)


Are you interested in becoming a DevOps Engineer? It's hard to solidify exactly what DevOps is and how to get into it, so I brought on a Senior DevOps Engineer to teach me more about it. As you'll learn, there's quite a variety of different types of DevOps positions, but David still managed to share solid advice on what to learn and how to land a DevOps job. For those potentially interested in this path, I hope this helps!

David Kirk (guest):
Linkedin - https://www.linkedin.com/in/david-kirk-jr
Podcast - https://open.spotify.com/show/1rPsb7EBWovFCNfS719AaR?si=Z3esnB1CRBm2ujaDYyBsNg

---------------------------------------------------

🤝  Join our junior friendly developer community:
https://discord.gg/H69QqZ8MVJ

🔥  Want more personalized help from me? Here are the paid mentorship and review services I offer:
https://calendly.com/donthedeveloper

❤️  If you find my content helpful, please consider supporting me by becoming a channel member and get access to additional perks. Every little contribution helps and is actually used to pay my bills.
https://www.patreon.com/donthedeveloper

---------------------------------------------------

Disclosure: Some of the links below are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

📚  Web development books and other products I recommend:
https://www.amazon.com/shop/donthedeveloper

Dev Interrupted
Behind every successful tech company is an engineering org. We tell their story.

Listen on: Apple Podcasts   Spotify

Ad To The Bone
The digital advertising, AdTech & programmatic advertising podcast

Listen on: Apple Podcasts   Spotify

Tales from a car salesman
Ask me anything about sales I am one of the top Kia salesmen in the entire nation! I...

Listen on: Apple Podcasts   Spotify

Transcript

Don Hansen:

All right. Welcome back to another web development podcast, where we help aspiring developers get jobs and junior developers grow. So a lot of you have asked me, how do I get into DevOps? So I've known a few people in DevOps. I'm gonna be honest, a few people that I have known that kind of keep to themselves. It was a little trickier trying to get people to come outta this podcast for DevOps, but I know. From experience when I start having a conversation and asking for advice, especially when building out the pipelines, I did have a lot of questions, probably bugged too many people, but, um, I feel like DevOps in general. Uh, when someone wants to listen to them, they have a lot of great advice to give and they usually have quite a bit of experience to, to back it up. But, um, yeah, I'm gonna be learning quite a bit on this podcast with you today, but, uh, I invited on someone that's been in this field for a little while. David, thanks so much for coming on. Hey, my

David Kirk:

pleasure. Thank you for having me, Don.

Don Hansen:

Absolutely. So I guess, uh, kinda just do a quick intro of your experience. What have you been doing in DevOps?

David Kirk:

uh, so I've been, uh, in the field for seven years now. Uh, I, thankfully I lucked out, uh, the guy who ended up becoming my best friend and current teammate is, uh, the guy who also sort of like pulled me onto the DevOps team at my first gig. Um, So, yeah, I've been doing it for about seven years. Uh, my first gig lasted for three years and that was at a company called relativity and I was on a team of probably 14 people that were doing DevOps. So it was the type of thing where you have a, oh wow. A relatively. Narrow scope of responsibilities compared to my next gig, where I was the only person doing DevOps at a company that had about 30 engineers. Uh, and so they brought me on to, they already had, uh, deployment pipelines and tooling set up to get, uh, stuff into Heroku. Um, and so they had a staging environment, a production environment, and then a sandbox environment and also a U a T environment. Basically they had environments that would get really messy and they wanted me to come in and build out tools to make the development process easier. Uh, and that's what I focused on for about like two, two and a half years there. Uh, and then. I am now currently working at a company called the network. Uh, no vowels in network. It's based out of LA. Uh, it's basically QVC for millennials. And if my CEO is listening, I'm so sorry for describing it like that. uh, and appreciate I was brought on . Uh, I was brought on for. Similar reasons, uh, to build out development tooling, uh, but also I've ended up just shifting. I I've built out, uh, me and my, me and my team have built out the, uh, entirety of the development production and staging infrastructure and all the workflows to move things around in there. So it's been a nice progression. I've really honestly been pretty fortunate with, uh, with the, with the opportunities afforded to me.

Don Hansen:

That's good to hear. So a couple things we're gonna explore today are, um, What it's like. Right. And I think it was even to you that shared with me, like DevOps can really have a variety of responsibilities depending on what company you work at, but we're also gonna be exploring. How do you get into DevOps? Cause that's also a really important question, but I'm gonna start off with just, um, a couple of questions out of curiosity. You mentioned you came into a job, they had Heroku Heroku. First of all, I love Heroku. I think it's amazing for a lot of developers to just get an app up and running and a lot of coding, boot camps who encourage their students to set something up with Heroku. Um, but when I hear that, it almost makes it so easy. That I'm surprised to hear. There was like a, a role where you would manage that. Did you, did you actually manage the Heroku pipeline or did you advance it to something else?

David Kirk:

So that's, yeah, that's a good point. Uh, so at that company, the thing that really rules about Heroku is that it is so easy to use and it really makes it so that you don't need to have. Like someone managing it directly. Um, and I'm a really big fan of like one of the, one of the primary theoretical ideals in DevOps is that it is a common it's. It enables developers to do operations. And as far as I'm concerned, managing staging and production is operations. And so I want the developers to do that. So fortunately I was. Hey guys, you know, y'all have all been running all the Heroku stuff this entire time before I got here, keep doing it. I mean, y'all are doing a great job. Like, you know, the, the, the site almost never goes down. They had clean workflows for getting things into staging and production. So I just left. Heroku as it was, and then built all of these stuff, uh, to enable them to do development more easily prior to it getting to staging and Heroku or staging and production. Um, so like for the, the, the main project that I worked on, um, was that like, if someone creates a branch in GitHub, we had maybe 30 different repos and we had a slack command and you would run. At Hydra, I named our slack bot Hydra because, uh, I thought it was funny that the idea that you chop one bug off and you introduce like four more. I like it. Uh, so you would say at Hydra QA stack, which would create a QA quality assurance stack, you would pro pass in the branch name and it would look through, it would deploy the whole thing. But for every repo that had that branch name, it. Use that branch and then deploy our stack into what's called an ephemeral environment. Uh, and then developers could do work inside of that, make sure that all their features work and then destroy that and then take those code changes and put it into staging. So, yeah, that's sort of what I've worked on was everything before staging and production.

Don Hansen:

Interesting.

David Kirk:

Okay. . Yeah. So whereas the old workflow would be that like they would get stuff into U a T user acceptance testing. Then they would run a bunch of tests in there or manually QA things that would have the feedback loop of around like an hour and a half. And you could only have one person working in there at a time, uh, which, you know, it's the type of thing where it's like with Heroku. Uh, when you only have five developers, that's fine. When you're a single developer working on your own Heroku rules, because it just takes DevOps is all about efficient laziness. uh, and so, you know, we had reached the point where we had 30 developers and they were constantly stepping on each other's toes. So we needed the ability to have multiple environments that they could be working in and then more automated tests. We eventually got that feedback loop from like an hour and a half or two hours down to about 10 minutes for them to write new code and then make sure it. Uh, please. Sorry, I cut you off though, please. No, no, that's tab really quick. Cuz I'm getting message on slack and I wanna be able to pay attention. sounds

Don Hansen:

good. That's um, that's interesting. I actually, okay, so. Ah, I don't wanna jump into this too quickly. So that was your second position. Cause I do have some questions about like what you should learn specifically, but I do wanna hold off on that. So the second position, it sounds like you essentially had more room to, um, just figure out like some of the holes of that pipeline you figured out it was before the staging process for your second company. Um, And then you allowed, um, you allowed, uh, multiple views on that where Heroku actually provided a limitation for that company. Mm-hmm okay. So when I hear DevOps and I hear DevOps talk about their job and their responsibilities, a lot of times it's just figuring out, like you said, that's a really interesting. What part of the process is kind of, um, broken and what can I do to make developers' lives easier and try to build those environments to be able to do that. That's essentially the, a slightly common thing that I hear, but I guess with your current job now, I guess I wanna get more of a picture. How is it different than the Heroku gem?

David Kirk:

Mm, yeah. Very good question. So like they actually, so at that, uh, at my previous job, um, We were using Heroku for saging in production. And then we were using Kubernetes in AWS for our development infrastructure. So. I wasn't responsible. I didn't design anything in Heroku. I was just responsible for the, uh, for the, uh, dev stuff. Whereas for this company, um, I've been fortunate enough that they were just like, yeah, run with it. Go crazy. And I got the dev environment set up, but, um, have you, uh, have you, have you talked before on this, about, uh, the tool Terra form? No, but I've heard of it. So Terraform is an incredible tool. Uh, I would recommend if people want to start playing around with DevOps, like you. You need to learn Terraform at the very least the very basics. It's incredible because it's a declarative programming language. You essentially just state here are the things that I wanna create. I wanna create this server. I wanna create this network connection. I wanna create this firewall, yada yada yada. And, uh, we have a few thousand lines of code that defines sort of like a generic. Kubernetes deployment with all of the supporting services and everything that we need to support our. Uh, environment, be it staging production or dev or whatever. Um, and then we have like a configuration file that we can pass in there to configure it, to be deployed to dev staging or production. So the main thing that I focused on with this company is that I wanted to write code to. All of our infrastructure and also have it defined in such a way that our development infrastructure is as close to identical as our staging or production infrastructure. Um, the primary reason behind that is that like, I. Well, there's two, two primary reasons. One of them is it makes it way easier for developers to do that work. And it's also like way easy. Like right now we're rolling out some changes to the way that we manage our DNS addresses. So we push those out to the dev infrastructure and leave that for a week just to catch any weirdness. And then, because it's, everything is defined exactly the same. We just propagate that up to staging in production. And then also. I'm very lazy. I don't wanna wake up in the middle of the night if like something is broken in production. I didn't write that code. And I'm also not the person that is going to know best how to fix it. So by using the same thing in dev. And forcing and encouraging and empowering developers to use the tools, to understand how to manipulate their environments in dev and fix issues in dev. They then implicitly learn how to do things in staging and production. So, uh, wow. Actually I did have to step in on some production issues, uh, about a week or so ago, but it had been like three or four months since the previous time that I had to do that because yeah, people just learn how to use these different environ. A long winded answer to a relatively quick question, but yeah, hopefully that covers it.

Don Hansen:

No, that's super helpful. Gives me definitely more of an in depth picture. And I feel like correct me if I'm wrong, but I feel like an ultimate goal of DevOps is to try to create enough automation and create enough comfort for developers and even just, um, ownership and, and resourcefulness where they can figure it out. So you don't get pulled into.

David Kirk:

Exactly. Yeah. Yeah. Okay. I like that. Yeah. That's the, that's the selfish thing of it is, you know, us DevOps, engineers, you know, we don't want to be pulled into that stuff, but then, you know, there's also the realistic thing, which is that like, developers don't wanna have to come to us to fix things. Like if you are freaking out because yeah. You know, your code is broken. You don't wanna have to go through someone else. And if you know how to fix it, I mean it rules. Yeah.

Don Hansen:

I remember my first job as a developer, it was so hard to distinguish. Was buggy, like what was actually buggy about the website? If we were having an issue, was it the code? Was it the back end code, front end code DevOps. And we had a really good DevOps person. It was never a DevOps issue. It was never an environment issue like that, which is awesome. Like that made it much easier. And I think, um, cause I think a lot of developers are a little less comfortable with the command line and, and going a little bit deeper in that direction. And even just setting up the pipeline environment. first of all, thank you. for making that easy. So with that third job, with the second and third, it sounds like you had some freedom to establish a lot of this automation and make it as easy as possible for developers. What was your first job? Like you said, you were very, oh, focused narrowly in that job.

David Kirk:

Yeah. So that was much more, um, that was a company that had, whereas this company that I'm working at now and my previous. All of their stuff was running in the cloud. Um, my first company was a mixture of some stuff running on the cloud and then some stuff running inside of data centers that customers owned. Um, and so the practices around that are quite different. Um, we had like a two or three week release cadence, whereas, so like every you'd only push out changes every two or three weeks. Whereas at my previous company, Where you're pushing out 10 changes a day. Um, so, uh, it was much, much, much more narrow. My first project actually, which was kind of nuts for like a first project was we were moving the whole company from, uh, mercury, like the version control system over to GI. Um, just because like GI is industry standard. Uh, and I think it's better. Get's my favorite piece of software. Uh, and yeah, so one of my first projects was building some tools. Convert repos, working with individual teams to convert repos and start doing trial runs and proofs of concept, and then propagating those changes to the rest of the company and also designing, uh, educational, like materials and doing like talks with, I, I, I had every single developer I was in my first, like, I think I was maybe in my third. in my career. Uh, and I had every single developer across 250 developers come into a classroom where I was teaching people, uh, the basis of how to use Git. And let me tell you, it's really awkward to be there in front of someone and not know how to close out a VI. Uh, when you have guys who are just like two cool for school, like mid thirties, lead architects or whatever, uh, it was very embarrassing, but also really it was cool. It was really, really cool.

Don Hansen:

That's an interesting experience.

David Kirk:

Okay. Mm. So it was lots of projects like that. I mean, another one that I did, I wrote the LA logic to, uh, create version numbers or like to iterate version numbers there. Uh, so there was a while where every version number came from this guy, at least with that company. And then there was another one where, uh, and this was like mine it's it's it was even more boring to work on than it is to hear described. But. Ironing out the way that we referenced other pieces of code. We had like six different solutions. We had a like 550 something different project files across like three different languages. We have two versions of node JS running in there, and people didn't have any consistent way of referencing code. So we had to write code. To do graph theory, style analysis on how everyone is referencing code, build rules to analyze that and then make it so that whenever someone pushed code, if they didn't follow those rules, it would break their build and re prevent them from being able to merge that code.

Don Hansen:

What do you mean referencing code?

David Kirk:

Um, so like, uh, if you are trying to do something more advanced with your code than like, if you don't wanna have to write out, like, if you're trying to interact with GitHub or like, if you're trying to in like calculate the square root of a number, you don't want to have to rewrite the code. To calculate that square root or interact with GitHub every single time you wanna do that. So you'll define, uh, your code to do that thing in a file. And then in other places where you want to do that thing, these other places will point to that file and then use the function to find in that file. So instead of writing my square root function all over the place, I'll just reference one that I already wrote over here. People were doing that in an inconsistent way, which is insane.

Don Hansen:

Got, yeah. So you, you can do so maybe this is my ignorance. You can do that with languages.

David Kirk:

I guess I think that like, it was like, it was all, uh, visual basic and C plus plus and C sharp that would like, you know, the outputs of those things would be, I don't know if they were referencing cross language, but even in like, even within C sharp, there were just like, there was no consistency to how they were referencing things, which is like such a niche. Thing. So I, I would say that like that project is a really good indicator of like the types of things that you could potentially expect to be doing at a large company. Because like, once you get to the point of having, you know, if you only have. 10 20, 30 engineers. It doesn't really matter if you're referencing things inconsistently. Like it's gonna suck down the road, but at least at this point in time, it doesn't really matter when you have 250 engineers and 10 million lines of code, uh, then it really starts to matter because while your build doesn't work, unless you run the build in visual studio and then on your command line and then visual studio again, and like you start getting weird quirks like that, that just make it harder and harder for development to be done.

Don Hansen:

That was actually a focus of ours on with my second company, we had a team of like 12 engineers and that was actually really important to us. Then I almost wouldn't wanna work in an environment where a lot of people are writing very similar functions that kind of just do the same thing. That seems chaotic so

David Kirk:

good for you. Yeah. Yeah. It's definitely something that you wanna squash, uh, in the bud or whatever, if

Don Hansen:

you. Okay. Um, interesting. So definitely different projects, somewhat unique. Um, I didn't think even DevOps would focus on creating a lot of those, um, conventions or reusable functions or organizing that in general. That's interesting. What I kind of wanna get a feel for like what you love about the job and what you hate. Let's start with what you love.

David Kirk:

It's really, uh, I'm definitely the type of person that will get really passionate and into something for a month or two at a time, and then be bored with it over the it'll take a day or two for me to become immensely bored with it. Uh, and I really like DevOps because there are just. There's always so much to do. Uh, and when you do a lot of the things that you can do can really make a big difference in the life of the developers of the company. Um, and like, my job is to make all of my coworkers lives easier, which is a really satisfying thing to do. Um, and yeah, there's like just always interesting things to be working on. And there are so many things that you have to consider beyond. Like there, you know, you have to consider, how am I gonna write documentation for this? How is this gonna be maintained in the long run when I'm building workflows? I just got out of an issue where one of our, uh, earlier today, one of our senior developers. Was using the wrong command to try to deploy to production because the deploy to staging is deploy staging. And then the deploy to production is promote staging. Because like, to me, in my mind, I thought that that distinction makes sense, but it only makes sense because that's the model that I have in my brain. And so it's a really interesting thing of like, figuring out not only how do I build these things, but also how do I design the UX so that people can effectively use these tools that I'm. So it's a lot of interesting challenge.

Don Hansen:

So you're focused on the UX of your development team.

David Kirk:

Yeah. Uhhuh . Yeah. That's interesting. What I biggest it's concerns. Yeah. Yeah. Yeah. And it's the type of thing where like it's, I was, I was even talking with, uh, the other people on my team right before this, where it's like, it's an interesting thing, because like, it's kind of frustrating to see your tools get used wrong, especially if you've written documentation. And if you explained how to use them and all this. But like the lead engineer at my first company, the lead DevOps engineer, my first company, I, I, I built some tools. Like I had mentioned earlier to help with the transition from mercial to get, and those tools weren't being used correctly. And people were coming to question coming with a, coming to us with questions that I had already answered a hundred times before I was complaining to this lead engineer. And I was like, dude, Adam, this sucks. Why don't these developers pay attention and use my tools, right? I've written all these great tools. I've written this great documentation. And he was like, David hold. All these people are professionals that have been working in this industry for a long time. They're all smart people. If you're building a tool and everyone is using it wrong, you built the tool wrong. And like, it makes so much sense. And you know, like it kind of sucks that this tool isn't getting used. Right. But also people have so many things that they need to be focusing on. So if the tool's getting used wrong consistently, then I need to improve the tool. And like, it's an interesting thing of like, you know, those challenges. Uh, I really.

Don Hansen:

If it makes you feel better, the number of conversations developers have had, I built this feature for these users. It solves their problem. Mm-hmm why aren't they using it? Right. They're still complaining that it's not solved. So that just kind of flows down the pipeline, the people

David Kirk:

complaint. Yeah, yeah, yeah. You know, you go onto the OnRamp to get on the highway and you see the ramp meter and people are zooming, right. By not knowing that it's gonna make their lives better for everyone. If they don't. . Yeah. There's only so much that you can do pick that's true metals.

Don Hansen:

Yeah, I like that. So what do you hate

David Kirk:

or dislike? Uh, that people don't read my documentation and use all my tools wrong. Uh, I mean, I would say, uh, a lot of this stuff is pretty cutting edge, um, or at least like a lot of the stuff is new. And so the. I mean, the tools are constantly changing. We're running into some issues now where all of our laptops are moving from where we all, we all use MacBooks and apple has switched from using Intel CPUs to AR M CPUs, well, their own internal Silicon, and that's a different architecture. And some of the Terraform things that we use aren't compiled for a RM. So now we have to spin up an EC two instance that has Intel and like. I'm using a bunch of, uh, like niche, very specific technical terms. I'm doing so to illustrate that, like, that's the very frustrating thing is you run into all of these really weird edge cases and you will spend, I've spent literal weeks of my life trying to figure out. And I'm sure that, you know, this is something that exists for all developers. Uh, Bad documentation and whatnot. But yeah, it it's really frustrating when you're trying to write some Terraform and figure out, Ooh, just where you need the escapes and the quotes and the right dollar signs in the right places. And like, it takes 20 minutes to apply because you thought you were being so clever back when you started at this job and you threw everything into the same Terraform repo, but now it takes 20 minutes to update it because, Hey, guess what? Everything's in the same thefor refill. So it needs to scan through everything. So it's. Just bad documentation, using new tools, having all these cool ideas of things that you wanna do. And then things not really working, right? Like we have this one tool called telepresence that we use to have developers connect their machines, do the Kubernetes clusters to make it easier for them to do development. It is an incredible tool that has really let us do some like really, really, really cool stuff. Uh, but that tool. The network connection drops randomly, and it doesn't provide any error logs as to why it does it. There aren't any error logs on the client on the, on the, on the user's computer. There aren't any error logs, the freaking server. It just dies sometimes, but it doesn't do it when I'm doing it just on my own, on my server. So, you know, it's the type of thing where we've had. We've been struggling with this thing for four months. And we don't know, we've tried out all these different solutions, but there's just no clear answers. So you, you get in here and you get a lot of things where you don't have any clear answers. That can

Don Hansen:

be frustrating. Yeah. Yeah. When, when you deal, so you were essentially dealing with, um, the actual CPU changes, architecture changes. Is that more of all of a sudden, a lot of your tools aren't optimized for that architecture or just flat out don't work?

David Kirk:

Um, it literally does not work. It literally will not run on. Yeah, we. There's thankfully there's only one chunk of infrastructure that needs to be deployed from our machines, because like, this is a danger. If you are having mission critical infrastructure that has to be deployed from someone's machine. Well, what if you need to lay that person off? What if they get hit by bus? What if their machine, uh, you know, what, if they go down to the ocean and think. Laptop Frisbee is a fun thing to do. Like you don't want that to happen. So thankfully there's only one thing, but it also is dangerous because I'm the only one on my team that has an X 86 processor. So I'm the only one that can do those things and yeah, that's just like, uh, spooky. It's very spooky.

Don Hansen:

Very spooky. Okay. Yeah. What are, so I guess for people that kind of wanna identify different types of dev positions, Um, this is a general question. You can help me narrow it there. It sounds like there are different types of dev positions. Right? How can some, I guess we'll do this. How can someone identify that DevOps is for them? What kind of things should they be playing around with and get excited about and what, what kind of positions would that lead into?

David Kirk:

Um, I think that, uh, I think that you need to have like, already. Hmm. Well, let me start by breaking it sort of down into like two different major categories of DevOps that I would consider, like cuz companies use this term all over the place. And really what a DevOps position is to a company. It differs quite a bit. So you'll have DevOps positions at large companies where you're working on that more narrow stuff. Um, and like way more specific things and you're not architecting development pipelines, or maybe not even necessarily creating workflows, but just updating and bug fixing the workflows. Uh, and then you'll have DevOps positions where yeah. You are working in a smaller company and you're building a much, much, much wider range of things. I would say for the former, um, like, well, I would say that in general, for DevOps, you just have to, uh, I have a passion for being efficiently, lazy, or effectively lazy. Like it really is just about identifying the biggest issues and the places where with the least effort you can make life easier for people or make it easier to do something or safer to do some sort of work. Um, I would say that for. Those larger positions. I mean, in general, if you find like the cloud, interesting, uh, and you find the idea of working with servers in the cloud just naturally interesting, then it's definitely a worthwhile thing to, uh, Get into, like, I just think that it's freaking cool. Our, our infrastructure. I can hit a button to scale up one of our services to like a hundred X and then it'll automatically spin up a bunch of servers to support that. And I just think that's really cool. Um, if you want to, I would say that for smaller companies, Uh, you'd need to already sort of have like an understanding of how at least like a low level understanding of how the software development process works, uh, or at least I guess, a high level understanding of how software development process works and sort of like how you would want to be deploying software. And if you find yourself doing. If you find yourself writing code on your machine and running tests, running your linter pushing code up to GitHub and thinking, wow, I, this thing, every time that I run this command, it's really annoying that I have to run these next couple of commands and you are interested in the possibility of how to make it. So you just run one command and then it automatically figures out what to do from there. Uh, I would say that. Probably a worthwhile field to at least start looking at, if you play around with Docker, if you find Docker cool. If you find Kubernetes, conceptually cool Terraform, I would say that those are some of the really big things, but the also, you know, it's sort of the hard part as well as that, um, like to get deep experience with this, you need to sort of be at an organization that's already sort of doing it. I think that this is a really hard field to break into. at a small company, like you are much, much more likely to be able to break into DevOps at a larger company or at least one that already has a DevOps team, uh, existing. So

Don Hansen:

if I, okay. So I guess I see a lot of senior, well, not senior engineers, backend engineers to kind of. Start leaning into that a bit more and start automating a lot more for the backend team. Do you feel like someone that's a backend developer can naturally progress into DevOps if they join another company and their current company, doesn't give them that opportunity.

David Kirk:

Yeah, I would say that, uh, the best example in my career that I've seen of someone breaking into DevOps was, uh, the dude who joined me at my previous company, it was just me on the team. And then we went looking to hire someone and this guy rules, it's one of the best engineers that I've ever worked with, but his progression was, uh, He worked as a bank teller and then, uh, didn't like that and got into it and was basically just like doing it admin or like CIS admin type work and was reading about like, you know, was getting frustrated with the things at his job that could be more efficient and could be automated and could be done in a more reliable way and was learning about those things on his own and trying to implement them at his company on his own. But his company wouldn't really let him. And that is a really. If, if you wanna get a DevOps job and you are interviewing with a team that already exists, and you say, I was trying to implement these things, I know how to do it. It would make things so much better. And it's so frustrating that they wouldn't let me, there's nothing that we like to hear more or nothing that would like to hear more. Yeah. Someone who wants to be proactive and figure out how to make things better. And just like intuitively understands this process that we're doing. It's always the same every time or like this could easily be automated. Um, yeah, I would say that's one of the, one of the better ways to break in is just gaining that experience, automating thing and pushing your company to let you automate things and having good ideas, uh, around how to do it. That's interesting research. Yeah,

Don Hansen:

it sounds like it's tougher to get. If you haven't even landed a dev role yet, if you haven't really gotten that experience on a team and make pretty much identified a lot of the problems that could be solved by automating or making the flow a little bit easier. Do you think honestly, and be candid about this? Do you think there's a chance that aspiring developers that haven't gotten tech yet could do that?

David Kirk:

I th I think that, uh, getting into a, I think that you'd be out of. Depth at a smaller company that I think if you only, if you have a much smaller team, if you're the only person, uh, if you would be the only person on the DevOps team, you're gonna be out of your depth, just because you don't know necessarily what a professional software organization would want to be building. But if you are a new developer and like, you've not gotten a dev job yet, but you do know how to do software development on your own. Um, and you do. Like if you're working as a, if you're doing hobby development and you can understand. Some of the software development workflows, like take the time to go watch some videos on how Docker works. If you can understand, take the time to figure out how Docker works, understand layers, get to the point where you can intuitively understand how file system deltas. And I'm gonna use technical THS here because like, once you understand what these terms that I'm saying mean, then you can go to companies and try to flex and be. Listen, I know the basics. Let me into a junior DevOps role. If you can understand how like file system Delta's work layer caching works like the basics of how Terraform work and, uh, start playing around with Terraform that you can do free tier stuff with like, I think digital ocean is probably the easiest bet. If you wanna play around with Terraform, digital ocean is probably going to be your best bet for at least like deploy a little server. You know, if you can do the path of. I push to a GitHub repo, which initiates a GitHub action, which builds my Docker image from the code that I pushed, pushes that up to Docker hub and then digital ocean spins up a server and deploys that image to that server. If you can do all those steps, which I don't think is like here I am sitting here with seven years experience, but I don't think is like really incredibly difficult to. Do it's something that if you have no tech experience, no programming experience will be difficult to do. But if you have a decent amount programming experience, you can crack that code in like two weeks, probably, uh, at least the very basics. And then if you can go to a DevOps position and say, Hey, I like I've done all of this stuff, then, you know, you've proved out enough that you can figure things out on your own and you can work with the tools that are commonly used in the most basic. If, if I had a junior developer, if we were looking for a junior developer and they were able to show me that they had done all that, I would immediately, I, I would leave that meeting and say, we need to hire this person because it's, it's really hard to find people that can do that.

Don Hansen:

Yeah. I think that gives people actually a fairly helpful outline. And I think just looking at the Terraform website, I think if your project is open source, it is free. Am I correct?

David Kirk:

Saying. Uh, Terraform the tool itself is free. That's a Terraform cloud that they're talking about. I would recommend just staying away from Terraform cloud. Honestly, if you're just working on your own private project, don't even necessarily worry about Terraform, remote state management, just run it all locally. Uh, and at the very least like, you know, you can also, Ooh, here's a way to be lazy and then score bonus points in the interview, which is a very DevOps thing to do. Yeah, you can, in that interview, say, I know that this state should have been saved remotely, but I just wanted to figure out how to get it to work and then I'll be like, oh, hell yeah, going for a little spike, little POC. Ooh, love it. That's what I'm talking about.

Don Hansen:

Yeah. Okay. That's that's pretty cool. I don't think I've ever had anyone outline that for me to even understand. I think, I think what you're describing is fairly easy to achieve, especially if that interests you. So. For me. Um, I started leaning more on the front end route. I'm finding that I really love backend and the further, I, I mean, even just some of the problems that we were experiencing when we were managing a lot of big data, kind of poke in with questions and try to figure out how a lot of this is being optimized. This is super interesting, and I've always been fascinated with creating my own pipeline and creating, spinning up a testing environment and something that QA could test in. Um, I didn't, I wasn't a huge fan of Docker just because dealing with Docker with multiple operating systems, I just didn't play with it enough to be able to like, Deal with that,

David Kirk:

but oh no. Yeah. That stuff is so gross. I don't even use my windows computer for programming anymore. Yeah. Oh really? I don't even play with it. Yeah. Yeah. Okay. Well,

Don Hansen:

that's a little bit of a relief, but that, that is really interesting. I'm fascinated by creating a lot of automations and I feel like, you know, sometimes. when aspiring developers are trying to become developers for like 99% of people, it's like build projects. What do you wanna build? What do you wanna create? Um, think about like even your old industry, could you have used better software? What would that have looked like? Build it. Right. And so a lot of people struggle with this concept of trying to figure out a project, but I do think it's a skill that you can build up, but there are a few people. that don't want to build some random project and think about a user for it. Some people wanna build developer tools. Some people want to just write tons of tests and just like they get this, um, I don't know, comfort and just having more confidence that like a lot of this code is going to continue to run just as it is. And some people like spitting up a, a, a test instance and being able to toss their code on the cloud and test it out. And then, you know, They are ready, you know, they do emerge and it automatically will build to the server, et cetera. Like they, they kind of just like creating a little bit more of it automations with that pipeline and that build. I think, I think this is kind of an interesting path and it sounds like it's gonna be very challenging for someone that doesn't really have a lot of, uh, professional tech experience. But if they have that fascination for it and they explore these tools and they get it up and running, even if it, they don't, you know, hop onto the pricing model for Terraform cloud, you had mentioned an alternative,

David Kirk:

um, oh yeah. You just run Terraform locally. Okay.

Don Hansen:

So it sounds like it could be an option if you're really fascinated by it. Um, I'd be curious. I think I'm gonna start asking people because they ask me, how did they get into DevOps? I'm gonna start asking why I wanna kind of feel why they wanna get into DevOps over traditional software engineering. Um, I dunno, I'm just thinking out loud, but that's super helpful. Yeah, it is for sure. For sure. Do you feel like you,

David Kirk:

yeah, go ahead. It's a, it. It's a weird niche. I find as well that, uh, most developers say that they they're like, man, thank you for doing that DevOps stuff. Cuz it's a bunch of stuff that I would never want to do. And interestingly enough, when I was like in high school and college and looking at software job postings, cuz I was a cool kid, uh, and mostly just very curious, like I would see build engineering roles and this sort of stuff and think like, wow, that sounds miserable. I do not wanna do that. And here I am having done it for seven years. Uh, but yeah. It's a lot of stuff that is sort of weird and it doesn't really fall in line with the classic dev projects, but it, it it's just like, man, it's so interesting. And it's also just so satisfying when you see every single developer at your company, having their jobs be easier because of tools that you've built. Um, yeah, it, it rules and you just get to work with cool stuff. I just have, I'm like responsible. Like $40,000 a month of spending. This is a lot of money, but it's basically, I just, it's just a number now, uh, sort of, but I also get to spin up a bunch of really cool servers and do all this cool stuff. Yeah. It's, it's pretty fun. I dig it. That's really

Don Hansen:

cool. I, um, So talking with here's something I'm gonna challenge you with talking with a, uh, someone that was in DevOps. He's a senior back en engineer. And he, he kind of just worked with the stack that we've been working with for a very long time. And he was that person that wanted to make it a lot easier for the team and create a lot of automations. He moved into the DevOps role, but he also expressed a concern that his job, he didn't feel super secure about his job because when he built a lot of this. He finished it essentially, and the team was happy with it and he actually wasn't sure what to do next. And he was insecure about that. Can you talk about

David Kirk:

that a bit? Yeah, I have been there. Uh I actually did get, uh, laid off from my previous company because they COVID, they're hitting hard times, uh, and DevOps engineers are expensive and so they just. Cut it down to one. Um, so I, uh, understand the, uh, concern. I would say that like, you know, I think that it's mostly about continuing to look for what is the next opportunity to. Optimize things and make things more stable and easier for developers to do, like going and interviewing your setting aside time to interfere your developers and asking them what are the frustrating things? Honestly, this is something that I've always been too busy with too many projects to do, but this is something that I've really think it would be a very worthwhile thing to do. And, and, and something that anytime I've done, it has been beneficial, which is like, go do development, go, you know, Hey, this is a slow week for me. This is a slow month for me. I'm gonna go join one of the feature teams and firsthand do development so that I can firsthand see, so you can eat your own dog food mm-hmm and see what's bad. And, uh, and then, you know, go from there and hopefully have a bunch of ideas around, uh, how to, how to improve things from there. I like that go to conferences as well. That's a really big thing. Um, yeah. Also another thing, if you are a new developer and you think DevOps would be an interesting thing to break into, get your company, to send you to conferences. Also just general advice for every developer, get your company to send you to conferences, look for ones in your city. I've learned. So, so, so much just from like, you know, it's like a 40 minute talk that then just changes the way that you. Software development. I think especially earlier on in your career, it's really important to do. And if you can get your company to send you to a DevOps conference or even a more generic conference that does have some DevOps tracks, that's a great way to really start to learn some meaty stuff. And then you can go and talk to, I spoke, uh, for my first time at a conference like a month or two ago. And speaking from personal experience, the people up in. Talking, they're there to talk to everyone. So if you wanna go talk to them right after, I mean, they're there to talk to people like I, I was flattered and excited by everyone that wanted to hear more information about the things than I had to say. So yeah, go to conferences, talk to those people. And also if you're, uh, not yet a developer and you don't have a company that will cover the expensive conference tickets, look for tech meetups in your town and see if there are DevOps tech meetups. Cause you can go there and talk to people in person, uh, as. Those were very helpful for me.

Don Hansen:

Yeah. I like that. That's really good advice. If someone wanted to dive into this, they wanted to learn these tools or even, um, I mean, even get into software engineering and build things that would eventually kind of transition into more of the DevOps area. Do you have any courses or cutting boot camps, et cetera, that you would recommend.

David Kirk:

Um, unfortunately not, uh,

Don Hansen:

not, did you read a lot of API documentation to learn a lot of these

David Kirk:

tools? Yes. And Terraform, thankfully has the best documentation I've seen from anything. Uh, there are definitely some issues, but in general, the Terraform website has incredible documentation. Um, yeah, I'm very much a. look at docs, but also primarily just find examples of how other people have done things and then play around with them until I can do the thing that I wanna do. And then I'm a, I'm a big fan of the pattern of look for someone else having done it before. Ideally take that, do it the way that I wanna do it messy, and then take what I've done and refactor it to be clean. Uh, and nice. And honestly like, yeah, there, there are. Some good DevOps tutorials out there. Probably I've not really done too many, but I mean, it, it really is the type of thing where like I would say, like, yeah, pick a specific thing that you wanna do, like figure out if you Google, uh, deploy static web server with Terra. And then like digital ocean or AWS, or like deploy, probably the easiest thing to do the easiest first Terraform thing that you can do where you can actually go in your web browser and go to something just Google, uh, Terraform S three, which is an AWS service for static file hosting, Google Terraform, S3, host static. And you will almost certainly be able to find a guide for how to write Terraform, to create an S3 bucket and a URL that you can hit and then how to upload an HTML file in there. And then Bing bang, boom, you got yourself a little website and you've written some Terraform and you have been created a website and honestly, a more responsible way than 90% of websites that exist out there. So, you know, you can pat yourself on the back.

Don Hansen:

I like that. Yeah. It, it feels like this profession, this area, a lot of people that get into into DevOps are just curious. People that wanna make things more efficient and they're resourceful. And I feel like this almost helps a lot of people that do really dive deep into the self-taught route and they figure things out. I feel like those people have the potential. If they have the interest. To dive into DevOps a little bit more. Cause I haven't really heard of any like strong coding, boot camps around this, or people coming out of CS degrees, like going into it directly for DevOps. It feels like it's something you kind of piece together.

David Kirk:

Yeah. I think the hard thing is that DevOps is just such a poorly defined term and there's so much to, you know, what companies are going to expect of you that like you can't really expect to be taught DevOps. In a Cho or a bootcamp, just because it is, you know, people don't even know what they're saying when they say disrupts So like, it really is a thing where I would recommend Googling tutorials for specific things, and then figuring out how to chain those things together. Like GitHub actions, it's just running. Command line commands. Don't use the built-in actions as much as you can only use them. Occasionally I'm not a big fan of built-in actions for a bunch of reasons, but mostly because I think like it's way easier to just read someone's shell command and then a little bash file there. Anyway, uh, GitHub actions just run commands on a server. So like if you're running commands to build a Docker image on your machine, or you're running commands to deploy something to Docker hub on your machine, well then think like, okay, cool. What are the commands that I'd. If I was in a server to do this, which are the same commands you would run on your local machine because you're local machines, a computer. And so is the server. And then you write a GI up action to automate those steps. And so like a lot of this automation for CI is basically just figuring out what are the discreet steps that I wanna run and then how do I chain those together? And a lot of the experience with DevOps is just like, and a lot of the knowledge that you gain. You have the foundation of how to tie things together. And then the experience comes from, okay, now I know nuanced things about AWSs or like now I know about how to deploy a Kubernetes cluster to digital ocean, or now I know how to deploy, you know, all the different little components are the things that you'll learn over time, but at least for a new DevOps engineer, what we really, really, really wanna see is a fundamental understanding. I, I need to chain things together and here's the basic concept around how to do it. And then most importantly, if you don't know how to do something, Google it and, you know, try to figure it out. And then if you can't figure it out, ask someone that's really what I'm looking for in a new DevOps engineer.

Don Hansen:

I like that. I feel like you, you did an excellent job at. Really articulating your mindset about how you even approach problems and even just sharing and exposing a lot of your curiosity and how essentially you just wanted to make things just a little bit better. And like that is kind of your mindset as well. You wanna help the team out? You wanna make your. Um, essentially the pipeline of the process, a lot better for your other teammates. And it, it, it evolved into you diving a little bit deeper into DevOps and solidifying that career track for you. But like, I feel like I've heard what you've said. From a few different DevOps. It actually sounds pretty similar, different responsibilities, pretty similar mindset. And, um, I just wanted to bring that onto the podcast. So I'm essentially saying you were very articulate and you did a good job

David Kirk:

with it. So thank you. I appreciate that. I've honestly been struggling to explain a lot of these concepts, uh, For basically all my career. So I'm glad, I'm glad it could happen here. And thanks for, uh, guiding me with the good questions to be able to, uh, elaborate. Yeah. Hopefully people find this helpful. I mean, I, I love the field. We also really need DevOps engineers, bad. Uh, we really, really do. It's impossible to hire it's so, so, so difficult to hire engineers. Um, and so like if automating these things is something that you find interesting and you can. Get that real basic GitHub action running so that Ooh, if you could, Ugh. Yeah. So that you can push code and then have it deployed to that S3 bucket. I mean, like having people that you can add to your team that understand that basics and then have the curiosity to learn more. Yeah. I, I hope people have found this helpful because it's, it's such a great field. We need a lot more people and like, it pays really well and you get to work on interesting and cutting edge things and like, yeah, it's a good path to go down. So if, if anyone finds this stuff to be interesting, I'd highly recommend, uh, diving into it. Cuz it's really fun. You get to work on cool stuff.

Don Hansen:

That's really cool. Yeah. I'm glad you shared all this. I didn't even know. DevOps was starving for DevOps engineers, so, so hard. It's so hard.

David Kirk:

okay. Good to know. We, we were looking for four months before we found someone like it's really, really difficult. Yeah.

Don Hansen:

Okay. Gives, um, People a little perspective with that. I just realized we got a couple minutes left, so let's go ahead and wrap this up. Um, this is all super helpful. And if you're watching on YouTube, definitely. If you have questions, anything like that, leave it in the comments or you wanna, um, if I can do more or bring more people from DevOps on to have more conversations about this, if this is helpful, let me know, disagree with anything. Let me know in the comments. But, um, David, if people wanna reach out to you in anything else you wanna shout out, where could they reach you?

David Kirk:

Uh, LinkedIn is probably the best place. Uh, I believe I'm David Kirk Jr. On that David Kirks. My father, uh, don't contact him. I mean, unless you wanna talk, he's a nice guy. Uh, but he's a sales guy, so not too much dev ops help. Uh, yeah. Search for David Kirk, Jr. Uh, and search the network NTW R K. If you need to filter it down further and you should be able to find me, feel free to contact me on LinkedIn. Like I love talking about this stuff. Yeah. I was helped by a bunch of people to get to the point that I'm at now. And I'm very happy to, uh, pass the favor along. So, yeah. Please feel free to reach out on LinkedIn. Uh, if you are going to be at the AWS conference in Chicago on August 25th, I'll be there. So please come share. Be sure to watch my talk about how to make Docker image build faster. And, uh, if you like NASCAR, I have a podcast called, uh, the big one podcast. So be, come be our 13th listener, please. That's awesome.

Don Hansen:

I love meeting other podcasters. That's really cool. Yeah. Okay. I think that's it. I think that's all my questions. Um, let me know if you found this helpful, but, um, you know, David, like I said, stick around for a couple minutes, but thanks so much

David Kirk:

for coming out. We just, yeah. Thank you very much. Everything.