Click a paragraph to jump to that point in the audio.
Matt Butcher: [00:00:00] I can use a lot of metaphors to describe Helm, but the short version is—
Bridget: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Bridget Kromhout, with a great show for you today, but first, a word from our sponsors. This episode is sponsored by CircleCI. Designed for modern software teams, CircleCI’s continuous integration and delivery platform helps developers push code with confidence. Trusted by thousands of companies, from 4-person startups to Fortune 500 businesses, CircleCI helps teams take their software from idea to delivery quickly, safely, and at scale. Visit arrestadevops.com/circleci to learn why high-performing DevOps teams use CircleCI to automate and accelerate their CI/CD pipelines. If you are like most of your friends in DevOps, you probably prefer using open-source solutions for observability. But you also wish you didn’t have to sacrifice scalability, performance, and simplicity. With Logz.io, you get the best of both worlds for your cloud environment. You can use the tools you love at the scale you need. Logz.io is a fully managed service that offers complete cloud observability for engineers on one unified platform. Log management and cloud SIEM based on ELK and infrastructure monitoring based on Grafana. To give it a try for yourself, sign up for a free 14-day trial today at logz.io/ado. And for your chance to win a free Logz.io t-shirt.
[00:01:51] The worst thing about the Arrested DevOps podcast is when it ends. You’re left wondering what to do next. What are you going to listen to on your commute home? How do you occupy your time when walking the dog? What are you going to listen to during the quarterly all-hands meeting? But fear not, dear listener, there is a solution. You need to subscribe to Software Defined Talk right now. It’s a weekly podcast that recaps all the news in cloud computing, DevOps, and enterprise software. The hosts, Cote, Matt Ray, and Brandon Wichard, will keep you up to date on all things cloud while offering tips on how to optimize your Costco haul and how to PowerPoint. It’s a fun, free-flowing conversation that will keep you entertained and informed. What are you waiting for? Subscribe to the podcast today by visiting softwaredefinedtalk.com or by searching for Software Defined Talk in your favorite podcast app. Today, we’re going to talk about Helm and the community. And I would like to introduce our guests, starting with Matt Farina.
Matt Farina: [00:02:56] Hi, my name is Matt Farina. I work over at Samsung SDS doing Kubernetes and cloud-native things. I spend part of my time in upstream, part of my time doing internal stuff. And I’ve been doing open-source software now for greater than 15 years, and so that’s a lot of fun.
Bridget: I do feel like at some point you start saying over 10 years, over 15 years, a while. At some point I’m gonna have to stop. I think I have 15 years in there somewhere. At some point I’m gonna have to take that out. All right, so welcome Farina. Karen, Karen Chu, tell us about yourself.
Karen: Hey there, I’m Karen. I’m a community program manager on for Microsoft Azure on the Cloud Native Upstream team, and I joined Microsoft, I guess it’s been about 3 years now, through the Daeus acquisition.
Bridget: Excellent. I feel like there’s foreshadowing there, like spoiler alert, we’re going to talk a little bit about Daeus. Which brings us to Matt Butcher.
Matt Butcher: [00:03:59] Yeah, I’m Matt Butcher. I’m an engineer at Microsoft, also joined via the Daeus acquisition with Karen. My team at Microsoft is called Daeus Labs. We do the open-source development, mainly container-focused work with Kubernetes, and of course Helm and Brigade, and a number of other projects like CNAPP that we’re super proud of.
Bridget: Okay, so we got to start at the very beginning, a very good place to start. We’ll go with the superhero origin story of Helm. Like, what even is Helm? People have heard of it, but where did it come from? What is the genesis? And Butcher.
Matt Butcher: Yeah, so the one-phrase description we always use when we’re talking about what Helm is, is Helm is the package manager for Kubernetes. If you think about when you’re working on your Linux box, or macOS, or Windows, and you want to install a new piece of software, you use a package manager to do it. When we were making our first forays into Kubernetes, we wanted to provide that same kind of experience for the people who were just coming to Kubernetes. We wanted to provide people who were building packages, or building software, the ability to conveniently package it up. And we wanted to give people who were just starting out on Kubernetes a convenient and easy way to install stuff into Kubernetes. And so that was where we kind of came up with the idea behind Helm and behind this whole chart thing. A chart is a package that Helm consumes and can install into a cluster. And as far as the origin goes, it started out as a little tiny project inside of Deis. Karen and I and a a couple of other engineers. We were all together at a hackathon project, and this idea just kind of came out of the woodworks. We kicked the tires on it. Wow, that’s a lot of metaphors there. I can use a lot of metaphors to describe Helm, but the short version is, we wanted to build something that would be generally useful to the community and solve some of the problems we were having as we just got started with Kubernetes. With a little bit of work, This thing became Helm and took off kind of on its own. And as you know, is now, I don’t know what, 1.8 million downloads a month or something like that. So fairly successful there.
Bridget: [00:06:22] All right, so that is awesome. And I feel like you’ve told that story before, you’ll tell it again. We’re not gonna go too deep down that rabbit hole today, but I do wanna ask, since we don’t always have you and Karen in the room at the same time, Hey, Karen, when you were starting to do the community marketing around Helm, did you have an inkling that it was going to become what it did? At what moment did you look at this and say, oh, wow, this is actually blowing up?
Karen: Definitely not. I mean, I think at that point, Deis was still fairly young, having joined Engine Yard. Even for me, it was a few years ago, and it felt like things were still a bit scrappy. I’m not saying scrappy is bad, but I think when you’re at a startup and you start a project from the ground up, you don’t really know where it’s going to go. I think for us, no, didn’t think it would grow as big as it did. Helm started… Fairly along with when Kubernetes was coming into play as well. I think a lot of people were also surprised at the direction that— or the trajectory that Kubernetes took as well.
Matt Butcher: [00:07:40] You were the one who put together the booth and all the original marketing stuff and everything for Helm for the very first KubeCon, right?
Karen: Yeah. I worked with Shana on that. I mean, we kind of debuted Helm at the first KubeCon, and I think that was kind of our little taste to see how this would go. But yeah, even then, it was very scrappy. It was like a little turnkey booth. We had our socks. I don’t even know if we had stickers at that point, because the turnaround from the conception of the project, from that hackathon to KubeCon, wasn’t even that long of time.
Matt Butcher: I think our booth was only 6 feet by 8 feet or something tiny. KubeCon itself had, what, maybe a couple hundred people at it? I don’t remember.
Bridget: Looking back, hilarious. And I’m curious now, of course, we had a little foreshadowing because we mentioned charts. Farina, do you want to give us a sense of when did you come into this Helm excitement and what is this charts thing that you are bringing to the party?
Matt Farina: [00:08:45] I came in about 2 and a half years ago, 2 and a half years ago. I had been watching Helm and I’ve known Matt Butcher for over 10 years now. We’ve done a lot of things together over the years. I knew about this Helm thing. I’ve been watching it. Helm was a subproject of Kubernetes at this point, and I’m one of the co-chairs of SIG Apps that oversaw it. I was intimately familiar with Helm on this, but I hadn’t been a contributor. Then I started contributing in the charts area. Charts was— well, the charts repository that we have is a collection of community-curated packages, basically. If you wanted MySQL or MariaDB or many other things, this was the community-curated ones. In Helm 2, the repository was accessible right out of the box. We’ve made some changes since then, but it was that, and it started off small, and it grew really quickly, and I saw kind of an overwhelming load, and so I started coming in and contributing in charts, and this is just the community-curated charts, because when you think about charts, The whole design that they originally had was designed so just like apt repositories in Debian apt, different people could have their own repositories and use them in many different ways. It was like that, but we still had this community-curated one. And so I stepped in to start trying to automate what was very much a manual process at the time, because it looked painful to do all this manual curation over and over and over, and that killed me.
Bridget: [00:10:18] It’s like automate all the things. That is a wonderful choice.
Matt Butcher: Yeah, when we first started the chart repository, we had hypothesized that we would have somewhere between 12 and, and maximum maybe 30 charts in there. Uh, and, and when it started taking off, I, as one of the core maintainers on the code, I had no idea what to do with what to do with all these PRs that were coming in and the changes, because I’m not really as much of an operational person. So when Matt and— I think probably at the time you joined, Matt, there were probably, what, 3 or 4 other chart maintainers? And there have been over a dozen, I think, over time, right? But when you picked it up, it was probably around 15 or 20 charts. And I’m not— I don’t even know how many we have in there now.
Matt Farina: So there were a few more maintainers. There were probably 7 or 8 when I jumped in. There weren’t as many charts, but it very quickly grew. It was probably 50 charts when I came in, somewhere around there, but it had grown, uh, to hundreds of charts in, in the repository. And so you’ve got to think, people coming through with small changes, additions, feature additions, updates to READMEs across hundreds of different charts, and then you’re manually checking these out. And sometimes it’s YAML, that’s changing, and does it actually validate in Kubernetes? How does all this work? It’s one of those areas where when I came in— we had this guy, Reinhard, who was this amazing charts maintainer. He had all of these things, like if he reviewed a chart, you trusted his reviews, and that’s where I went to learn from. My first thought was, I can’t do what he does manually. I started automating it. I captured what he did and started automating it in the repo. This will be a quick tangent here. We created all of this automation where we linted charts and we linted pull requests, and then we actually tested them in live clusters to make sure everything installed. It became this wonderful test suite built around what he had done as a manual process. We actually broke that out into an independent tool called Chart Testing. Now, the charts repository consumed, but we turned it into something others could consume as well. Now, this is one of the things the chart team offers to people who self-host repositories, is this wonderful tool called chart testing that lints your YAML. It can test different configurations of your charts being installed into a cluster if you expect customers to do things in different ways, or users. It’s got all kinds of neat features. It’s driven by the charts folks in automating what used to be manual processes.
Bridget: [00:13:05] That is very actionable, and so we’ll definitely have a link in the show notes. I say that so that we actually do. I want to make sure that we’re talking really quick about— oh, go ahead.
Matt Butcher: I wanted to piggyback one more thing on there because I think there were really 4 distinct phases of how that whole charts story unfolded. The first was kind of the Wild West days when we started the repository and thought, oh, this will be great. And then with Matt and with Bitnami and with Reinhard, the second phase started where we went from, oh, this is a chart, throw anything in here and we’ll just package it up and release it, to here are some good design patterns. I remember Matt and Reinhard and Adnan from Bitnami produced this documentation for best practices for chart development, and I read it and learned a bunch. I’m like, I shouldn’t be learning things about the software I wrote from this, but it was great. It was the first time that I really started to understand the rigor through which these maintainers examined the charts. And then the third phase was the one Matt alluded to or described strongly, this kind of turn from manual checking into automated tooling. And then the last one, and the one that I think we should all be most proud of in this regard is that that tooling became generic to the point where other people would be able to use it. So we had gone from a Wild West repository to some canonical guidelines that could be programmatically applied to anyone’s chart repository.
Matt Farina: [00:14:40] And, you know, along the way, as it went from the Wild West to this, we actually saw a neat transition. Charts started off there. Charts have templates for Kubernetes manifests inside of them. The values and the replacement for the templatizing was very much Kubernetes structured in thought, just basic replacements for Kubernetes variables, so to speak, Kubernetes properties. It actually grew into having business logic and design patterns around the charts so you could encapsulate things. For example, you could specify Here’s the URL that we want to expose an application at. Then all of the things that needed to be created to do that around it would then be created and configured for you, sticking the kinds of values in the right places. It wasn’t so much a replacement pattern; it was logic inside of those charts to simplify your work as somebody who has to go install it.
Bridget: That is fantastic because I think what you’re describing is it’s applicable to so many things. It’s applicable to— I’m hearing the story of scaling and increasing your impact. And the thing that Butcher said that stuck with me is, I created this, and yet I don’t really know what’s happening with it. And that’s actually a good thing. And that’s making me think, I want to actually ask Karen about contrast, like the first HOME Summit. With even the next Helm Summit that we did with CNCF support? What did that scale from small, indie, scrappy to, hey, this is actually a little more? Can you talk a little bit about that scaling experience?
Karen: [00:16:24] Yeah, for the first Helm Summit, I did that right after, or a little bit after we had gotten acquired, but this was before we became a CNCF project. Again, I’m going to use the word scrappy here. It was a little bit scrappy, and I guess, in a sense, modest, in terms of doing all the sponsor stuff, the venue stuff, figuring out the schedule, and all that. Then, once we moved into becoming a CNCF project and having that support from CNCF, it definitely offloaded a lot of the logistical work. And like, in terms of like, you know, again, like the, the like schedule and CFP and stuff. But I think having that work offloaded to a group that obviously, you know, is very experienced in this space gave us a little bit more, like, it gave us back some resources to focus on other things. And I think in terms of like, Even though we handed this to CNCF to help execute, at the same time, we were able to take some of the lessons we had learned from the first conference and apply it back. I think between the two conferences, obviously, you can see that it’s a bit more scaled, but I think we tried to keep some consistent matters there as well in terms of just the nature of the conference not being very salesy, being very technical, and also just Yeah, not being flashy. It’s a weird thing to focus on, but yeah, we tried to make it about the technology and not necessarily the glitzy parts of conferences. But again, yeah, I think just utilizing the resources that came from CNCF, in that sense, that allowed us to scale to a bigger audience, but at the same time, by keeping in mind what our true message and efforts were focused on, we were able to keep things consistent while scaling.
Matt Farina: [00:18:27] Yeah, I actually want to say the first Helm Summit was one of my favorite conferences that I’ve been to. It was actually because there were different style tracks, there were different time limits for speakers, there was roundtable time. It was this great opportunity to hear technical talks from a wide variety of people, people who develop it, people who use it, and yet we still had a small enough intimate setting where we could talk to each other. It’s a major contrast from the CNCF conferences today that have well over 10,000 people, right? To have that small, intimate gathering where people could just talk and dig in and hear real-world stories, and it didn’t have that overly vendor feel. It had that very much, we’re people who are getting stuff done and being useful feel, and it was fun. So, I give props to Karen. That was an amazing conference.
Karen: Yay! I just wanna add on to that. With our second conference, even though we had more resources, I think even just trying to keep towards the small intimate setting, we didn’t try to upscale this to 1,000 people. It was still definitely a smaller group trying to hold that same culture that we had with the first conference.
Bridget: [00:19:46] Right. So, that’s really important, right? Maintaining the sense and the feel of your community wherever you’re taking it. But, and this is, I think, one of the core questions of open source that I think you folks have some really good insight into, which is, okay, cool, your open source project is really popular, and now it’s huge, and your issue queue is full, and people have lots of drive-by PRs for things where you’re like, I know we said pull requests accepted, but what is this? Like, how do you connect with the community when the community is variegated and wants many things, and some of those things are confusing and vexing. How do you deal with that?
Matt Butcher: I thought one of the things that was the most delightful about Helm when we started was that the community was small and also highly motivated to just explore and experiment and try and figure out what we were all collectively going to make out of this Kubernetes thing and this cloud-native thing. So, you’ve got a bunch of eager explorers who are willing to try something out and then try and work with you to figure it out. We used to do some really fun things. We used to be able to pair with people who were having problems and just go through on a Zoom call or on Slack, hey, okay, tell me about your cluster. Let’s try this. Let’s try that. It was a lovely feeling. I enjoyed it very much. It’s really hard to scale some of that behavior up and make— I, on very, very rare occasion, might get the opportunity to sit down with someone and look deeply into the way they’re using Helm. More often, it feels like the Time to Make the Doughnuts commercial, where it’s like, time to check the issue queue, time to check the issue queue, and you’re just kind of going through, scrambling as fast as you can. And we got to the point of where the issues felt like dialogues to really the first few interactions are almost robotic, right? Can you provide more information? Can you fill out all the fields on the template and not just 2 of them? You know, that kind of thing until you can actually dive in. And I found that to be a very disconnecting experience. Hard, hard to deal with. And I know some of the things we’ve tried to do is maintain a really positive Slack channel where people can ask comfortable questions and even if they don’t know, still feel like it’s a safe place to ask. But definitely for me, the biggest psychological, I would even say emotional challenge of Helm has been trying to learn how to deal with the volume while still looking at each person, each issue that comes in as being filed by a person with some needs, Often filing the issue out of frustration, because they don’t file issues when they’re happy with something.
Bridget: [00:22:45] Okay, that is true. I think most people don’t go to an open source project and find the issue button, the open new issue button, I love your software. So, what do you think, Farina? How do we continue to go a trajectory of good curation and response?
Matt Farina: Yeah, I mean, that’s a hard one. You talked about people showing up with pull requests and going, what are they doing? I think this is one of the things, and I’ll credit Butcher for this, is keeping us focused on what Helm does. It’s not trying to take over the world and do everything else. When people have other ideas, like, we should do this and add this and that, We try to encourage them, saying, you know what? That’s not a Helm thing, but you could do it as a Helm plugin because Helm has the ability to have plugins, or you could wrap Helm and have your own application. Give that a shot, and if you do that, we have a place where we’ll list your related projects so people can know about it. This isn’t a feature to go into Helm. We draw the line because it’s important not just to do everything, to dump everything. It’s not a junk drawer. But to actually say, this is an idea, and encouraging others to build out their thing and share it and build upon Helm or work with Helm in the appropriate ways. I think that’s a really useful aspect of this, is that extensibility and that thought. But, you know, again, the issue queue becomes a thing because as Helm became popular, we get more and more generic Kubernetes questions in there that have nothing to do with Helm, but are about Kubernetes and its complexity. And I don’t have a good way to solve that. I mean, we have somebody who goes through, we actually assign somebody to go through every week and be the triage person who’s going to go look at the issues, triage them, and respond to people to try to have that engagement because with so many, you’ve kind of got to sign up for it and focus on it and put real effort into it. But that’s hard. It’s really hard to do that. I think the best thing we can do is write better documentation and hope people read it and then point people to it.
Bridget: [00:24:56] I was just going to say—
Matt Farina: but I’m open to ideas.
Bridget: No, that’s actually a really good point. I was actually— I work on the same team as Karen at Microsoft. We both work for Lockie Evenson. I was just talking with him in my one-on-one this week about how I I put a couple of PRs in, just doing a few doc updates for Helm, and I thought, I need to do more of this, and we need to do more of this in general. I think he agrees, because it’s like, if some of these people opening issues found a doc that answered their question, they probably wouldn’t open an issue. Or maybe they would open an issue and tell us how great we are. That would be kind of fun. I’m curious, actually, As this project has progressed, one of the things that has changed is the involvement with the CNCF. And some of the— I imagine people who are listening to this in our audience might have questions about what does that look like when you become a CNCF project? They might have listened to the CNCF webinar that we did for Helm earlier this year. I’m wondering, Karen, since I happen to know you’re an ambassador, if you can tell us a little bit about what talking about your project in general does, and give us spoilers as to whether or not it brings new contributors or people who might give pull requests.
Karen: [00:26:19] Yeah, I mean, I think in terms of utilizing the CNCF to help spread the word about your project, I mean, obviously, they have a huge community and audience. I think working with them has given us a lot of opportunities, and some that we either knew about from the beginning or didn’t. I think that’s one of the things I want to share with people about getting your project into the CNCF. For us, obviously, we were doing a lot of on-the-ground things as much as we could before, but with the CNCF webinar, those are opportunities you get being part of it, and those are all online webinars that happen quarterly. Us going to conferences like KubeCon. They provide support. As of lately, they’ve started doing project pavilions, which are spaces dedicated to CNCF projects. At the last KubeCon in San Diego, we had a Helm-dedicated booth. That was really cool, because a lot of times, you have projects that— a lot of projects are the work of multiple companies, but there may not be a central booth dedicated to that project. For us at Microsoft, there’s no clear home booth at the booth or at our booth per se. Even if there was, it’s this weird feeling of like, well, we have people like Matt Farina who help work on the project and it’d be weird if he showed up at the Microsoft home booth. Having a Project Pavilion booth provides a neutral space and I think makes it clear that this is the one spot that you can come and talk to people about HELM. Yeah. And then other— I’m trying to think of other things. I mean, obviously, like I said earlier, like having, like doing our own HELM Summit these past few years has also been a great opportunity because again, like you’re bringing in the people who know that this is like a focused conversation.
Bridget: [00:28:25] So of course, now that we’re at this point in 2020, I have to say everything is not necessarily going to be travel and conferences right now. What are you thinking? And I’m interested because I know Butcher has an idea somewhere in this realm. What are you thinking is our best path or best recommendation right now for people who want to connect?
Matt Butcher: I thought that Helm Pavilion and the Helm Summits too, but those have been the opportunities where having a successful project, you know, I expressed earlier it’s frustrating to feel overwhelmed by the issue queue, but those are the opposite experiences where You feel like you really, you’ve got time allocated where the absolute best thing you can do, where there are no distractions pulling you in different directions, is to stand there and talk to people. And, you know, we talked, you know, we deep-dived with people into the internals of the template engine, would turn around and someone would walk up and say, I’m really frustrated with this, like, Kubernetes Helm thing. I don’t understand it. This whole conference is overwhelming me. And I get to talk to someone about that. It was fabulous and I would love finding environments where we could replicate that kind of experience, you know, to once again connect with the people, the people as people and not people as problem statements in an issue queue.
Matt Farina: [00:29:45] Yeah, and the project and the pavilion, right? That was one of the most fascinating things to me because I got to see people who had issues and I could help with. There were people who came by just to say thank you. You don’t see that in issue queues. You don’t see that other places. And we had that. And it was an opportunity to meet people from other projects or people who just wanted to come brainstorm on ideas around it. And as an engineer who loves to solve problems, having a problem and brainstorming around those things with other people who are excited and interested, that’s a lot of fun, right? And Karen, you did one of the most wonderful things in organizing us to always have somebody from the Helm project at the pavilion, where some of the tables were empty, you actually organized us intelligently to have somebody there. We’ve got project maintainers on Helm from— we’ve got over 20 of them from over 10 companies. That’s a lot of people to organize who are at the conferences, who get a chance to experience all 3 of those things, which I think are just wonderful for us and the people who are looking for that.
Bridget: [00:30:48] That is awesome. I have an idea that just came to me right now, and I’m going to put it out here live. Totally making new work for Karen. Sorry, Karen. Congratulations, Karen, because I think we need to have the Helm drive-by drop-in office hours, distinct from the maintainer call. This is kind of like the TGIK thing, but maybe not quite as focused, because instead of just being a presentation, I’m thinking happy helming. Or some such. And it’s basically the Helm happy hour drop-in, talking, you know, whatever, you know, Thursday afternoon, whatever you want it to be. Talk about Helm. Replicate that serendipitous experience.
Karen: Yeah, the feel-good experience. I definitely— yeah, I mean, I think as of these days, like, there are so many virtual conferences going on. Sure. Right. And it’s just like popping in, listening to people talk. But I mean, in terms of like, you know, stuff that I’ve done like with our team and just like socially, right? It’s like, it’s nice to have these breaks where you like show up and there’s no like clear agenda necessarily, but to like feel better and relax. And yeah, um, and I, I think that would, um, yeah, it’d be probably like the optimal way these days to like be reminded as to like why we work on this stuff.
Bridget: [00:32:12] Helm happy hour.
Matt Farina: Well, you know, an interesting angle to this is When you do the virtual conferences, you’ve got somebody who knows a lot of this stuff telling other people about the things that they’ve made and use, right? It’s not a 2-way interaction. You don’t get to hear from people. It puts the speakers kind of isolated telling other people their things. And when you’re at a real conference, you’ve got the hallway track and you can intermix with people. The virtual conferences, I’m not sure how they’re gonna do that well. But I think with this kind of virtual happy hour, what I really like about it is, is it’s not somebody lecturing or teaching or telling. It’s somebody who can just listen to others and have 2-way conversations. And I think that’s vital because a community is a lot of people, not some people who know lecturing others.
Bridget: And also, I feel like as Helm approaches graduation and is very popular, there’s a lot of stuff on the agenda in the community calls to the point where we can’t necessarily just sit and shoot the shit as much. And so this could be an opportunity for that, that could fill that void in our hearts. I have a fun/optional question, which is, we’ll have a link in the show notes to Phippy and Friends, which are the absolutely adorable Kubernetes characters. I’m just curious if anybody wants to answer this question, which is, which character in the Phippy and Friends gang do you identify with the most? I’m totally going to look at Butcher.
Matt Butcher: [00:33:42] Oh no, Karen should totally get to answer this first because the visuals behind all of this stuff was Karen’s brainchild.
Bridget: Fantastic. All right, Karen.
Karen: I want to say Zee just because like Zee was like kind of in this position to like, or like in a position where like she didn’t know a lot and like she went on this, you know, journey to like learn about all the different animals, at least like in the last book, right? And so I feel like I identify with Zee because I’m full of questions to the point where like I feel like people are often overwhelmed by me asking questions. And so I feel like the inquisitive version of me like lives on through Z. I love that.
Bridget: And honestly, I think asking questions honestly and openly and caring about the answer is a superpower because people love to answer questions about them and themselves and their things. And I’m totally gonna look at you now, Butcher, and say Who do you identify with?
Matt Butcher: Well, in the second book, there were the pods who just run around and carry stuff around until they die. That feels like me, at least today. Probably, you know, when I wrote the original story, the sort of background in my mind was, you know, how do I— how would I explain to my own kids what Kubernetes is? And at the time, my daughter’s favorite animal was owls, which is where Captain Kube came from. And so I guess that’s probably the character that I associate most with because, you know, in my mind originally, Phippy was, you know, my daughter saying, what is it exactly that you do, Dad? And me being like, well, this is what I do and I’m trying not to make it sound boring for you.
Bridget: [00:35:23] All right, Farina, you wanna give us your insights?
Matt Farina: So I probably identify with Phippy and there’s 2 reasons for that. One, one of my daughters, giraffes are her favorite animal. In fact, I actually had to sew an ear back onto a ratty old one earlier this week. But the other reason is, is I have a secret that a lot of people don’t know. I used to do a lot of PHP work. And so Phippy being a PHP application still kind of pulls to me. And I know I’m not the only Matt on this call who’s done a lot of PHP.
Matt Butcher: I was wondering if you were gonna out me at the end of that.
Karen: Yes.
Matt Farina: Yeah, sorry, I already did.
Matt Butcher: Yeah, yeah, actually our first working experience together was doing Drupal development, Matt and I. Yeah. And everybody got us confused then too. They did.
Matt Farina: You’re quite distinct. We weren’t so distinct this winter when I also had a beard. Yeah, so I do identify with Phippy because of that history of touching that language.
Bridget: [00:36:25] Okay, I love it because this is actually perfect. Since Goldie is the character who’s left, and I have 2 reasons to identify with Goldie. One, I went to the University of Minnesota. Their mascot is Goldie Gopher. Goldie Gopher is terrifying because it’s literally a person in like a human-shaped sized gopher costume, and it was giant, and it would like come up to you sometimes on the quad and want to like take pictures with it. It was just— yeah, so I was avoiding and terrified of. Then when I joined the Cloud Developer Advocacy team that I was originally on at Microsoft before I became a PM, I was mostly with Ashley McNamara and a whole bunch of other Go people. Suddenly, everything was all about Goldie, and I’m just like, what?
Matt Butcher: No.
Bridget: Oh, it’s sweet. It’s adorable. I actually love it. That made me happy. Also, So little and blue and adorable. So, I think we love all of Fifi and their friends, which is sweet. And okay, we gotta end, you always gotta end with call to action. Where, and we’ll put links in the show notes, where would all y’all recommend people go and check out and learn more?
Matt Butcher: [00:37:43] Helm.sh is the number one place. And one of the things that we are, and Matt Farina, I know, is passionate about this, so we’ll probably mention it, One of the things we are very much trying to do now is to increase the accessibility of our documentation. If that’s something you are passionate about, that is a great place to dive in. You don’t even have to know anything about Helm when you start, because it’s basically— you read the documentation, learn it for yourself, and re-express it in languages and ways that will appeal to a broader audience.
Matt Farina: I guess the next one that I would say is, if you’re looking for charts, go to hub.helm.sh, because you can find charts that people have created, both ones that are part of the community and those created by other organizations who are sharing and managing them themselves.
Bridget: Karen, what do you think people should check out?
Karen: Check out our Twitter account. It is @helm-pack for the most up-to-date information whenever we do updates, things like that. Yeah, it’s a more real-time version than The official stuff that you might want to look at would live on at the helm.sh blog.
Bridget: [00:38:49] Just to wrap up, I’m going to tell people, head to arresteddevops.com/helm-community for this episode’s show notes. Visit arresteddevops.com/itunes and leave us a review in the iTunes Store if you want to help other people find the podcast. Side note, I have no idea how that works. I’m guessing they must have some kind of algorithm that waits if people have been reviewing it lately. But wait, do they have to be many-starred reviews, or do you show up if you’ve been getting a whole bunch of 1-star reviews? I don’t know. We’re also on Spotify and iHeartRadio if you’re into those. Thank you so much to Matt and Karen and Matt for joining us today.
Matt Butcher: Thanks for having us.
Karen: Thanks, Bridget.
Matt Farina: Thanks for having us.
Bridget: Excellent. I’m Bridget at Bridget Krumhout. This is Arrested DevOps, and remember, there’s always DevOps in the banana stand.