Derek: 0:00

A lot of the stuff that we did was in the GUI a lot of times, and so once I started learning Linux, I'm kind of like, how do I catch up with these people? Pretty quickly I started learning AWS and then I'm like, all right, now I've got to get to the command line. And I picked up Terraform one day and I was like whoa, that was easy.

William: 0:29

It is 2025. There is a blizzard just raging outside. You know, the governor of Kentucky, andy Brashear, has declared a state of emergency, and Yvonne Sharp couldn't be happier. You were right at home in this type of weather. It's your preferred weather profile, isn't it, yvonne?

Eyvonne: 0:47

That't be happier. You were right at home in this type of weather. It's your preferred weather profile, isn't it, yvonne? That would be an overstatement. I am not a fan of the cold, but what I will say is we woke up this morning and the power was on. So I'm a happy camper. I've got power, internet and some chicken and rice soup on the stove. So no, complaints.

William: 1:03

Yeah, I, I mean for those in kentucky or anywhere around. We haven't. I mean, I haven't seen snow like this. My kids have never seen snow like this and ice. It's been a winter wonderland.

Eyvonne: 1:14

So you have a lot of fun stuff in six to eight inches of snow and then covered by half an inch of ice, which means nobody's going anywhere.

William: 1:23

Yeah, shelter in place, get the hot chocolate and listen to your favorite podcast. And joining us today, hailing from Chicago, illinois, which is equally cold and maybe not as dismal and crazy with the snow and ice, is Derek Morgan. How are you doing today, derek?

Derek: 1:42

Doing pretty well. Thank you, happy to be here. Awesome, how long have you today, derek, doing?

William: 1:45

pretty well. Thank you Happy to be here. Awesome, how long have you been in Chicago?

Derek: 1:49

This was. I moved right before the fund started, January 2020. So I guess that makes, oh wow, half a decade now.

William: 1:59

How are you liking it so far?

Derek: 2:01

I mean, half a decade is not bad for me. To be perfectly honest, it's not too bad overall. I'd say it's kind of got that smaller town feel with a big city atmosphere. So it's a really good mix, depending on which neighborhood you're in. So I can't really complain. The tech industry's pretty good here and the beer scene is fantastic.

William: 2:23

so do you like chicago style pizza?

Derek: 2:27

uh, tavern style there's. I'm not sure if you're familiar with it. Tavern style is a very thin crackery crust that you get at a lot of the bars and pubs around. Uh, the chicago style is something you do with your family about once or twice a year when they visit, check it off the list, take a long nap after and then get back to the normal pizza.

William: 2:49

A long nap is right.

Eyvonne: 2:51

The tavern style, I imagine, has the added benefit of being ready quickly.

Derek: 2:56

It's not 45 minutes in Luma, that's right.

Eyvonne: 3:00

Like those deep dish. Yeah, full of carbs very gluten-y. Yeah. Chicago style pizza, but oh so satisfying. Oh yeah, full of carbs, very gluten-y, yeah, chicago style pizza, but oh so satisfying.

William: 3:08

Oh yeah, pretty good stuff. Yeah, I like Giordano's every once in a while and they've kind of branched out of Chicago so we have one in like Indianapolis, which isn't too far from where I'm at. So every once in a while, mainly for kids' travel sports, we'll hit up Giordano's while we're up there.

William: 3:26

Got to get those calories back right, Exactly so do you want to give us a brief, just kind of a rundown, a background of your career, Like how did you find yourself working in tech in the first place and how did you get to where you are today? You're kind of like a trusted expert in DevOps infrastructure as code and teaching. So how did that happen?

Derek: 3:50

It was kind of a long, erratic story overall, so I'll try to keep it straight to the point. Kind of started out working, I think I got into retail is kind of where it all started. Started getting into tech there and then I started seeing that, you know, retail is not quite what it used to be, and this was years ago. Circuit City was still open. But it started getting to the point where Circuit City was closing down and all of a sudden I realized like that wasn't really the direction I wanted to go. So I hopped into the MCSA books For those that may not know, talking Microsoft way way back when Azure wasn't even a thought and so MCSA, ccna, cisco, got into the networking, got into kind of everything and finally, after a lot of digging and opportunity, opened in Atlanta at a hosting company. So it threw me right to the wolves. I got to experience some nice true DDoS attacks that took down entire regions. I got to kind of play with the real infrastructure and see what the grownups do other than running. I used to run like a small computer store and stuff like that, but once I got into the big boy stuff, that's where it kind of took off.

