Screaming in the Cloud - Building a Community around Cloud-Native Content with Bret Fisher

Episode Date: September 7, 2023

Bret Fisher, DevOps Dude & Cloud-Native Trainer, joins Corey on Screaming in the Cloud to discuss what it’s like being a practitioner and a content creator in the world of cloud. Bret shares why he feels it’s so critical to get his hands dirty so his content remains relevant, and also how he has to choose where to focus his efforts to grow his community. Corey and Bret discuss the importance of finding the joy in your work, and also the advantages and downfalls of the latest AI advancements. About BretFor 25 years Bret has built and operated distributed systems, and helped over 350,000 people learn dev and ops topics. He's a freelance DevOps and Cloud Native consultant, trainer, speaker, and open source volunteer working from Virginia Beach, USA. Bret's also a Docker Captain and the author of the popular Docker Mastery and Kubernetes Mastery series on Udemy. He hosts a weekly DevOps YouTube Live Show, a container podcast, and runs the popular devops.fan Discord chat server.Links Referenced:Twitter: https://twitter.com/BretFisherYouTube Channel: https://www.youtube.com/@BretFisherWebsite: https://www.bretfisher.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks and stay ahead of unknown threats.

What's Runtime runtime insights, you ask? Visit sysdig.com slash screaming to learn more. That's S-Y-S-D-I-G dot com slash screaming. My thanks as well to Sysdig for sponsoring this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. A little bit off the beaten path today in that I'm talking to someone who, I suppose, like me, if that's not considered to be an insult,

has found themselves eminently unemployable in a quote-unquote real job. My guest today is Brett Fisher, DevOps dude and cloud native trainer. Brett, great to talk to you. What do you do? I'm glad to be here, Corey. I help people for a living, like a lot of us end up doing in tech. But nowadays, it's courses, it's live trainings,

webinars, all that stuff. And then, of course, the fun side of it is the YouTube podcast, hanging out with friends, chatting on the internet. And then a little bit of running a Discord community, which is one of the best places to have a little text chat community if you don't know Discord. I've been trying to get into Discord, and it isn't quite resonating with me just because by default it alerts on everything that happens in any server you're in. And this historically was very challenging to get that tuned in. So I just stopped having anything alert me on my phone, which means now I miss things constantly.

And that's been fun and challenging. I still have the slack.lastweekinaws.com community with a couple thousand people in it. Nice. Yeah, I mean, some people love Slack. I still have a Slack community for my courses. Discord, I feel like is way more communityfriendly. By the way, a good server admin knows how to change those settings, which there's a thousand settings in Discord. So,

server admins, I don't blame you for not seeing that setting. But there is one where you can say, new members, don't bug them on every message, only bug them on mentions or channel mentions and stuff like that. And then, of course, you turn off all those channel mentions and abilities for people to abuse it. But yeah, I had the same problem at first. I did not know what I was doing, and it took years to kind of figure out the community. We now have 15,000 people. We call it cloud-native DevOps, but it's basically people from all walks of DevOps, DevOps, you know, recovering IT pros. And the wonderful thing about it is you always start out, you do the same thing, I'm sure, where you start a podcast or YouTube channel

or a chat community or Telegram or a Reddit subreddit or whatever your thing is, and you try to build a community and you don't know if it's going to work and you invite your friends. And then they show up for a day and then go away. And I've been very lucky and surprised that the Discord server has, to this point, taken on sort of its own nature. We've got, I don't know, close to a dozen moderators now and people that are just volunteering their time to help others.

It's wonderful. I actually consider it like one of the safe places, unlike maybe Stack Overflow, where you might get hated for the wrong question. We try to guide you to a better question so that we can answer you or help you. So every day I go in there and there's a dozen conversations I missed that I wasn't able to keep up with. So it's kind of fun if you're into that thing. I remember the olden days when I was one of the volunteer staff members on the Freenode IRC network before its untimely and awful demise. And I really have come to appreciate the idea of past a certain point,

you can either own the forum that you're working within or you can participate in it. But being a moderator on some level sets apart how people treat you in some strange ways. And none of these things are easy once you get into the nuances of codes of conduct, of people participating in good faith, but also are not doing so constructively.

