Sponsored by Reblaze, creators of Curiefense
Panelists
Guest
Show Notes
Hello and welcome to Committing to Cloud Native Podcast! It’s the podcast sponsored by Reblaze where we talk about the confluence of Cloud Native technology and Open Source. Today, our guest is Justin Garrison, who is a Developer Advocate at Amazon. He also worked at Disney Animation and Disney Streaming Services, and we found out what he did there before going to Amazon. Justin created bashScheduler, and he tells us why he said, “This is a really bad idea!” We learn more about his book, Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment, a blog post he wrote about “The Economics of Writing a Technical Book,” a talk he did for DevOpsDays Portland 2021 called TikTalk, and his cool “manpage” resume. Also, he shares some insight on how he sees recognition as something we could really bring into the software industry. Go ahead and download this episode now to find out so much more!
[00:01:18] Before Amazon, our guest, Justin, worked at Disney and he fills us in on what he did there and what he does now.
[00:04:36] Justin tells us more about his book, Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment.
[00:08:46] What’s going on with remote conferences and talks?
[00:11:17] Find out more about a talk Justin recorded for DevOpsDays Portland 2021 called TikTalk. He also tells us if there is an open source community on TikTok.
[00:14:27] Justin created bashScheduler and we find out what it does and why he said, “This is a really bad idea!”
[00:20:50] How did Justin get a Linux.com email address?
[00:21:43] Justin Dorfman is impressed with Justin’s man-page resume and he fills us in on the details and some tips on doing a resume.
[00:24:26] Justin mentions a brag document that he used by Julia Evans and her website called Wizard Zines.
[00:26:25] Will Justin write a follow up book to the Cloud Native Infrastructure?
[00:29:12] Justin tells us about a blog post he wrote three years ago called, “The Economics of Writing a Technical Book.”
[00:30:43] When Justin was at Disney, he got a movie credit for working on Zootopia which won an Oscar, and he talks about recognition being something he could see bringing into the software industry. He also shares something interesting about movie credits and recognition.
[00:34:33] The guys chat about how CNCF has done a great job about having the “Chop Wood Carry Water” Awards at KubeCon and the people behind the scene that have such a huge impact in the foundation.
[00:36:46] All Things Open 2021 is coming up and Justin will be giving a talk called, “Internet Scale, Open Source with Kubernetes,” that you should check out.
Links
Infrastructure for Entertainment-Justin Garrison (YouTube)
DevOpsDays Portland 2021- Justin Garrison- Ignite- TikTalk (YouTube)
Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment by Justin Garrison
The Economics of Writing a Technical Book by Justin Garrison (Medium)
Committing to Cloud Native Podcast-Episode 22-Thoughts on Bash Becoming Interplanetary and More with Brian J. Fox
Justin Garrison - man-page resume
Get your work recognized: write a brag document by Julia Evans
Credits
Executive Produced by Tzury Bar YochayProduced by Justin DorfmanEdited by Paul M. Bahr at Peachtree SoundShow notes by DeAnn Bahr at Peachtree SoundTranscript by Layten PryceTranscript
[00:02] Justin Garrison: It's slightly different than infrastructure is code environment where you have a repo of YAML files or something. Whenever you change them, it pushes out and it says, okay, now I'm going to make the world look like that. But this infrastructure of software has a tighter loop. It has more consistency to say, hey, if anything changes, right now, I'm going to revert that change, I'm going to make sure that the world concept looks like this with running software, and not just a repository full of code. That really was like the key thing that we came out of cloud native infrastructure. We saw that pattern over and over again, at successful companies. Amazon, Netflix, Google, Microsoft, like all these companies are focusing on how do we run our infrastructure, not by people, always reverting changes, but software doing that, and Kubernetes was, again, the controllers pattern was kind of the Northstar for us to say like, this is how it's done.
[00:52] Announcer: Hello, and welcome to committing to cloud native, the podcast where we talk about the interface between open source and cloud native. We're super excited about our guest today. I really hope you enjoy this conversation.
[01:07] Justin: Hey, everyone, I'm here with Justin Garrison. He's a developer advocate at Amazon. He lives in Los Angeles like me, we share a first name. Hey, Justin, how are you doing?
[01:16] Justin Garrison: I'm doing just fine, Justin.
[01:18] Justin: Awesome. Before Amazon, you were at Disney, what's under the hood there. You work on Disney plus talk about this.
[01:26] Justin Garrison: I was at Disney animation for four and a half years doing infrastructure for the future animated films, working on render farm artists, workstations, internal servers, which is a great eye opening experience. I learned a lot of deep Linux technology and kind of how to run things at scale, especially on prem. But we're also using multiple different services and that was really when containers were starting to come around. I started focusing more and more on how that can enable developers to deploy things on prem or in the cloud. It was really impressive for me just to be able to work in that environment.
[02:00] Then I moved over to Disney streaming services, which created Disney plus ESPN plus a lot of different smaller streaming services in there. I write infrastructure for them. Behind the scenes of Disney plus as Amazon. It's a lot of Amazon, I really started learning a lot more about how to run services in Amazon at scale, and how to do things with native services. My team was specifically in charge of the centralized container infrastructure we had. With the containers that we were running in Amazon, what does that look like? How did we enable developers to deploy in simple ways, so there's actually quite a few different Disney plus talks that reinvent from last year.
[02:37] If you want to find out some of the details about how Disney plus runs very specific things, I did three or four talks at reinvents, which go deep into how we were deploying things, how we were running things, what native services we were using at Disney plus. I actually, I did a talk with my old co worker Zack. We were on the same team at Disney plus, and then I had switched over to Amazon. It was great talking to him about how we created the deployment tools and how we were managing the centralized infrastructure. Lower the cognitive load for a lot of developers to not have to learn everything about the entire stack of like, okay, where's the Linux running? Where's the container fit in? Where's the scheduler fit in? Where's Amazon components and VPC in there.
[03:17] We kind of took care of all that for them, and gave them more of a platform style environment of just saying, hey, I have an app, here's my container, deploy 100 bucks, and we'd make sure that gets done, it's highly available and all of the best practices that we had for logging and monitoring and some defaults for dashboards. All that stuff just got created for them out of the box, and they didn't have to really worry about it or think about it. Then they could tweak or change things as they had need.
[03:44] Justin: Did they just like poach you from reinvent?
[03:49] Justin Garrison: I was really excited learning so much about Amazon from Disney Animation, and Disney streaming, and just saying, hey, like I have learned a lot in the last six years at Disney. I could really turn that around and help more people do these things in Amazon do very similar things in Amazon. I was first and foremost a customer that was just like, telling people about it. I was going into my own conferences and telling people hey, this is Kubernetes. Here's EKS, here's how containers help and doing those things day to day. Then now I do it for my day job. It's not actually something I do on the weekends or at nights or anything. It's like, hey, when I reached out to Amazon and said, I love these services, can I help other people use them better? I had a great interview experience and onboarding, to say like, this is how we're doing these things here. If this is the right way, I would love to help more customers and more people just be successful in these areas.
[04:36] Justin: I mean, you literally like wrote the book on cloud native infrastructure. Was that before or after you joined?
[04:43] Justin Garrison: That was before I was at Disney animation. That was before Disney plus. Someone in the Kubernetes community reached out and said, hey, I saw you were doing some things and I was doing writing on the side my own blog. I've written for blogs in the past. I really liked writing. I like written communication and someone reached out, looking for an author for this style book, and it was really around CNCF tooling and how that looks. The first time I started outlining it, it was early days of Kubernetes. We weren't really sure what we wanted to put in the book or anything. I reached out to Kelsey at the time was writing Kubernetes up and running. I asked him, hey, what advice do you have for writing a book, and the first thing he said was get a co author.
[05:23] I was like, that's great advice. I didn't know a co author at the time. I don't know who to reach out to. I started talking to people, especially within the CNCF community. Multiple people recommended Chris. Chris, and I had never met before, we had known each other like, in passing in the community, but never met. With that, I reached out to her, and she brought so much great experience. She was a SIG chair lead for SIG AWS inside of the Kubernetes community already. I was like, hey, you're doing a lot in AWS, she was a co maintainer for cops, which is a Kubernetes deployment tool on top of AWS.
[05:58] We started talking, and it was great just to be able to take her experience from what she was doing in open source and the community, and what I was doing sort of in an enterprise side of things, to be able to say, like, hey, how does this work for anyone, and the first iteration of the book changed a lot, because at first, it was really about Kubernetes. It was about how to like set up projects and where they fit in. We wrote the first draft, and we threw away most of it, because it was already out of date. It was something that was just like, these projects change too fast, this environment changes too fast. We went back to say, okay, what are the patterns?
[06:29] What are the things that really will make the book last more than two years? What can we put in here to teach someone, hey, don't look at like a new tool, or a new, you know, option for something, look at how it works, and look at where that gets applied. That really got us down to what we call infrastructure as software, which is what you see inside of you using Kubernetes, the control loop, it has software that runs. It takes some data, and it constantly looks at that state of the world and says, what's the desired state that you want me to change? What's the current state of the world? How do I make that happen, and that's what the controller constantly does over and over again.
[07:08] It's slightly different than infrastructure as code environment where you have a repo of YAML files or something. Whenever you change them, it pushes out and it says, okay, now I'm going to make the world look like that. But this infrastructure of software has a tighter loop. It has more consistency to say, hey, if anything changes, right, now, I'm gonna revert that change. I'm going to make sure that the world constantly looks like this with running software, and not just a repository full of code. That really was like the key thing that we came out of cloud native infrastructure. We saw that pattern over and over again, at successful companies, you know, Amazon, Netflix, Google, Microsoft, like all these companies are focusing on how do we run our infrastructure, not by people, always reverting changes, but software doing that.
[07:54] Kubernetes was, again, the controller's pattern was kind of the North Star for us to say, like, this is how it's done. But also calling out other places where it's done. Like Netflix has chaos monkeys, that's like a controller pattern. That's like, doing the wrong thing. Essentially, it's causing chaos, but it's still infrastructure of software. In the case of like, it's not waiting for a git commit, it's not waiting for someone to make a change. It's always looking at the environment, always measuring the environment. It says, hey, what happens if DNS goes away, or this instance goes away or something, and it can do that as running software. You want them more productive infrastructure as software patterns, not necessarily destructive, but chaos engineering has grown into its own to say, oh, hey, like, there's a lot of great tools that will also allow you to verify that your infrastructure tooling will correct things on the fly and not wait for a human intervention.
[08:47] Justin: What about remote conferences and talks. What's going on there?
[08:53] Justin Garrison: With COVID a lot has changed in that space. I've tried to be innovative. My room is actually tore apart right now because I'm recording a couple of conference talks. I'm trying to do it in a different way. People like watching remote conference talks. This is not like a PowerPoint slide deck isn't always the most entertaining thing. But if I look at things like YouTube, a normal YouTube video and say, like, hey, what's successful here and it is more engaging, there's a little more polish and and producing put into it. Then I also think of like, if I don't want to watch a conference, what is something that I do want to watch?
[09:28] To me, it was like, well, I'll watch TV episodes. I watch 20 minutes of a TV episode. I might learn something from it. I'll do that anytime. Like I'll just keep binge watching them. But I won't do that with conference talks. What if conference talks were more like TV shows? What if we actually change the format? What if there was no slide deck? What if it was tell a story? What if it was entertaining first, and if you learn something that's good and there's actually a quote from Walt Disney where he says if you make something entertaining, if someone learns something from it, that's great. But if you make it you know, educational first and it's not entertaining, what's the point/
[10:01] That's not his goal. His goal was entertainment first, hopefully someone learned something too. I've really taken that of like, that's what I'm trying to do. I had a cube con talk last year, which got a lot of great feedback of there was no slide deck, I literally filmed the mini movie in 20 something minutes or 30 minutes. I tried to teach people what it was like to run infrastructure for this entertainment business, because it's not well known for a lot of people. I literally started with like, what is it like to render a movie? What does that infrastructure look like, then what does it look like to stream that movie? What are different design considerations? Why is that infrastructure different? Why is it something that is important to have in both sides, like you can't have the same specialty of just like, oh, the render infrastructure can't also stream the movie that needs to be separate for various reasons and why.
[10:47] Justin: Well, it's interesting, because obviously, with the past couple of years, everything's been remote and in terms of events, and I saw a few people give recorded presentations, and they were really good. There's some people that are just like, oh, it doesn't count if it's recorded. I'm like, why? You know if it's interesting, and it keeps you glued, like you were saying, like a TV show.
[11:17] Justin Garrison: I don't know when this podcast is airing, but I have a talk that I recorded that's going live next week for DevOps, in Portland. The talk is called Tick Talk, but I recorded five Tick Talks. Five Tick Talk videos, and I stitched them together and I said, hey, I could tell a story with Tick Talks. Because that as a format is really interesting to me, and it adds some things that you can't do in a normal style. Like, here's my slide deck, here's some things to talk about. Like I'm actually able to switch scenes, I even switched clothes, I recorded some of them on different days. There was a lot that went into doing that style format that was different, but being able to be creative in that space, to me has been just a ton of fun. I love bringing just that like different view on like, how do we make this better for the audience. Still, they can learn something from it. It doesn't have to be just here's a bunch of data. Oh, like learn one or two things and be entertained and more people will see it and more people will learn.
[12:16] Justin: How is the open source community on tik tok? My fear with Tik Tok is I'm gonna get addicted because every time I see a Tik Tok video, I'm like, whoa, where the hell did the time go? I was like, I can't install this.
[12:30] Justin Garrison: It's definitely an outlet for a lot of people. What are you watching Tik Tok for. Most people, I think are watching it for entertainment. They want to be entertained, they want to feel some emotion. A lot of times that's laughter, especially in the last year and a half of you know, being on lockdown and being remote. It's like people need to laugh. It's something that is kind of core to who we are and tick tock in a lot of ways brings that. In small chunks of one to three minutes, I can just keep saying that wasn't funny, keep going. But it's important for everyone. There are some people that do really cool, like developer content. I really admire the Dev Talk sort of space where a lot of people want to learn, like change their lives.
[13:05] Being a developer breaking it technology for so many people is life changing. It's life changing for what they're able to do, where they're able to work, how they get jobs and being able to afford things. There's quite a few people that I've seen on there that some of it is, the funny side of it, where like, hey, I'm a developer, only a developer would understand this joke. Also the other side of like, hey, if you want to learn how to be a developer, here's some links. Here's some things you should learn. Both sides are valid, because it's needed for depending on where people are at. But it's cool, I follow some of them and I've seen those videos on my for you page.
[13:42] It's really great just to see how people are using that. My content that I've posted is mostly like on the funny side, not sometimes on the educational side, but I really try to like, figure out the format and how you can use these different formats, podcasts, YouTube videos, Tik Toks, there's so many different mediums and they all have pros and cons.
[14:01] Justin: Yeah, no, I mean, I think that's interesting. I've seen a few that were front end focus, like the CSS community, like they always have some good memes on Twitter, but like I'd never like thought cloud native and like low level programming would have like a market there. But please drop your Tik Tok link in the chat. We put that in the notes. That's something I'm definitely gonna check out. I'm not going to install Tik Tok but I'm going to check it out. One thing that caught my eye was bash scheduler and you say it's an open source project that you wrote, and I'll let you go more into it. But you said it's a really bad idea. I'm biased because I really like bash. I love bash. I interviewed the creator of it not too long ago, Episode 22, by the way, and what is bash scheduler, what does it do what you make it for?
[14:50] Justin Garrison: I made it to learn. I'm a project based learner. I wanted to learn the Kubernetes API. I didn't know about extending Kubernetes. I started it five years ago, four years ago, something like that when Kubernetes was still early, and someone told me you can add third party schedulers to Kubernetes. I said, really? How does that work? Well, where do you do that, and I just started diving into the API. One of the cool things about Kubernetes is the structure of the APIs. Once you understand the patterns, you can do a lot, you can figure out oh, this is repeated every time and even for native objects, or CRDS or whatever. It's just the same pattern over and over again. Sure, there's libraries and things to help you do more advanced, scalable things.
[15:36] But I want to say, can I take a bash script and take a pod and put it on a node and make a pod, and that's what bass scheduler was for. It's just okay, well, let's just randomly take some pod and put it on a node. I was doing this in my free time years ago, just saying, okay, and I wanted to do it with native tools, the first iteration of it actually didn't use GQ at all. I was parsing the JSON output with a [crosstalk 15:58]. But that's already. I was like, I want to be like a bash purist here, and then not use those easy tools like JQ. When I rewrote it this past year, I was like, you know, like, I make this way shorter and more understandable for other people to also learn if I just use JQ and say, hey, this is where the object is. At that point, it turned into I wasn't learning from it anymore. I wasn't using it.
[16:24] To me, it was three really cool things. One was just how easy and structure the API is to how easy it is to extend pieces in Kubernetes, by looking them up by saying like, hey, a scheduled pod is just a pod that has some metadata on it that says where it's supposed to go. Then the cubelet, everything else happens after the fact. The third thing actually was something I didn't think I would learn, but how easy it is to get a feedback loop of Kubernetes, and how much that enables learning. that was really exciting for me, because I could do a cube control proxy. I had access to the API server.
[16:56] I had used tools in the past, I have to used mezzos, I'd use these other things in the past, and I could never do it that easily. Being able to just all of a sudden, no matter where I was, or where the Kubernetes cluster was, create a cluster and then access API with my own authentication, all that stuff was just taken care of, and I just curling localhost, and then I was like, wait a minute, it's that easy. Okay, now, let me see what this does when I actually package this up in a container and put it in Kubernetes. It essentially has similar access to give it a service account, tell that you can call the API server and then I was like, okay, now that feedback loop was so powerful, because that's where people learn. It's not like reading a doc, it's not necessarily watching the video.
[17:37] It's doing something and say, having that aha moment of, oh, this is different, I get this. Now, when I've created bash schedule, that's what I want to do. I didn't want to do it with another library. I wrote a lot of Python in the past. I was like, I don't really want to do it with Python, I want to try it with bash and just see like, if I can do it with bash, it's simple enough that I could do it with anything. Just being able to do it with curl and JQ was very powerful.
[18:03] Justin: I said in the past, it always starts with a bash script. It just stays with the bash script. I mean, bash and YAML is like an every single cloud native related repository. I thought it was really interesting.
[18:17] Justin Garrison: Of every programming language, I've learned, I've gotten the most mileage out of bash. Yeah, that's the thing that I can start to.
[18:22] Justin: It's everywhere. It's on Mars, for God's sakes. It's just really great tool, I think for anyone who uses, even Unix like or Windows now it's just a great scripting language.
[18:34] Justin Garrison: For me, years ago, I set limits for myself on bash, and knowing when to turn to the tool or when to turn away from it was really important. I learned through doing my own development and working in various environments that basically I have a couple rules for when I stopped using bash. That's typically when the script itself becomes more than 100 lines. If it's 100 lines, more than 100 lines, at some point, I probably should change to something else. I can condense things that I can make it easier for humans to read after the 100 lines. The second one is if I have to accept more than two arguments on the script. Once I have a switch statement that has three plus arguments, maybe five, it's just gonna keep growing at that point. If I reach two, I know I'm gonna have 10.
At that point, I'm like, I want a better arc [inaudible 19:18] library, I want something that's going to do some better options just on that Unix style strings and set ops just isn't great. Then the third thing was really around if I needed to use an array, if I have to turn to any sort of bash array like in bash scheduler, I use one but once I start hitting an array, I know I'm doing something a little more complex for a scripting language and I try to look for something else. I can do this a lot easier in Ruby or Python or go, maybe I should just switch it up now. Because once you invest all the time, it's gonna be harder to switch. Those are kind of my three rules of like, I will use bash all day until I hit those three, one of those three things and then I will look for the next best tool.
[19:58] Justin: I like that. It's like the three rules to succeed in scripting.
[20:03] Justin Garrison: It's helped me a lot, because by starting with bash, I could build things so much faster, I can do and see things. I can't tell you how many internal tools and some open source projects, I've started that were a bash script. I use those same rules. I said, hey, this is the POC, the next version should be written in some other language for these reasons. Let's rewrite from there. We didn't invest too much time in that POC, but we got the user experience. We got some of the functionality, and then we can see how it would grow from there.
[20:33] Justin: Yeah, I mean, your disciplined.
[20:36] Justin Garrison: I failed so many times. By failing and saying once I was managing the 500, line bash script then I was like, I've made some mistakes. That's when I started learning the hard way these rules.
[20:48] Justin: That's cool. One other thing I saw, which was pretty cool is you have a linux.com email address, like, how do you get one of those?
[20:55] Justin Garrison: It was something that I didn't know about. But the Linux Foundation has individual memberships that you can pay for. For $150, you get a lifetime email address from the Linux Foundation, which is linux.com email. I paid for one along time ago, and I don't know how many like I got Justin, just because it was there. It's Justin at Linux. I was like, that's cool. It's just an email redirector it's not like, you know, anything special, but I have, you know, a lifetime membership with the Linux Foundation and it forwards that email. I thought it was cool. I saw someone else have one and they had a really short one. I was like, I think I want that. When it was a first name only short domain. That's really cool. I think I want one of those. Yeah, so it's a redirector for me.
[21:38] Justin: Still made me go wow, that's pretty impressive. Speaking of impressive, I looked at your resume, and it's a man page. Did you think of that? Or do you like getting an idea for someone else? I want to just kind of do mine like that now, but I feel like I'd be ripping you off. How did you get the idea? You just like, you know what man page, I think would be a great resume for that.
[22:00] Justin Garrison: Someone else. I got it from someone else. His name is Major.
[22:03] Justin: Oh Major Hayden?
[22:02] Justin Garrison: Yep.
[22:04] Justin: Oh, from Rackspace.
[22:06] Justin Garrison: Yep, he had at first, he's the first place I saw. He has it as an HTML, it was on his website. I condensed it, I've been using that same style for a long time, because I was so familiar with the format. I think I've had more comments in my career about the format of the man page, then the content on the resume.
[22:25] Justin: It looks legit. I was like, whoa, wait a minute, it's his resume.
[22:30] Justin Garrison: It did teach me a lot about being unique to like, get some attention. It doesn't do great with like, automated parsers for man pages, and that sort of stuff. Because I would have to export a PDF, make the HTML, I make it a single page, and then I export a PDF. That's what I would send, but also top tip for anyone doing a resume. Store it in a Git repo. Put your resume in a Git repo. I've been doing that for, I don't know, a decade now almost. I have forks of like, hey, here's the job path that I was looking at this other company. I have, you know, tags that would show hey, here's the one I submitted to this company on this date, and being able to review that history was super valuable for me as I was, you know, growing in my career and looking at other opportunities, and even just learning from my own mistakes in the past or just like, hey, this wasn't resume. dot v2 docs, like this was actually like, hey, git log.
[23:24] Oh, there's that fork that I had, that had some content that I remembered. Or here's the tag of if I applied at the same company multiple times, I could see the versions that I applied on a fork. Having that history is invaluable, because you forget so much, or at least I do.
[23:40] Justin: Especially like the older you get. I would always like be amazed that my mom wouldn't remember certain things, because I remembered everything when I was younger and then once you like, get in your 30s you just like start to go, I never said that. Did I say that? Then it's like they play it for you. I'm like, Oh my God, I totally forgot. I'm gonna start doing that. I think that's actually a really great idea because you can just see the evolution of your resume and your life, your professional career.
[24:07] Justin Garrison: Even if you're doing a Word file, right? Like you do Microsoft Word or something like that's still text. It's harder to diff HTML, the man page resume was really easy because it's just HTML, CSS, but there's definitely value. I would still commit the PDF, which was just like a blob, eventually, hey, here I can see the snapshot of the thing. I really think that I had a lot of value out of doing get from a resume, but also I would keep what's called a brag document. Julie Evans I think is her name. She does the wizard zine, the comics, online of like different Linux tools and networking tools, stuff. She's amazing at pushing all this stuff.
[24:42] I first read about using a brag doc from a blog post she wrote, I have a quarterly reminder, fill out your brag doc. I just put a couple summaries of the things I'm proud of that I work pn. Not necessarily all the projects. Not necessarily like everything I did. Just like hey, if I look back in three months, like what would be the two things that I'd say like I was proud I did that, or I was happy I worked on that, or something big I learned. I put those in the brag doc. I've been keeping those for years now. Four times a year, I fill out a section of that, and it helps with yearly reviews, all that stuff, but also it helps with the resume. Because then I look back hey, my six years at Disney, what did I work on? What was I proud of? I can review that. Hey, you know what I was really proud of like, I was proud that I worked on Moana and Wreck It Ralph. All these things are like, awesome, but like, hey, what did I actually contribute?
[25:28] What was the thing I was doing for those projects? What was it that I would put on my resume, and that's where the brag doc came in. Then I can see that tracking in the Git repo of resume. But also in those brag docs, great career advice that I learned from two different places.
[25:44] Justin: I do on my website, I post things that are public, but I don't keep track of like internal things that it can't link to. I think that's actually a really good idea. The way I version it, I do my age. I do like 3.6 and then the amount of times I've edited the site in my 3.6, 36 years, mark. That's been working good. But I think that there's a lot of things that I forget, because they're not like something you can just link to. I like that. The brag doc, I got to look that up. Is there going to be like a cloud native infrastructure, follow up book, or you kind of done with being author?
[26:32] Justin Garrison: I enjoyed being an author, I enjoyed writing the book. Chris and I debated writing version two, because there was a lot missing. When we wrote the book, it came out [inaudible 26:40] We were writing it early 17. Taking everything we learned from the 2016 through mid 2017, and put it in the book. Even things like lambda and serverless were like just coming around and security in the cloud. There was a lot of things in here that weren't necessarily available. People hadn't really failed at it enough to have a way to learn and teach people. There's things we would love to put in there as like a v2 to extend a lot of it. The pattern, I think is still the same where even with security, even with some other thing you're trying to do, if you want to run it at scale, having software manage that thing through some sort of declarative state is probably the way to go.
[27:26] But we haven't really scheduled or started working on any sort of v2 for it. We both done a lot since. She has gone on to, you know, take the idea of infrastructure software, and really implement it in different tools in different areas, especially in the Kubernetes community. Things like cluster API, are kind of direct descendants from the idea of how do you manage infrastructure, grazers great at managing pieces of infrastructure for the cluster, but how do you manage Kubernetes itself? How do you manage more things inside of the greater scheme of what your infrastructure means. Including things like pager duty schedules, and on call.
[28:02] Those sorts of things are also part of your infrastructure. People don't think of it that way. But it's really critical to have those aspects be rolled into these changes. Because once you have a disconnect between the documentation, and the runbook, and the code that's running and who gets paged, you're going to have a hard time. There's going to be some disconnect there where nothing lined up properly. Treating all of those things as critical infrastructure are really important. We still talk about it a lot, we still try to keep people educated and know what the next thing is. Like how they can be successful with the patterns. But we haven't really done anything with writing another version for the book.
[28:42] Justin: We've had a couple authors on the podcast and one fellow, he did a self publish. Then he just did like a publisher. He said, just the back and forth with the person who checks. The technical editor. He just said it was just like, I'm never gonna do that. I'm just gonna do Self Publish. It's just so difficult. But I think O'Reilly is such a great brand. It's like, it's got to be such an accomplishment. Was that your first book?
[29:12] Justin Garrison: Yeah. I wrote a blog post a while ago about the economics of writing technical book, because a lot of people ask about, like, well, did you make money, what was the process like I try to actually lay that out a lot in this blog post. It's a couple years old now from that, but actually 2018, so three years old, but I really tried to put any information that I had at the time in there because it was great writing my first book with someone, a group that was professional, and they knew the process and they knew the timing for things. I didn't have to get an editor and do all the reviews myself because as much as I like writing, I'm not great at that grammar itself, and knowing consistency for capitalization, or a comma versus an M dash or something like that.
[29:52] There's a lot of benefits in just having professionals review that work and help make it better in so many ways. The CNCF was great with the book as well because it came out right around that time of a cube con. I was working with Chris and Dan from CNCF at the time. They love that we were writing a book around this ecosystem, Dan has a quote on the back of the book, which I was forever thankful for him being able to, like be part of that and promote it as well. It was a great experience. Going forward for me, I might do like self publish in the future, for something that is more low key or something that is not necessarily like a professional endeavor, I get really excited about remote work. I get excited about culture. I get excited about process for things. I love addressing some of those topics too, which isn't necessarily like the O'Reilly technical sort of background for like the audience.
[30:44] Justin: So, you were at Disney? Did you get an Oscar?
[30:47] Justin Garrison: My first movie credit is Zootopia, which did win an Oscar. I was able to hold the Oscar. The Oscar goes to the the directors of the film.
[30:56] Justin: Are they heavy?
[30:57] Justin Garrison: Yeah.
[30:57] Justin: That's got to be really cool seeing your name in the credits.
[31:03] Justin Garrison: The recognition, I think is something that we could really bring into the software industry. It's a artifact of the history of Hollywood where credits used to be at the beginning of films. They didn't used to be this like mile long scroll at the end. They had basically the top billing, you know, people would be at the beginning of the film, and there'd be nothing at the end. We don't really have that same organization or recognition inside of software, or inside of open source. But I guess the like, closest thing you can see is like a maintainers file or owners file or something at a Git repo. But it's not really celebrated the same way. I do think there could be a notion of having more celebration and having more like formal recognition for those things.
Even if it's like, at this point in time, because movies are box software, modern movies. It's a snapshot in time of the development. It goes in a box, literally on a disk on a box. It sits in like in the bits get translated if you bring home a DVD or something like that. But even in streaming services, right, like it's a artifact in time. Software is not really like that software constantly changes. It's something that is always like, you can't take a snapshot of Disney plus. When I was there at Disney plus, like it's completely different, a lot of aspects from a year and a half, two years later.
[32:16] Justin: Yeah, I think it GitHub is doing a pretty good job with their stars program. Daniel Stenberg, who founded Carolan, he just got like a real gold star sent to him with a bunch of swag and everything. Then they highlighted them on the blog and being a maintainer for 30 plus years. GitHub is definitely do that. But it shouldn't stop there.
[32:39] Justin Garrison: Recognizing the I don't wanna say top billing, but like the real stars, the people that are very public and very much in front, they've done a lot of work for sure. They've put in the time. The first company that started listing everyone, like the first company that said, hey, we want to list our legal department, we want to list marketing, we want to list movie production, babies like that didn't come around until Pixar in Toy Story. They're like, no, everyone helped make this film. Even though there is voice actors, even though there was artists. They wanted to say, everyone should get their name in the credits. At the time, that was controversial.
[33:12] That was something that the movie industry said no, like only top billing gets that, you can't make them too long. They actually have a break. If you go back and watch original Toy Story, there's a line break that says Pixar would also like to thank it's not part of the credits. That's how they kind of were like, hey, we want to get around this rule and give everyone credit for their input on this. Everyone from onboard training to HR to finance, like they helped make this film and they put all those names in the credits, which I thought was really fascinating just to see like how that's grown to now it's just everyone. That's what you do. Like everyone gets that here at the studio for whatever the rules are working on a film like you get your name and a credit.
[33:51] Justin: It's got to be just a real big confidence booster. I don't know just something where it feels good to get recognized. I think that's definitely something that the open source community and cloud native community can take after.
[34:09] Justin Garrison: Even if your name is eight minutes down the 10 minutes scroll, it's still that recognition. It shows that you had some ownership and you can actually point back to that, and that is important.
[34:18] Justin: The thing is, especially with open source, there's so many people, non code contributors and non technical contributors that do amazing things behind the scenes, but how do we get them in?
[34:33] Justin Garrison: I do think that CNCF has done a really good job about having the chop wood carry water awards at cube con where they say, hey, this isn't someone that necessarily was in front of the camera. They were doing the work and they were really pushing for this stuff behind the scenes and recognizing those people on stage with an award I think was a great first thing for them to just step up and say like these people are really important. We need to make sure that they have that recognition, even if no one else is seeing it, they were.
[35:04] Justin: Yeah. Before I joined CNCF world, I didn't realize how many people were kinda in the background, Amy and Bill and all these folks that don't really touch GitHub or anything, but have such a huge impact in the foundation and just the ecosystem as a whole. There's other names I'm blanking on, but yeah, I mean, it's just the Christie, like all these people that are doing communications and getting everything organized for different events, and meetups and this and that. It's just really cool. It's just a cool community. I'll be honest, it's very organized. I mean, it's just really awesome to be a part of.
[35:45] Justin Garrison: The contributor experience holds the CIG, dedicated to that to grow the community and make sure that people coming on board to the community are having a good experience. Like they actually gather data to say, hey, you onboarded recently, what was good and bad, like, what can we do better and constantly trying to improve and be inclusive, and sometimes, it might even become like at the discomfort of someone else. I remember when the Kubernetes community meetings were Friday at like, 9 am pacific time, and it's great, because I'm pacific time. But that's not welcoming for everyone. Not everyone is pacific time, some people are asleep. Being able to spread that out and say like, hey, we have a lot of people in different parts of the world.
[36:26] Maybe 9am Pacific isn't the best time and actually taking that feedback and saying, well, we need to record these, they can be up on YouTube. But we also want other voices to be heard, not just people to listen to it. Being able to contribute there was important and contributes and all these other things that are focused on the community culture, I guess, is the word but the values that they have. I have all things open talk coming up next month that I'm actually recording right now about the communities specifically about how Kubernetes has scales and as a project and as code contributions and releases is absolutely important.
[37:00] Growing the community constantly, because if you stop growing the community, you're going to stagnate and you're not going to get new contributors. You're not going to get new points of view. Constantly getting that feedback loop is important.
[37:12] Justin: When she said all things open, I went there and like 2016 is a really great conference. Todd, if you're listening, you're awesome. What's your talk on?
[37:22] Justin Garrison: It's called interest scale open source of Kubernetes.
[37:24] Justin: Nice. Okay, cool. Awesome. Well, everyone, check that out when you hear this.
[37:30] Justin Garrison: I mean, this has been a lot of fun. It's been great just seeing these podcasts and other channels that have this sort of content that people that maybe are getting started or trying to understand how things work inside the broader CNCF ecosystem. It's not just about like being part of that org or being directly tied to that Kubernetes or Like you could be a part of the community and not contribute code or you can just have some other open source project that uses their projects.
[37:56] Justin: You're very right. Especially in CNCF, there are so many different tasks that need to be done that don't require a text editor. If you are on the sidelines, want to get in the game, then there's plenty of opportunities. Anyway, that's all we got today, folks. I gotts go get a haircut.
[38:20] Announcer: Listeners. I hope you enjoyed this one. Do Tune in next time. We're really excited about our lineup of guests. We have a super exciting guest next week, as well. Check out the show notes for this podcast at podcast.curiefense.io for the community to cloud native podcast. Thanks again for listening. Tune in next week. Catch you later.
Special Guest: Justin Garrison.
Sponsored By:
- Curiefense: Protect Your Cloud Native Applications 👉 Try Curiefense today!