Derek: 5:04

I started working in hosting or managed consulting after that dealing with very rich people who had very small problems. Then I kind of realized that through all of this I always ended up in one place and that was helping my colleagues. No matter where I was, no matter how big the problem or whatever, I always ended up being the one that my colleagues would come to. I was always the one writing the documentation and I realized that teaching was what I wanted to do. So a lot of you may remember Linux Academy way back when kind of ended up with A Cloud Guru and then ended up with Pluralsight a whole lot of paperwork and mess there, but anyway started working there. That's where I really found my passion. I had to branch off a little bit. After that dealt with manufacturing that was my first big production Kubernetes deployment. That was fun. Did a bunch of manufacturing stuff all of that and then eventually teaching called me back.

Eyvonne: 6:03

So here I am, off all of that and then eventually, teaching called me back. So here I am. I really love how you um, you looked at commonalities in your all of your roles and and really started to examine. You know, where is it that I find myself? What is it that I see is the unique thing that I bring into this situation, and how do I take that and then capitalize on that in the future? I think sometimes folks aren't aren't self-reflective enough to to connect those dots and they miss opportunities to to really shine in their own unique way. So I think that's a cool part of your story.

Derek: 6:40

Yeah, absolutely, and I think you know a little bit of neuro atypicalness kind of leads into that. You know you, sometimes it's not always a choice, it's just kind of flow with whatever makes you happy. And overall teaching made me happy more than grinding till two in the morning on something where a lot of people honestly really enjoy grinding on. That problem Me, that problem is helping someone and where you know, sometimes you like when the lights flicker properly, sometimes you like when the code deploys. I like when somebody sends me a message and says, hey, man, thanks, I really appreciate it. That's helped me get a job, whatever. So you know, overall it's not totally unselfish, but I will say that I'm really happy with my journey so far.

William: 7:27

That's awesome. You said a few things there I thought that were really good and to kind of take and expand on them. So like, as we march into 2025, I can't believe I'm saying that 2025. I can't imagine a better time to like, if you're entering into tech, it's a great time to come into tech, but it is a double edged sword. Oh yeah, there's so many new technologies and there's just there's way too many ways to do things and historically, like going back, things were much more clear, much more defined. But with that clarity also came this rigidity. Is rigidity a word I don't know?

Eyvonne: 8:09

doesn't matter yeah, awesome.

William: 8:11

But you, you typically had to follow like a, a predetermined path with like a particular type of technology with much less room for uh, crossing disciplines, like if you were, if you were going to be a network engineer, you got a net plus and a CCNA and you dug right in. If you wanted to write code, it was usually Java or C++, maybe a comp sci degree, I guess, depending on how far you go back. But I can't help but think and have empathy for folks coming into tech because of the confusion. There's just got to be so much confusion on where to start, like DevOps is cool, cloud is a huge thing and it's always good to maybe learn a programming language and you need to sprinkle Linux throughout all the things. So I guess the question is how is technology and the path to learning technology evolved from this like earlier days of doing things?

Derek: 9:11

You know the foundations are still so, so, so important, and this is something I've learned. It's definitely bit me multiple times where you know you learn this shiny new technology and then all of a sudden you're like, uh-oh, what exactly is this? And it takes you twice as long to learn this technology because you don't understand where it's coming from. You've got words that are derived from old technologies from the 80s that show up, and I know there's actually been a lot of discourse in the education community like should we be using these words that don't have a real world analog anymore? And uh, to use one which and I don't want to start any arguments or anything but you know like, uh, the master, master branch.

Derek: 9:58

Nobody had a clue where that actually came from. You know in like when it first came out, you know talking about whether it was tape masters or whether it was this or that, and there's so many different ways to interpret it that you know, honestly, main just kind of made more sense to everybody, and that's perfectly fine, and I think that happens with a lot of words nowadays. People are like why do you, why are you using this term? And then somebody's like oh, I guess debug is actually a lot more famous one and a more exciting one. You know it's from what I've read.

Eyvonne: 10:30