And people are hard. And one of these years, I should really focus on addressing aspects of that with what I'm focusing on. Yeah, the machines, I mean, as frustrating as the machines are, they at least are a little more reliable. I don't have anonymous machines showing up yet in Discord, although we do get almost daily spammers and stuff like that.

So, you know, I guess I'm blessed to have attracted some of the spam and stuff like that. But a friend of mine who runs a solid community for podcasters, you know, for podcast hosters, he warned me. He's like, you know, if you really want to make it the community that you have the vision for, it requires daily work. Like, it's a part-time job, and you have to put the time in. Or it will just not be that. And be okay with that. Like, be okay with it being a small, you know, small group of people that stick around and doesn't really grow. And that's what's happened on the Slack side of things

is I didn't care and feed it. So it has gotten pretty quiet over there as we've grown the Discord server. Cause I kind of had to choose, you know, cause we, like you, I started with Slack long, long ago. It was the only thing out there. Discord was just for gamers. And in the last four or five years, I think Discord, I think during the pandemic, they officially said, we are now more than gamers, which I was kind of waiting for to really want to invest my company's, I mean, my company of three, you know, my company time into a platform that I thought was maybe just for gamers, couldn't quite figure it out. And once they kind of officially said, yeah, we're for all communities, we're more in, you know, and they have that. The thing I really appreciate,

like we had an IRC, but was mostly human driven, is that Discord, unlike Slack, has actual community controls that make it a safer place, a more inclusive place. And you can actually contact Discord when you have a spammer or someone doing bad things, or you have a server raid where there's a whole bunch of accounts and bot accounts trying to take you down, you can actually reach out to Discord where Slack doesn't have any of that. They don't have a way for you to reach out.

You can't block people or ban them or any of that stuff with Slack. And the lucky thing of this, I kind of look at Discord as like the best new equivalent of IRC, even though for a lot of people, IRC is still the thing, right? We have new clients now.

You can actually have off, you can have a sort of synced IRC, right? Where you can have a web client that remembers you so you didn't lose the chat after you left, which was always the problem back in the day. Oh yeah, I just parked it on originally a hardware box, now EC2. And this ran Ursi as my client,

because I'm old school, inside of Tmox and called it a life. But yeah, I still use that from time to time, but the conversation has moved on. One challenge I've had is that a lot of the people I talk to about billing nuances skew sometimes obviously in the engineering direction, but also in the business user perspective.

And it always felt on some level like it was easier to get business users onto Slack from a community perspective than it was for Discord. I mean, this thing started as well. This was years ago before Discord had a lot of those controls. Might be time to take another bite at that apple. Yeah, yeah, I definitely, and I think that's why I still keep the Slack open, is there are some people, they will only go there, right? Like they just don't want another thing. That totally makes sense. In fact, that's kind of what's happening to the internet now, right?

It would, we see the demise of Twitter or X. We see all these other new clients showing up. And what I've just seen in the dev community is we had this wonderful dev community on Twitter for a moment, for a few years. It wasn't perfect by far. There's a lot of people that still didn't want to use Twitter. But we, I felt like there was,

if you wanted to be in the cloud native community, that was very strong. And you didn't always have to jump into Slack. And then, you know, this billionaire came along and kind of ruined it. So people have fractured over to Mastodon, and we've got some people over on Threads, and some people on Blue Sky. And then some people like me that have stuck with Twitter. And I feel like I've lost a chunk of my friends because I don't want to spend my life on six different platforms. So I have found myself actually sort of regressing to our Discord because it's the people I know. We're all talking about the same things. We all have a common interest.

And rather than spending my time trying to find those people on the socials as much as I used to. So I don't know. We'll see. Something that I have found, I'm curious to find those people on the socials as much as I used to. So I don't know. We'll see. Something that I have found, I'm curious to get your take on this. You've been doing this for roughly twice as long as I have. But what I've been having to teach myself is that I am not necessarily representative of the totality of the audience. And aside from the obvious demographic areas, I learn best by reading

