Building a Community around Cloud-Native Content with Bret Fisher

Episode Summary

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. 

Episode Show Notes & Transcript

About Bret

For 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:

Transcript

Announcer: 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.



Corey: 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 Insights, you ask? Visit sysdig.com/screaming to learn more. That's S-Y-S-D-I-G.com/screaming.



My thanks as well to Sysdig for sponsoring this ridiculous podcast.



Corey: 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 Bret Fisher, DevOps dude and cloud-native trainer. Bret, great to talk to you. What do you do?



Bret: [laugh]. 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.



Corey: I’ve been trying to get the 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. It, at least 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 of thousand people in it.



Bret: Nice. Yeah, I mean, some people love Slack. I still have a Slack community for my courses. Discord, I feel like is way more community friendly. By the way, a good server admin knows how to change those settings, which there are 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 a mentions or, you know, 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 me 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, you know, recovering IT pros.



And the wonderful thing about it is you always start out—like, you’d do the same thing, I’m sure—where you start a podcast or YouTube channel or a chat community or Telegram, or a 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 a, its own nature. We’ve got, I don’t know, close to a dozen moderators now and people are just volunteering their time to help others. It’s wonderful. I actually—I consider it, like, one of the safe places, unlike maybe Stack Overflow where you might get hated for the wrong question. And we try to guide you to a better question so [laugh] 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.



Corey: 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.



Bret: [laugh]. 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 podcasts 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 it 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. Because I kind of had to choose, you know? Because 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 [laugh] 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 we—the luckily—the lucky thing of Dis—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 could have 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.



Corey: Oh, yeah. I just parked it on, originally, a hardware box, now EC2. And this ran Irssi as my client—because I’m old school—inside of tmux 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—



Bret: Mmm. Absolutely. Yeah.



Corey: —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.



Bret: Yeah. Yeah, I definitely—and that, 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?



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 was a lot people that still didn’t want to use Twitter, but 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 have run Threads and some people on Bluesky, and now—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 am—I have found myself actually kind of 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.



Corey: 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 learned 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 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 can be forgiven for in some cases in the social media side of it for thinking that I’d forgotten to publish this thing.



Bret: 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 I think the same is true of learning and teaching, where my teaching style has always been visual.



I think have almost always been in all my videos. My first course seven years ago, I was in it phy—like, I had my headshot in there and I just thought that that was a part of the best way you could make that content. And doesn’t mean that I’m 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 [laugh] where I’m moving my hands around a lot. So, I think that the medium is very specific to the person. And I meet people all the time that I find out, they didn’t learn 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 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, you know, 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 were 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 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 [laugh] same time. So, what is it the great Will Smith says? “Do two things and two things suffer.” [laugh]. 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, maybe, if I had only dedicated to one thing.



Corey: No, 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 always more things to do than I will ever be able to address. You have to pick and choose, on 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.



Bret: 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.



Like 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 want 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—any of these content creation things, 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 I—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 know, you can fall into that trap with any of that 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 try to make some of it a little funner.



Corey: This question might come across as passive-aggressive or back-handedly 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?



Bret: Yeah. Yeah.



Corey: And so, you’ve never run Kubernetes in anger, which is, of course, was 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.



Bret: Yeah. That’s a real fear, for sure. And that’s why I’m kind of—I think I kind of do what you do and 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 in the last maybe three or four years.



Because you’re right. There’s two things that are, right? Like, it’s hard to stay relevant if you don’t actually get your hands dirty, your content ends up I think this 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 into 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 GUI 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 the 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 going to have to do that again in a few years when I feel like I’m losing touch like you’re saying there. That’s a—yeah, so I agree. Same problem [laugh].



Corey: Crap, I was hoping you had some magic silver bullet—



Bret: No. [laugh].



Corey: —other than, “No, it still gnaws at you forever and there’s no real way to get away for”—great. But, uhh, it keeps things… interesting.



Bret: I would love to say that I have that skill, that ability to, like, just talk with you about your customers and, like, transfer all that knowledge so that I can then talk about it, but I don’t know. I don’t know. It’s tough.



Corey: 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.



Bret: Ohhh.



Corey: Which apparently needs to be brought into every conversation as per, you know, analysts and Amazon leadership, apparently. What’s your take on it?



Bret: Yeah. Yeah. Well, I was earl—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.



Corey: Yeah. Back when the Hello World was a PhD from Stanford.



Bret: Yeah [laugh], 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. I was not an OpenAI 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 code and YAML and TOML and, you know, the stuff that I deal with every day, I 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 an early beta, so I was like, kind of invited. And it was filling out YAML for me. It was creating Kubernetes YAML for me.



And like we’re all learning, you know, it hallucinates, as we say, which is lying. It made stuff up for 50% of the time. And it was—it is way better now. So, I think I actually wrote in my newsletter a couple 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, like these certificates of completion or certifications, you know, 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 can 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 libraries, so I’d have to figure out which libraries I needed and all that stuff. All the dependencies.