It's actually getting bugs out of the computer, physical, actual, like roaches pulling them out of mainframes, my favorite example of that and this is not exactly tech, but there are words that stay with us, right and back in the typesetting days when you had, when letters you know physical letters were placed in a press to make newspapers, the capital letters were in a A case that was up high and the small letters were in a case that was down low, and so your capital letters were uppercase and your small letters were lowercase. And that comes from the news printing, typesetting industry. And those words are still with us, even though their original meaning is almost lost to antiquity, except when somebody you know picks up a cool story like that tells it right and there's, there's there's all kinds of history in in tech that way as well.

Eyvonne: 11:35

Right that we keep the names, the, the. You know the kid who saw a floppy disk and asked why you, why somebody 3d printed a save button. Right Like those. Those things happen all the time.

Derek: 11:51

Yeah, no, I that's. That's a huge thing and you know, some of this stuff does build a barrier to entry on the newer technologies and things like that. And it's funny. You know, you bring the new great thing. You know AI it's just a bunch of if statements, right? Or somebody's like oh, I was doing AI what they call machine learning in Excel in the 80s, or I guess not the 80s for Excel, but you know, like a lot of these concepts have been around, oh yeah, there you go.

Derek: 12:23

Lotus Notes everybody's favorite yeah, so a lot of this stuff has been around. Oh yeah, there you go. Lotus notes everybody's favorite yeah, so a lot of this stuff has been around forever. So getting that foundation makes it easier for people to understand the why behind a lot of new technologies, and I'll get a lot of people to kind of head up the stack a little bit.

Derek: 12:40

I've got a lot of people who learn Terraform from me, who come in and they're in my course and they're like, hey, I keep having this problem and I look and it's because they have no idea how to read the output from a bash script that was there. You know, the Terraform stuff kind of makes sense. They learned cloud, they got their cloud practitioner and their AWS associates, they learned all this other stuff. But the second I threw a bash script in there they fell apart.

Derek: 13:06

So I'm trying to make sure that I know to step back and consider those people and if you're trying to get into the industry, make sure you do learn those foundations. You're going to need them and even if you don't use these specific things, the knowledge you gain just from the why of these things and learning what you're solving helps you understand new products a lot faster. So if you want to navigate this crazy landscape of a thousand things, just go and learn what they're based on, and any new thing that comes out is basically going to be the same thing, with different terminology, different UI or a different CLI.

Eyvonne: 13:44

That's great and that begs an interesting question, because this this is something I think about often is is how do you know where, where to start with folks? Because you know you. You could go all the way back to number theory and ones and zeros and vacuum tubes and and things like that that aren't 100% applicable today, or you could go so far the other direction, that there's absolutely no foundation. Do you have any thoughts on how to draw the line and where to really start along the technical evolution curve?

Derek: 14:21

Lots of thoughts but no real solutions. That's a very difficult question and I've definitely had polls on LinkedIn. I've had conversations. I've seen big arguments on interview questions. They're expecting someone who is coming in as a cloud engineer to know some. We'll just say Fortran, just for kicks.

Derek: 14:44

I know that's probably not realistic, but just to really hammer the point home. You know they're asking for things because it scratches that manager's itch, it makes them feel good about what they've done and they must be getting the best engineers. But at the end of the day, is your product really that important that somebody needs to do this type of stuff? Is it really that important that somebody needs to do this type of stuff? Is it really that complicated? And I think a lot of these hiring managers think that their stuff is that much more complicated that they need these 10X engineers who can do stuff from the 80s when in reality somebody who just came out of school or somebody who just got a couple associate certifications and really practiced could do just as well. So it's a little bit of gatekeeping and I don't like that in a lot of ways. So deciding where to start is probably the hardest part, I think.

Derek: 15:37

With AI, especially now, will you always have a calculator in your pocket? No, that's the way they always said it. Now, of course. Well, now we have ai right in front of us that will answer so many of these problems. So should somebody be able to do a one-liner bash script with regex and you know awk and said from from memory maybe not, but debugging it is still very important because ai is not there yet.

William: 16:04

That's such a good, yeah, linux. We've been on a tear with Linux lately, yvonne and I, with a lot of our guests, because it's just such a core skill, like you were just saying earlier, like interpreting that output, but it's everywhere, like when every time I, every time I build a pipeline, I'm doing something with Bash. It seems like it's the glue between all these different things bootstrapping this, doing that, and it's not like it's some huge thousands of lines, elegant piece of code, but it's maybe 30 lines here, 40 lines there, 10 lines there. And understanding the file system, how to mount things, how to use SCP, how to transfer files. Those things are never. I don't know if they're ever going to go away, I use them all the time still and it's just. That's one of those skills that I see is like really just the hierarchical file structure of linux, like file systems aren't understood anymore. It's like oh, I just search a thing and that's how I get to this thing. Well, they're like okay, we missed the file, the file system hierarchy, completely.