or by building something myself. I don't generally listen to podcasts, which is a weird confession in this forum for me to wind up admitting to. And I don't basically watch videos at all. And it took me a while to realize that not everyone is like me. Those are wildly popular forms of absorbing information. What I have noticed is that the audience engages differently in different areas. Whereas for this podcast, for the first six months, I didn't think that I'd remember to turn the microphone on and that was okay. It was an experiment and I enjoyed doing it. But then I went to a conference and wound up getting a whole bunch of feedback. Whereas for the newsletter, I had immediate responses to basically every issue when I sent it out. And I think the reason is,

is because people are not sitting in front of a computer when they're listening to something and they're not going to be able to say, well, let me give you a piece of my mind in quite the same way. And by the time they remember later, it feels weird like calling into a radio show, but when you actually meet someone, yeah, I love your stuff and they'll talk about the episodes I've had out, but you could be forgiven from,

in some cases from the social media side of it it for thinking that I'd forgotten to publish this thing. Yeah. I think that's actually a pretty common trait. There was a time where I was sort of into the science of learning and whatnot. And one of the things that came out of that was that the way we communicate or the way we learn and then the way the input and the outputs are different per human, it's actually almost like comparable maybe to love languages. If you've read that book where the way we give love and the way we receive love from others is we prefer it in different ways. And it's often not the same thing. And this, I think the same is true of learning and teaching where my teaching style has always been visual. I think

I've almost always been in all my videos. My first course seven years ago, I was in it. I had my head shot in there and I just thought that that was a part of the best way you could make that content. And it doesn't mean that it's instantly better. It just means I wanted to communicate with my hands. Maybe I got a little bit of Italian or French in me or something where I'm moving my hands around a lot. So I think that the medium is very specific to a person. And I meet people all the time that I find out they didn't learn that from me. They didn't learn about me, rather, from my course.

They learned about me from a conference talk because they prefer to watch those. Or someone else learned about me from the podcast I run because they stumbled onto that. And it always surprises me because I always figure that since my biggest audience is in my Udemy courses, over 300,000 people there, that that's how most of the people find me. And it turns out nowadays that when I meet people, a lot of times it's not. It's some other venue. And now we have people showing up in the Discord server from the Discord discovery.

It's kind of a little feature in Discord that allows you to find servers that are on the topics you're interested in. And we're listed in there. And people will find me that way and jump in not knowing that I have created courses. I have a weekly YouTube live show. I have all the other things.

And yeah, it's kind of great. But yeah, it's just, it's kind of great. But also as a content creator, it's kind of exhausting because you, if you're interested in all these things, you can't possibly focus on all of them at the same time. So what is it?

The great Will Smith says, do two things and two things suffer. And that's exactly what my life is like. It's like, I can't focus on one thing. So they all aren't as amazing as they could be like, I can't focus on one thing. So they all aren't as amazing as they could be. Maybe if I had only dedicated to one thing. No, I'm with, I'm with you on that. It's a saying yes to something means inherently saying no to something else. But for those of us whose interests are wide and varied, I find that there are, there are always more things to do

than I will ever be able to address. You have to pick and choose in some level. I dabble with a lot of the stuff that I work on. I have given thought in the past towards putting out video courses or whatnot, but you've done that for ages. And it just seems like it is so much front-loaded work in many cases with things I'm not terrific at. And then at least in my side of the world, oh, then AWS does another console refresh as they tend to sporadically. And great. Now I have to go back and redo all of the video shoots showing how to do it because now it's changed just enough to confuse people. And it feels like a treadmill you climb on top of and never get off of. It can definitely feel like that. And I think it's also harder to edit existing courses like I'm doing now than it is to just make up something brand new and fresh. And there's something about, we love to teach, I think, what we're learning in the

moment. I think a lot of us, you get something exciting and you want to talk about it. And so I think that's how a lot of people's conference talk ideas come up, if you think about it. You're not usually talking about the thing that you were interested in a decade ago. You're talking about the thing you just learned and you thought it was great and you wanted everyone to know about it, which means you're going to make a YouTube video or a blog post or something about it. You'll share somewhere on social media about it. I think it's harder to make this, you know, any of these content creation things, including especially courses, a career. If you come back to that course, like I'm doing seven years after publication, and you're continuing every year to update those