Corey: You make the same typical newcomer mistakes of not understanding the local idioms and whatnot. Oh, yeah.



Bret: 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. Like, and it was—we’re talking really just hundreds of lines of code at the end of the day, but 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 NodeJS 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, you know, 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 ChatGPT-4 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, then they copy out code and they paste it in their editor.



Well, there was none of that because since that’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 ten ways to improve this code now that it works?” And you know, “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 [laugh], which I hear you 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 and get it, 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 prompts. I mean, it was spitting out code that wasn’t perfect. It would actually—[unintelligible 00:23:53] 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.




[midroll 00:24:27]



Corey: What I think is a necessary prerequisite is a domain expertise in order to figure out what is accurate versus what is completely wrong, but sounds competent. 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 cost 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.



Bret: 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, right, you know, watching [Fireship 00:25:37], 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 ten years. I am 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. I mean, this is kind of the future that, like, none of the movies predicted.



[laugh]. 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, like, this would be too boring for a movie, like, we all want the—you know, 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, like, 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, in anything like that, that’s the highest level and the highest restrictions and all that. I could 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, like, 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, they certainly can help you write command lines, but it just doesn’t flow right for me. I don’t know if you’ve tried that.



Corey: Yeah. I ha—I’ve 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.



Bret: Right.



Corey: 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, where it’s, “Great, here’s a one-line email I’m 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.



Bret: Yeah. Robots talking to robots? Is that what you’re saying? Yeah.



Corey: Well, 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 [unintelligible 00:28:29] me.



So, snark and sarcasm are my first languages and that is something that increasingly they’re leery about, like, oh, sarcasm can hurt people’s feelings. “Well, no kidding, professor, you don’t say.” As John Scalzi says, “The failure mode of 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.



Bret: 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 and notion to help me, you know, think out, you know, sort of whiteboard some things, right, or sketch stuff out in terms of, “Give me the top ten 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 the 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 back-end, and a Kubernetes YAML repo. And I would like this one to be Rust, and I would like this one to be NodeJS or whatever, and I would like this other repo to have all the pieces in Kubernetes. And I would like Docker files in each repo plus GitHub Actions for linting.”



Like, I could just spill out, you know, all these things: the editor.config file, the Git ignore, the Docker ignore, think about, like, 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 that’s—like, 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—maybe I don’t think that’s a general AI. I don’t think we’re… I don’t think that needs to be like 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 [laugh] so it doesn’t deploy all the things to AWS. But.



Corey: Yeah. Like, I’ve been trying to be subversive with a lot of these things. Like, it’s always fun to ask the challenging questions, like, “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 found that at least, but cool, give me the dirt. I get asked in isolation of, “Yeah, how can I increase my AWS bill?” And its answer is, “There is no good reason to ever do that.” Mmm, there are exceptions on this and that’s not really what I asked. It’s, on some level, that tries to out-human you and gets it hilariously wrong.



Bret: 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 can—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 robot is 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.



Corey: 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 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, like, the easy, trivial stuff like querying a bad API, but for any of this other stuff, you still need senior engineers.” So, their defensiveness 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. Like, 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, then life goes on.



Bret: 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 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 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 at 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 slideshow that I keep, I’ve been using it for a decade and it hasn’t really changed. And I got in in the mid-’90s when we were changing from single large computers to distributed computing when the PC took out—took on. I mean, like, I was doing miniframes, 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 us, 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 a 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, you know, 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 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 the shifts are happening, then we had the cloud and then 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. We’re going to—someone else said the great quote, and I’ll end with this, you know, “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 ten 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.” [laugh]. So, you could swap that word out for—



Corey: A line I heard, must have been 30 years ago now is, “Think. It’s the only thing keeping a computer from taking your job.”



Bret: Yeah [laugh], and these things don’t think so. We haven’t figured that one out yet.



Corey: Yeah. Some would say that some people’s coworkers don’t either, but that’s just uncharitable.



Bret: That’s me without coffee [laugh].



Corey: [laugh]. 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?



Bret: bretfisher.com, or just search Bret 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 a YouTube channel, on Twitter, I hang out there every day, and on my website.



Corey: And we will, of course, put links to that in the [show notes 00:38:22]. Thank you so much for taking the time to speak with me today. I really appreciate it.



Bret: Yeah. Thanks, Corey. See you soon.



Corey: Bret 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-Gippity thing write for you, where, just like you, it sounds very confident, but it’s also completely wrong.


Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
Newsletter Footer

Get the Newsletter

Reach over 30,000 discerning engineers, managers, enthusiasts who actually care about the state of Amazon’s cloud ecosystems.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.
Sponsor Icon Footer

Sponsor an Episode

Get your message in front of people who care enough to keep current about the cloud phenomenon and its business impacts.