Eyvonne: 17:13

You know I, I think about you know when you're talking about where to start, especially when it comes to education, and I think one helpful thing to think through is how do I get somebody to a point where they can do a practical thing? You know, like I, you know how do I help them solve a problem and teach them a thing that is directly applicable. I think you know you need to present some theory and you need to explain things, but I think if you can help people practically solve a problem and then grow out from there like concentric circles, I think that's a really good approach. Years ago my oldest, who's now a software developer there was a bring your kid to work day. I worked from home at the time and so I brought him to work with me. But what I did is I bought a raspberry pie, sat him up in the room with me, sent him a link to a document, gave him all the pieces and basically told him to spend the day to build himself his own video game system. So he took his Raspberry Pi, he loaded the RetroPi OS on it, he downloaded his mods, he deployed them on his Raspberry Pi and at the end of the day he had a working video game system and, and he's a software developer today, you know and, interestingly enough, william, he and I were talking the other day and he was ranting about the fact that people don't know how to use hierarchical file systems anymore. So, um, I've been a success, just so you know, I love that.

Eyvonne: 18:47

And then I took the contrarian position. I was like well, do they really need them, though? Does your average user really need to know how to use a hierarchical file system? Tell me? So we had that conversation. I do agree with you if you're technical, but anyway, I think finding something that folks can practically use and wrap their arms around today and make them productive and then growing from there is an incredibly important strategy, because you can always go back further and there's always more to learn, but if you can solve a problem today, then you can build on that and be productive and then continue to grow then you can build on that and be productive and then continue to grow.

Derek: 19:27

Yeah, I'd say in, file systems are an interesting one. I haven't had to really mount a file system in forever. Most everything I do is in ephemeral boxes. I run GitHub code spaces for almost everything that I have to do. Otherwise I piece it out and throw it somewhere, whether it, whether it's S3 or whether it's, you know it's on serverless thing or a container containers or something that I think still are going to be around forever and you can't just you cannot skip to Kubernetes. You've got to understand how the Docker file system works and how all of that works. Well, you know Docker or any type of container system and that's something you know. It's a black box for a lot of people and when you actually break it apart and see that like a Docker container is just these files and directories spread apart on your computer, it really kind of becomes very interesting and brings the whole Kubernetes ecosystem a lot closer. It makes it make a lot more sense for you. That's something I noticed.

Derek: 20:28

There's that the next one, I think SSH keys Please learn to understand those and file permissions, because that is a nightmare for everybody, I'd say. I would honestly say 90% of the tickets I get on my courses are related to the SSH keys that we use. I would say that actually might be a little low. That's probably. Most of the problems I get is SSH keys and then manipulating the path, like, honestly, can we not fix this somehow? It is just, you know, installing a new binary in Linux is still way too hard for a lot of people, Even for me. I get tripped up sometimes, especially dealing with, like Python, environments and stuff like that. But manipulating the path and permissions on that, permissions on executables, making sure you can run something that, honestly, is where I would I would start is understanding the file system, like you said, and how to get these, these binaries, where they need to go it's funny.

William: 21:34

You said ssh key. So I have a linkedin course with terraform and part of the course is, like you know, we need to get to this ec2 instance and so, like I have the commands and the readme and everything like ssh dash I. Okay, here's the path to where you generated the thing. Okay, now you gotta log into it and that is like again, I got tons of emails and you know, hey, it's not working. Like okay, you're not putting in the path. Okay, where's the Well, where did you generate the key? And it's just this reverse engineering of like okay, this lives in a directory somewhere. You're just pointing that command to that directory, to where this file is, and then oh, it works.

William: 22:15

Now, you know it's one of those misunderstood things. And you're so being a teacher, I mean you're, I guess you're a teacher pretty much by trade now.

William: 22:31