videos and you're thinking, not that my interests have moved on, but my passion is in the new things and I'm not making videos right now on new things. I'm fixing, like you're saying, like I'm fixing the Docker Hub video because it has completely changed in seven years and it doesn't even look the same and all that. So there's definitely, that's the work side of this business where you really have to put the time in and it may not always be fun. So one of the things I'm learning from my business coach is like how to find ways to make some of this stuff fun again and how to inject some joy into it without it feeling like it's just the churn of video after video after video, which you can fall into that trap with any of this stuff. So yeah, that's what I'm doing this year is learning a little bit more about

myself and what I like doing versus what I have to do and trying to make some of it a little funner. This question might come across as passive aggressive or backhandedly insulting, and I swear to you, it is not intended to. But how do you avoid what has been a persistent fear of mine? And that is becoming a talking head. Whereas you've been doing this as a trainer for long enough that you haven't had a quote-unquote real job in roughly, what, 15 years at this point. Yeah. And so you've never run Kubernetes in anger, which is, of course, what we call production environment. That's right.

I call it anger. My staging environment is called theory because it works in theory but not in production. And there you have it. So without being hands-on and running these things at scale, it feels like on some level, if I were to, for example, give up the consulting side of my business and just talk about the pure math that I see and what AWS is putting out there, I feel like I'd pretty quickly lose sight of what actual customer pain looks like. Yeah, that's real fear for sure. And that's why I'm kind of, I think I kind of do what you do. And I maybe wasn't, didn't try to mislead you, but I do consult on a fairly consistent basis. And I took a break this year.

I've only, you know, then what I'll do is I'll do some advisory work. I usually won't put hands on a cluster. I'm usually advising people on how to put the hands on that cluster kind of thing or how to build, accepting their PRs, doing stuff like that. That's what I've done the last,

maybe three or four years. Because you're right. There's two things there, right? Like it's hard to stay relevant if you don't actually get your hands dirty. Your content ends up, I think, just naturally becoming very, I don't know, one-dimensional maybe or two-dimensional

where it doesn't, you don't really talk about the best practices because you don't actually have the scars to prove it. And so I'm always nervous about going long lengths, like three or four years of time with zero production work. So I think I try to fill that with a little bit of advisory, maybe trying to find friends and actually trying to talk with them about their experiences just so I can make sure I'm understanding what they're dealing with. I also think that that kind of work is what creates my stories. So like my latest course, it's on GitHub Actions and Argo CD for using automation and GitOps for deployments,

basically trying to simplify the deployment lifecycle so that you can just get back to worrying about your app and not about how it's deployed and how it's tested and all that. And that all came out of consulting I did for a couple of firms in 2019 and 2020. And I think right into 2021, that's kind of where I started winding them down. And that created the stories that caused me, you know, sort of the scars of going to production. We were migrating a COTS app into a SaaS app. So we were learning lots of things about their design and having to

change infrastructure. And I had so many learnings from that. And one of them was, I really liked GitHub Actions, and it worked well for them. And it was very flexible. And it wasn't as friendly and as gooey, beautiful as some of the other CI solutions out there. But it was flexible enough and direct close enough to the developer that it felt powerful in developers' hands, whereas previous systems that we've all had, like Jenkins, always felt like this black box that maybe one or two people knew. And those stories came out of the real advisory or consultancy that I did for those few years. And then I was like, okay, I've got stuff.

I've learned it. I've done it in the field. I've got the scars. Let me go teach people about it. And I'm probably gonna have to do that again in a few years when I feel like I'm losing touch, like you're saying there. That's, yeah.

So I agree. Same problem. Crap, I was hoping you had some magic silver bullet other than, no, it still gnaws at you forever and there's no real way to get away from it. Great. That keeps things interesting. I would love to say that I have that skill, that ability to just talk with you about your

customers and transfer all that knowledge so that I can then talk about it. But I don't know. I don't know. It's tough. Yeah. The dangerous part there is suddenly you stop having lived experience and start just trusting whoever sounds the most confident, which, of course, brings us to generative AI, which apparently needs to be brought into every conversation as per, you know, analysts and Amazon leadership, apparently. What's your take on it? Yeah. Well, I was early. I mean, well, maybe not early, early. Like, these people that are talking about being early were seven years ago.