And I teacher, I mean you're, I guess you're a teacher pretty much by trade now and I would say, like a good teacher goes a long way, especially with, I mean, I looking back like I had some really good teachers over the years that kind of inspired me to just be better and, um, you know whether it was in person or in an online class, you know. But what about the teachers, though? You know what inspires the teachers. Um, so you started more than Certified, which I actually went through. You have some free courses on there and it's really good content. No paywall, you don't have to register, you don't have to do anything, you just go in and click Go. But how were you inspired to sort of go off on your own and start this content creation and course journey?

Derek: 23:06

Well, I mean, linux Academy was great. I honestly, when I started my new thing after that, I really just I was burnt out. It does burn you out a pretty good bit, especially doing AWS courses, because one reinvent and everything you've created is useless. Now you know it will brick entire courses. And if you're using the UI then it's even worse because then you have to rerecord because people will complain and absolutely wreck your courses because a button moved. So I think once I had control over this and I was inspired to start again, I hopped on a friend's podcast actually years ago he doesn't have it anymore Hopped on that and a bunch of people said, oh yeah, I remember you from Linux Academy, will you ever do another Terraform course? And I said I guess it sounds like a pretty fun idea. And honestly it caught fire. I did very, very, very well and I created another couple.

Derek: 24:03

I ended up getting a job as a dev rel at another company because, especially after the heart surgery, you know this, this stuff, if there's anything that puts pressure on your heart, it's it's teaching. It's very stressful, especially running it yourself. But you know, once, once I kind of got control over the content, you start to enjoy it a little bit more than having someone over your shoulder yelling at you hey, you have to do this because this one corporation needs it. And you may never get that return, at least the squishy return, the one for where the people message you and say, hey thanks, you're not going to get like that corporation reaching out and be like, hey thanks, you got me a new job, or you're going to get in a lot of trouble, like that corporation reaching out and be like, hey thanks, you got me a new job, or you're going to get in a lot of trouble.

Derek: 24:47

So the idea of like being able to control things and all of that, it also motivated me to come out with my own platform, which I migrated to a new platform which I'm liking a whole lot. It's giving me control to do kind of my own thing. I'm working on a greater now. I'm working on, you know, different lab environments, stuff like that, so trying to expand and some scratching two inches at once. I get to do the teaching but I also get to do the engineering and that's that's really fun. Still doing some hosts, like you know, devrel type stuff for companies on the side, because rent does need to get paid and unfortunately when you're between courses sometimes that money does dip a little bit while you're still trying to figure it out. But overall it's just been so satisfying kind of moving and building this new platform and making a big move to some really cool new stuff.

William: 25:43

That's great. I know that content, you know everybody. You know looking, you know looking back, I had a teacher one time at a vocational school when I was learning. That was in high school still, I think it was net plus. We had a vocational school we could go to and, or no, it was CCNA, I think I can't remember. But anyway, we, we had our books. We came into class there was like I think there was less than 15 of us and teacher comes in and said, hey, stack all your books over there. We never opened them once. He had this gigantic pile of hubs, switches, just junk PCs that had to be put together that we could test with. We just started building from like day one.

William: 26:25

That was like the whole entire year and that was, I mean, I'll always remember this teacher. It was one of the best. I mean that's a really good way for me to learn. But I mean, of course you can't do that virtually and most of the stuff we touch now doesn't have a physical component to it. But what I mean to say is, like most teachers or creators have their own philosophy. You know, when I was learning, doing the linkedin learning stuff, my philosophy, like what I would really try and do, was, you know, revolve, you know make it uh, revolve around, like fundamentals, but also kind of like what yvonne was saying, like solving a real problem, like taking a problem, baking in the fundamentals and then building out the code and doing a thing you know, a real world type scenario. But do you have any sort of guiding principles or philosophies that you try to stand behind? You know that adhere to, you know, when you build, like new learning content yeah, I mean it's called more than certified for a reason.

Derek: 27:22

The idea is, this is not supposed to be like an exam course. In fact, I don't even take the exam before I do it anymore. I used to, but now I actually just I'll read the exam guide and make sure I hit everything, but I don't want to limit myself to, oh, this isn't covered on the exam, so who cares? It's more of a I'm going to make sure I hit everything, no matter what. But that pretty much just, you know really just terraformed that I've done any exam level content for, and part of that is because I do want to just build and, to be perfectly honest, sometimes I do need to dive in a little bit more on some slides and things like that. There are people who do want that intro content and I am sometimes bad because I get so excited about building.

Derek: 28:13

My entire course is built around building something and I managed to squeeze in every topic into an actual project. I try to do minimal like okay, now we've done that, so now delete it, type stuff, because that's certainly something that a lot of people will do. But the idea is that you're going to learn everything that's on that test through an actual project that will deploy and will work, and sometimes that's easier. It's very easy to plan and I hate slides. I would rather jump out of my window than do another slide. So it's actually easier for me to go over code than it is to sit here and try to pile a bunch of information into a slide, but I think sometimes that probably isn't the best route. I do need to do a few more slides and build a few more foundations on this stuff, but overall it's been very successful and a lot of people do my entire course and then go do a practice exam or something somewhere and make sure they're in the right spot, but overall nothing is better than building.

William: 29:15

I love that. I mean a lot of the. I've studied, I've gone through so many cert training material like over the years and never took a lot of the certs like I did it honestly, just for the like hey, my employer provides, like one of my employers like convinced them to actually do purchase seats for linux academy, for the cloud sandboxes and such. And so I had a few teams and we, we didn't stop at our expert, our subject matter expertise area. We were, you know, learning adjacent things. And then once some I mean, there were some folks on on the team that really embraced it, some that were just like I don't, I got to do this, you know.

William: 29:55

But the ones that really embraced it, they took off like I couldn't almost get them to stop, like, hey, you got a day job, you need to set time to do this, you know. And they were just, you know, sucking in all that information. And then it, then it showed in their day-to-day work they were performing better, they had new and better and creative ideas and such. And that's why it's so important. I encourage any big enterprise out there for your training dollars, empower your folks to learn. It's not about just getting a paper cert you want them to provide value and you want them to feel fulfilled in the role that they're doing. It's huge.

Derek: 30:31

I built a lot of those labs, actually A ton of those labs. I did a lot of the backend type, behind the scenes stuff to get a lot of those Linux Academy labs out. So it's the guiding principle for a lot of the stuff that I'm building now. Only I'm doing things slightly different and I haven't released this totally to the public yet. I've hinted it, but I found that in those labs you're missing probably the most important concept involved with learning actually learning real tech stuff, and that is breaking stuff.

Derek: 31:09

A pristine sandbox is never going to teach you what you need all the way through. Because I know God, I'm learning Python, I'll spend more time setting up the Python environment than I will actually on the Python code. Python's easy Environments are hard, and so what I'm actually working on now is a grader, a CLI that you will run on your own system and you'll grade code that you code on your own system. So you keep everything that you write. Everything is all yours. You can expand on it. You can do anything you want. Once you get done with the tasks that you do, you still own the code. So if you want to continue building after the course, you've got it. So the grader will report back to my system. It will say hey look, good job, You've passed. You can now take your code. You don't have to move it off of a lab, you don't have to move it out of a sandbox. You get to keep it exactly where it is.

Eyvonne: 32:05

So so for me, one of the one of the best certification experiences I ever had was, if you remember, the Red Hat Linux certification from years ago and and it's it's been over a decade I'm not going to do the math, but the certification there was a written part of the exam which was around, you know it was simple and you only had to have a 50% pass rate. But then there was also a build and a troubleshoot and they gave you a broken system and you had to go through and resolve it. And I mean I remember even taking the exam. For somebody who had worked in enterprise IT and in troubleshot systems for years. I feel like that part was really pretty straightforward. There were some master boot record things and, and, yeah, some like files in the wrong place and then some permissions issues and stuff like that that you had to troubleshoot. But certainly engaging and then working to fix broken things is a is a very different learning experience.

Derek: 33:04

Absolutely. The RHCSA was the one that I did by them and the first question was eh, whatever, it's already expired, they can come get it. But it was as long as you kind of had heard that somewhere, it was pretty great. But of course expecting someone to memorize that is sometimes that's a little brutal. Overall, but I think that's really the way to go and a lot of people are moving to that. The new Terraform exam is all hands-on.

Derek: 33:47

So I did a poll the other day just talking about how you know we're talking about these older technologies and stuff like that, and it was asking like what is my next content? I can't put food on the table with Terraform for the rest of my life and we can go all day talking about Terraform and OpenTOFU. But I think you've had plenty of guests go down that track on here already. But I think you've had plenty of guests go down that track on here already. So I'm like you know, I've got a Terraform Ansible and Jenkins course which has crushed it just for years, and I'm like you know, maybe I should replace that with GitHub Actions. And then in that I was like, hey, should I replace this or refresh it? And then in that poll, I was also like or should I do DevOps with AI, just to see who's out there DevOps with AI? It just crushed it. It doubled everything else, which kind of blew me away, to be really honest. But I think I can do it in a good way.