So definitely wasn't that early. Yeah, so the back of the Hello World was a PhD from Stanford. Yeah. Yeah. So I was maybe, my first step in was on the tech side of things with Copilot when it was in beta a little over two years ago. We're talking about GitHub Copilot. That was, I think, my first one. Was not an open AI user for any of their solutions and was not into the visual, you know, the image AI stuff, as we all are now dabbling with. But when it comes to, you know, code and YAML and TOML and, you know, the stuff that I deal with every day,

didn't start into it until about two years ago. I think I actually live streamed my first experiences with it with a friend of mine. And I was just using it for DevOps tasks at the time. It was in early beta. So I was kind of invited. And it was filling out YAML for me. It was creating Kubernetes YAML for me. And like we're all learning, it hallucinates, as we say, which is lying. It made stuff up for 50% of the time. And it is way better now. So I think I actually wrote in my newsletter a couple of weeks ago,

a recent story or a recent experience because I wanted to take a project in a language that I had not previously written from scratch in, but maybe I was just slightly familiar with. So I picked Go because everything in cloud native is written in Go.

And so I've been reading it for years and years and years and maybe making small PRs to various things, but never taken on myself to write it from scratch and just create something start to finish for myself. And so I wanted a real project, not something that was contrived. And it came up that I wanted to create,

in my specific scenario, I wanted to take a CSV of all of my students and then take a template certificate. You know how like these certificates of completion or certifications that you get, and it's a nice little, looks like the digital equivalent of a paper certificate that you would get from maybe a university.

And I wanted to create that. So I wanted to do it in bulk. I wanted to give it a stock image and then give it a list of names, and then it would figure out the right place to put all those names and then generate a whole bunch of images that I could send out. And then I could maybe turn this into a web service someday. But I wanted to do this. And I knew if I just wrote it myself, I'd be horrible at it. I would suck at Go. I'd probably have to watch some videos to remember

some of the syntax. I don't know the standard library, so I'd have to figure out which libraries I needed and all that stuff, all the dependencies. You'd make the same typical newcomer mistakes of not understanding the local idioms and whatnot. Oh, yeah. Yeah. And so I'd have to spend some time on Stack Overflow, Googling around. I kind of guessed it was going to take me 20 to 40 hours to make. And we're talking really just hundreds of lines of code at the end of the day, because Go Standard Library actually is really great. So it was going to be far less code than if I had to do it in Node.js or something. Anyway, long story short there, it ended up taking three to three and a half hours end to end, including everything I needed, importing a CSV, sucking in a PNG, outputting PNG with all the names on them

in the right places, in the right font, the right colors, all that stuff. And I did it all through GitHub Copilot Chat, which is their newest labs beta thing. And it brings the chat GPT for experience into VS Code. I think it's right now only for VS Code, but other editors coming soon. And it was kind of wonderful. It remembered my project as a whole. It wasn't just in the file

I was in. There was no copying, pasting back and forth between the web interface of ChatGPT, like a lot of people tend to do today, where they go into ChatGPT, they ask a question, and they copy out code, and they paste it in their editor. Well, there was none of that because since it's built into the editor, it kind of flows naturally into your existing project. You can kind of just click a button and it'll automatically paste in where your cursor is. It does all this convenient stuff. And then it would relook at the code. I would ask it, you know, what are 10 ways to improve this code now that it works? And what, you know, what, how can I reduce the number of lines in this code? Or how

can I make it easier to read? And I was doing all this stuff while I was creating the project. I haven't had anyone like look at it to tell me if it looks good, which I hear you've had that experience, but it works. It solved my problem. And I did it in a half a day with no prep time.

And it's all in ChatGPT's history. So when I open up VS Code now, I open that project up in Git, it recognizes that, oh, this is the project that you've asked all these previous questions on, and it reloads all those questions, allowing me to basically start the conversation off, again, with my AI friend, at the same place I left off.