Derek: 34:52

Second place was Terraform, ansible and Jenkins these enterprises. Sometimes you just need a sledgehammer to do something, and Jenkins is a sledgehammer. And when you're talking about these enterprises like, oh no, switch to GitHub Actions because it's cool and nice, these guys don't care. They're not going to change up something that's been working for a decade just because something is neater or has, like you know, one extra feature. Jenkins is still very much alive and well. Ansible is very much alive and well, and so I think you know if you you're probably hurting yourself by I'm not saying you need to learn it, but you won't hurt yourself to learn it. If you learn the principles of Jenkins, you're going to be able to use anything.

William: 35:34

Yeah, jenkins is a, I have some. Yeah, it's a mountain. Yeah, there's a lot easier ways to do things, but you're right, they, you know, if you think about every use case and these are kind of like divisive topics actually. So building, I think about every use case and these are kind of like divisive topics actually. So building, I'll just go and like say, like building infrastructure atop, like an sdk with a general purpose language like python or go or type type script, versus using, like these kind of some of the things you said, these infrastructure platforms like ansible, terraform, open tofu, all these, um, my, my case against the former is especially like you were saying enterprise as a company scales.

William: 36:15

You have more hands in that cookie jar. You have more, uh, you know you got these hot shot developers coming in with their creative minds at work. Their wheels are spinning. You know they. They want to do lots of custom things and if you give them the power to, they will, and I can tell from experience this gets out of control very quickly because at the end of the day, you want consistency and the ability to enforce consistency across a large number of teams for the betterment of the business. So kind of what you're saying resonates because Ansible. You know it may not be the best tool on the entire planet for configuring a, an image at build time, installing some packages or doing some things, but you know what most of the folks I've worked with in the past have the ability to pick it up and start using it rather quickly. Same with terraform. It's not going to solve every problem out there, but it is a platform and it helps with that scale and with that maintaining consistency.

Derek: 37:15

I'd say I get a lot of pushback from these hotshot developers.

Derek: 37:20

And not to throw you guys under the bus, but some of these guys come up and like, well, what about this one super niche problem that I encountered at Fortune X hundred company? And it's like there are thousands and thousands and thousands of startups out there that just need to get some stuff out the door. You know, like not everybody needs to go and build something with code and, honestly, the what you said about consistency is the number one thing I chime in on. I say, look, have you ever had to debug somebody's inventive solution? Like no, guess who's going to have more documented solutions out there Probably Terraform for exactly what you're doing. Or OpenTOFU or whatever it's called HCL Probably HCL in tofu, or whatever h. What's called hcl? Probably hcl. Uh, you know, like your weird little hacky java triple nested loop thing probably is not going to be easy to debug five years down the road yeah, and especially if they leave at some point and they were the sort of the keeper of the keys to the logic to that thing.

William: 38:26

oh, oh boy. I mean I guess it's easier nowadays because you can maybe plug it into some AI and figure out what the heck it's doing, but yeah, historically it's been like a no-go.

Derek: 38:37

Maybe why there's so much pushback.

Eyvonne: 38:40

Well, and we're often more impressed with our own cleverness than other people are right.

Eyvonne: 38:46

You know, folks want solutions to problems and, especially if you're a leader in an enterprise, you have to be able to find people to support your environment and it has to be supportable and there are all kinds of requirements and constraints that that, especially in heavily regulated industries um, regulated industries that matter and that the business has to account for. And even if a tool requires a person or even a team, a little bit more effort, it can save effort across the organization in inconsistencies, in portability of code, in training costs, in the ability for folks to move around inside the organization if they're consistent is supportable. That you can find other people to work on, that has support, because so many organizations pay for support to keep their executives out of hot water. Frankly, you know, and and I have a um, a bat phone, you know to pick up and call to, to bring in the cavalry when they need to, and all of those things are objective realities inside of enterprises and it's not just about who can write the most clever recursive function, for example.

Derek: 40:20

Absolutely, I agree. The whole I guess a little less friendly term, throat to choke, is just absolutely huge and that's something when I worked at one of the major tacos.

Derek: 40:35