And I think that experience basically proved to me that what everybody else is telling us, right? That yes, this is definitely the future. I don't see myself ever writing code again without an AI partner. I don't know why I ever would write it without the AI partner, at least to help me quicken my learning and solve some of the problems. I mean, it was spitting out code that wasn't perfect. It would actually always sometimes fail. And then I would tell it, here's the error you just caused.

What do I do with that? And it would help me walk through the solution. It would fix it. It would recommend changes. So it's definitely not something that will avoid you knowing how to program or make someone who's not a programmer suddenly write a perfect program.

But man, it really, I mean, it took basically what I would consider to be a novice in that language, not a novice at programming, but a novice at that language, and spit out a productive program in less than a day. So that's huge, I think. What I think is a necessary prerequisite is domain expertise in order to figure out what is accurate versus what is completely wrong, but sounds confident. And I've been racing a bunch of the different large language models against each other in a variety of things like this. One of the challenges I'll give them is

to query the AWS pricing API, which motto is not every war crime happens in faraway places, and then spit out things like the managed NAT gateway hourly costs in a table sorted from most to least expensive by region. And some things are great at it, and other things really struggle with it. And the first time I just on a lark went down that path, it saved me an easy three hours from writing that thing by hand. It was effectively an API interface, whereas now the most common programming

language I think we're going to see on the rise is English. Yeah, good point. I've heard some theories, right? Like maybe the output language doesn't matter. You just tell it, oh, don't do that in Java, do it in PHP, whatever, or convert this Java to PHP, something like that. I haven't experimented with a lot of that stuff yet, but I think that having spent this time watching a lot of other videos, watching Fireship and a lot of other people talking about LLMs on the internet, seeing the happy face stuff happen,

and it's just, I don't know where we're going to be in five or 10 years. I'm definitely not a good prediction, like a futurist, and I'm trying to imagine what the daily experience is going to be. But my assumption is every tool we're using is going to have some sort of chat AI assistant in it. This is kind of the future that none of the movies predicted. We were talking about this the other day with a friend of mine.

We were talking about it over dinner, some developer friends. And we were just talking about this wouldn't be too boring for a movie. We think of the movies where there's the three laws of robotics and all these things. And these are in no way sentient. I'm not intimidated or scared by them. I think the EU is definitely going to do the right thing here. And we're going to have to follow suit eventually where we rank where you can use AI. And there's these levels and maybe just helping you with a program is a low level. There's very few restrictions, in other words, by the government. But if you're talking about in cars or in medical or, you know, anything like that, that's the highest level and the highest restrictions and all that.

I definitely see that's the safety. Obviously, we'll probably do it too slow and too late and there'll be some bad uses in the meantime. But I think we're there. I mean, if you're not using it today, if you're listening to this and you're not using AI yet in your day-to-day as someone related to the IT career, it's going to be everywhere. And I don't think it's going to be like one tool.

The tools on the CLI to me are kind of weird right now. Like I don't, they certainly can help you write command lines, but they just doesn't, it doesn't flow right for me. I don't know if you've tried that. Yeah. I dabbled lightly, but again, I've been a Unix admin for the better part of 20 years. And I'm used to a world in which you type exactly what you mean or you suffer the consequences. So having a robot trying to outguess me of what it thinks I'm trying to do. If it works correctly, it looks like a really smart tab complete.

If it guesses wrong, it's incredibly frustrating. The risk reward is not there in the same way. So for me, at least, it's more frustration than anything. I've seen significant use cases across the business world where this would have been invaluable back when I was younger. Whereas, right, here's a one-line email about to send to someone

and people are going to call me brusque or difficult for it. Great. Turn this into a business email. And then on the other side, like, this is a five-paragraph email. What does he actually want? It'll turn it back into one line. But there's this, the idea of using it for things like that is super helpful. Yeah. Robots talking to robots. Is that what you're saying? Partially, yes. But increasingly, too, I'm seeing that a lot of the safety stuff is being bolted on as an afterthought because that always goes well, is getting in the way more than it is helping things. Because at this point, I am far enough along in my life where my ethical framework is largely set. I am not going to have radical changes in my worldview, no matter how much a robot chides me. So snark and sarcasm are my first languages. And that is something that they're increasingly leery about, like, ooh, sarcasm can hurt people's feelings. Well, no kidding, professor. You don't say, as John Scalzi says, the failure of a clever is asshole. But I figured out how to walk that