You know, terraform collaboration softwares, that was something we heard a lot of. Uh is, you know, like people are like, oh, I can build this in github actions and somebody's like, well, we pay you two $200 an hour and we can pay them nowhere near that for a year to help, basically, be there if something goes wrong. To fix all these things you might have to do two hacky things instead of a thousand hacky things, but overall we need you somewhere else, not building GitHub Actions pipelines. But you know, overall we need you somewhere else, not building GitHub Actions pipelines. We need you building the infrastructure, doing actual architecture and making you know, making sure this stuff stays up. The deployment's just a piece of the puzzle. So I think you know the whole build versus buy and I don't even know how we got here. But the build versus buy argument is certainly, you know, an interesting one.

William: 41:31

But I'm seeing a lot of people really opting to buy most of the time. Likewise, yeah, I, I know we're going. I don't know how long we've been on because it reset the timer, but I think we're running up on time. Okay, yeah, I think we are. But I wanted to ask something. I'm just kind of curious. So I had an aha moment.

William: 41:44

Like many years ago I was one of these folks. It was like you know, terraform, this new hipster garbage, get this out of here. So, like I was in like a hot seat basically with what would become like a devops team and I remember like what made it stick for me. So I had written this stuff. I can't remember if it was python, yeah, I think it was python, I can't remember, but I'd written this stuff to deploy this infrastructure and I was like showing them all the you know, all the things we've been talking about. Look at how clever this is. Like, oh, look at me, I wrote this, it's so good.

William: 42:21

And then there was one devops engineer that like put me on blast. He was like okay, how do you, how do you destroy all that? Then and I was like uh, I'm still trying to work that out. And I had all these. Okay, like because you created a, the vpc, you have all these defaults that get created, but then you have to delete them individually and like all this stuff and everything has dependencies. And he's like you know how we do it in terraform destroy. And then it was all gone and I was like, oh snap, this is really cool, this is awesome. And, honestly, ever since then I've been like a huge fan, like terraform is probably one of the like. I used to tend towards general purpose languages, like most of the time, but terraform open tofu either. They are fantastic tools but like what made you like these tools so much? Like what made it stick for you?

Derek: 43:12

um, well, uh, for one thing it was. It was just interesting. I I picked up terraform pretty early in my real devops journey. Now I'd been in you know infrastructure forever, but you know I'm like literally working with Windows machines. A lot of the stuff that we did, powershell was still in its infancy, so a lot of the stuff that we did was in the GUI a lot of times. And so once I started learning Linux, I'm kind of like how do I catch up with these people? Pretty quickly I started learning AWS and then I'm like all right, now I've got to get to the command line. And I picked up Terraform one day and I was like whoa, that was easy, you know. And I played with Bodo a lot and I really tried to be that cool kid who was like I don't need Terraform, check this out. And I'm like what am I doing? You know, terraform is just so much easier.

William: 44:06

Yeah, much easier.

Derek: 44:08

Yeah, it just worked and it was cool and it was early, so I got, you know, scratched that itch. I was one of the earlier adopters of it because I needed to teach it and I taught it and I'll admit I probably didn't use as many best practices as I could for that first course, but you know it worked and I've learned a lot since then. And you know, I definitely see the cracks, I know there are definitely cracks in the language and all of that. But people ask me all the time just use Pulumi, just use SDK, just use this. And I'm not or CDK rather, and I'm just like you know, if it doesn't work for you, that's fine, do it. But for me it makes absolutely no sense to switch to a whole new paradigm for a couple weird edge cases that I can't quite nail down.

William: 45:00

Yeah, and in those cases I'll figure it out.

Derek: 45:03

I'll create a shim if I have to a very readable shim, create a shim if I have to a very readable shim, but I'll create a shim for the little stuff and otherwise Terraform is going to work just fine versus, as we've said, going way off the rails and completely reinventing the wheel, so I love it.

William: 45:19

Do you have anything else, yvonne, before we part ways? No good, awesome. Well, it has been a pleasure talking to you, derek. No good, Awesome. Well, it has been a pleasure talking to you, Derek.

Derek: 45:33

Where can the nice folks out there find you? I'd say, you know, obviously my site, morethancertifiedcom, and LinkedIn, probably the best place to get me. Otherwise, you know, I'm on X, I'm on Blue Sky, but we're still trying to figure all that out. So I think LinkedIn and my site are probably the two best places.