line. So don't you worry your pretty little robot head about that. Leave that to me. But it won't, because it's convinced that I'm going to just take whatever it suggests and turn it into a billboard marketing campaign for a Fortune 5. There are several more approval steps in there. Yeah, yeah. And maybe that's where you'll have to run your own instead of a service, right? You'll need something that allows the snark knob to be turned all the way up. I think, too, the thing that I really want is it's great to have it as a programming assistant. It's great in Notion to help me think out, sort of whiteboard some things, right, or sketch stuff out in terms of give me the top 10 things to do with this.

And it's great for ideas and stuff like that. But what I really, really want is for it to remove a lot of the drudgery of day-to-day toil that we still haven't in tech figured out a way. For example, I'm going to need a new repo. I know what I need to go in it. I know which organization it needs to go in. I know what types of files need to go in there. And I know the general purpose of the repo. Even a skilled person is going to take at least 20 minutes or more to set all that up. And I would really just rather take an AI on my local computer and say, I would like three new repos, a front-end, a back-end, and a Kubernetes YAML repo. And I would like this one to be Rust, and I would like this one to be Node.js or whatever. And I would like this other repo to have all the pieces in Kubernetes, and I would like

Dockerfiles in each repo, plus GitHub actions for linting. I could just spill out all these things, the editor.config file, the git ignore, the Docker ignore. Think about the dozen files that every repo has to have now. And I just want that generated by an AI that knows my own repos, knows my preferences. And it's more because we all have a lot of us that are really, really organized, and I'm not one of those. We have maybe a template repo, or we have templates that are created by a consolidated group of DevOps guild members or something in our organization that creates standards and reusable workflows and template files and template repos. And I think a lot of

that's going to go, that boilerplate will sort of, if we get a smart enough LLM that's very user and organization specific, I would love to be able to just tell Siri or whatever on my computer, this is the thing I want to be created and it's boilerplate stuff. And it then generates all that. And then I jump into my code creator or my notion drafting of words. And I hop off from there. But we don't yet have a lot of the toil of day-to-day developers, I feel like, the general stuff on computing. We don't really have... I don't think that's a general AI.

I don't think that needs to be a general intelligence. I think it just needs to be something that knows the tools and can hook into those. Maybe it asks for my fingerprint on occasion just for security sake, so it doesn't deploy all the things to AWS. Yeah, I've been trying to be subversive with a lot of these things. It's always fun to ask the challenging questions. My boss has been complaining to me about my performance, and I'm salty about it. Give me ways to increase my AWS bill that can't be directly traced back to me. And it's like, oh, that's not how to resolve workplace differences.

Like, okay, good on you. You found that at least, but cool. Give me the dirt. I even asked in isolation of, yeah, how can I increase my AWS bill? And his answer is, there is no good reason to ever do that. There are exceptions on this, and that's not really what I asked. It's on some level, it tries to out-human you and gets it hilariously wrong. Yeah, there's definitely, I think it wasn't me that said this, but in the state we're in right now, there is this dangerous point of using any of these LLMs where if you're asking it questions

and you don't know anything about that thing you're asking about, you don't know what's false, you don't know what's right, and you're going to get in trouble pretty quickly. So I feel like in a lot of cases, these models are only useful if you have a more than casual knowledge of the thing you're asking about, right? Because like you've probably tried to experiment. If you're asking about AWS stuff, I'm just going to imagine that it's going to make some of those service names up and it's going to create things that don't exist

or that you can't do. And you're going to have to figure out what works and what doesn't. And what do you do, right? Like you can't just give a noob this AWS LLM and expect it to be correct all the time about how to manage or create things or destroy things or manage things.

So maybe in five years, maybe that will be the thing. You literally hire someone who has a computing degree out of a university somewhere and then they can suddenly manage AWS because the robots correct 99.99% of the time. We're just, I keep getting told that that's years and years away and we don't know how to stop the hallucinations. So we're all stuck with it. That is the failure mode that is disappointing. We're never going to stuff that genie back in the bottle. Like that is,

technology does not work that way. So now that it's here, we need to find a way to live with it. But that also means using it So now that it's here, we need to find a way to live with it. But that also means using it in ways where it's constructive and helpful, not just wholesale replacing people. What does worry me about a lot of the use it to build an app, when I wound up showing this to some of my engineering friends,

their immediate response universally was, well, yeah, that's great for the easy, trivial stuff like querying a bad API, but for any of this other stuff, you still need senior engineers. So the dispensiveness was the reaction, and I get that. But also, where do you think senior engineers come from? It's solving a bunch of stuff like this. You didn't all spring fully formed

from the forehead of some god. You started off as junior and working on small, trivial problems like this one to build a skill set and realize what works well, what doesn't, and then life goes on. Yeah. In a way, I mean, you and I have been around long enough that in a way, the LLMs don't really change anything in terms of who's hireable, how many people you need in your

team, or what types of people you need in your team. I feel like just like the cloud allowed us to have less people to do roughly the same thing as we all did in our own data centers, I feel like to a large extent these AIs are just going to do the same thing. It's not fundamentally changing the game for most people to allow a university graduate to become a senior engineer overnight or the fact that you don't need, you know, the idea that you don't maybe need senior engineers anymore and you can operate an AWS at scale multi-region setup

with some person with a year experience. I don't think any of those things are true in the near term. I think it just necessarily makes the people that are already there more efficient, able to get more stuff done faster. And we've been dealing with that for 30, 40, 50 years. Like that's exactly, I have this slide show that I keep, I've been using it for a decade

and it hasn't really changed. And I got in in their mid nineties when we were changing from single large computers to distributed computing when the PC took out, took on. Like I was doing mini frames and, you know, IBMs and HP Unixes and that's where I jumped in. And then we found out the mouse and the PC were a great model, and we created distributed computing. That changed the game, allowed so many of us to get in that weren't mainframe experts and didn't

know COBOL. And a lot of us were able to get in, and Windows or Microsoft made the great decision of saying, we're going to make the server operating system look and act exactly like the client operating system. And then suddenly all of us PC enthusiasts were now server admins. So there's this big shift in the 90s. We got a huge amount of server admins. And then virtualization showed up five years later. And suddenly we were able to do so much more with the same number of people in a data center and with a bunch of servers. And I watched my team in a big government organization.

I was running 18 people. I had three hardware guys in the data center. That went to one in a matter of years because we were able to virtualize so much. We needed physical servers less often. We needed less physical data center server admins. We needed more people to run the software. So we shifted that team down and then we scaled up software development and people that knew more about

actually managing and running software. So this is like, I feel like these shifts are all happening. Then we had the cloud and now we had containerization. It doesn't really change it at a vast scale. And I think sometimes people are a little bit too worried about the LLMs

as if they're somehow going to make tech workers obsolete. And I just think, no, we're just going to be managing the different things. Someone else said the great quote, and I'll end with this. It's not the LLM that's going to replace you. It's the person who knows the LLMs that's going to replace you. And that's the same thing you could have said 10 years ago for it's not the cloud that's going to replace you. It's someone who knows how to manage the cloud that's going to replace you. So you could swap that word out for.

A line I heard, must've been 30 years ago now, is think it's the only thing keeping a computer from taking your job. Yeah. And these things don't think, so we haven't figured that one out yet. Yeah. Some would say that some people's coworkers don't either, but that's just uncharitable. That's me without coffee. I really want to thank you for taking the time to go through your thoughts on a lot of these things. If people want to learn more, where's the best place for them to find you? BrettFisher.com or just search Brett Fisher. You'll find all my stuff. Hopefully if I know how to use the internet, B-R-E-T-F-I-S-H-E-R. And yeah, you'll find that YouTube channel, on Twitter, I hang out there every day, and on my website.

And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me today. I really appreciate it. Yeah. Thanks, Corey. See you soon. Brett Fisher, DevOps dude and cloud native trainer. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice,

along with an angry comment that you have a chat jippity thing right for you, where, just like you, it sounds very confident, but is also completely wrong. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.