Brigade with Kent Rancourt

Kent: [00:00:00] We weren’t going to just be talking about Kubernetes, and yet we’ve said Kubernetes so many times.

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. Rootly helps engineers manage incidents directly from Slack without ever needing to leave the tool. They handle all the boring and tedious manual work during incidents, like creating channels, looping in the right people, and acting as your scribe to document that ever-important timeline. Companies from 20 to 2,000 manage hundreds of incidents daily on Rootly. It’s super simple and easy to use. You can install it in 5 minutes or less. Visit rootly.io to learn more and mention Arrested DevOps for $1,000 off when you book a demo.

[00:01:05] BridgeCrew is the all-in-one cloud security platform for developers. They automate and embed security throughout the entire development lifecycle so you can streamline your DevSecOps toolchain into one solution. By integrating infrastructure as code security and compliance into your version control systems and CI/CD pipelines, BridgeCrew empowers you to find, fix, and prevent cloud misconfig faster. Get started with BridgeCrew for free at arresteddevops.com/bridgecrew. The role of a developer or engineer has evolved into a security-first mindset. The ability to confidently build and deliver your software assets across the globe while also avoiding supply chain threats is a priority for organizations to remain successful. Cloudsmith is software supply chain management for modern DevOps practices. They provide a single source of truth for all software assets while integrating with the package formats your team is used to. With a focus on securing your software supply chain, Cloudsmith is truly at the heart of your DevOps ecosystem. To learn more and receive a firsthand look at their solution, please visit arresteddevops.com/cloudsmith.

[00:02:18] For once, I’m not bringing you an episode on Kubernetes. Or at least not just Kubernetes. Kent, would you like to tell our listeners a little bit about yourself and what this Not Just Kubernetes story is about?

Kent: Well, sure, Bridget. Thank you for having me. A little bit about myself. I’m Kent Rancourt, a senior engineer at Microsoft, and some other non-work things that I do. I’m a dad. Martial arts instructor, a comic book nerd, and a Lego maniac.

Bridget: Um, there’s a lot there that we’re gonna need to unpack. Um, like for example, why is Lego not pluralized Legos? Is this just some sort of European thing? Or I always feel like when I want to talk about Lego TM, I’m doing it wrong.

Kent: Yeah, I, I feel, I feel like anytime I talk to somebody about Lego, they They, they, they offer me that factoid and they say, hey, did you know that the plural of, of Lego is, is Lego? And I’ve heard it so many times now.

Bridget: [00:03:27] Yeah, but like, I just don’t understand why. Is this like a collective noun thing? Or like, what is— is Lego Swedish?

Kent: Uh, yeah, uh, I forget. Uh, I can’t remember. I can’t remember now. Anyway, Finland, maybe, maybe. Yeah, they— although they have a big headquarters right, right near me here in Connecticut.

Bridget: Huh. Okay, so yeah, so you’re Connecticut-based and you have opinions about the Kubernetes adjacent ecosystem. And what is this Brigade project that we’re going to talk about here?

Kent: Yeah, so we’re going to talk about Brigade and I’ll give you a little background on on Brigade. So the tagline for the project is event-driven scripting for Kubernetes. So we said that we weren’t talking just about Kubernetes today. And we’ll, you know, we’ll get into why this is not just Kubernetes. But a little background on how the project started. I think it’s actually a very interesting story. So I came from a startup called Deus, which, which some of your listeners may have heard of. And we were acquired by Microsoft back in, oh, I don’t know, it must have been 2017. And one thing that we used to do at Deus, we had our annual offsite because we were largely remote and very distributed. And once a year, we would get everybody together. And something we did a couple times, 2 consecutive years, we did this kind of shark Tank exercise where, you know, it was like a hackathon, but you didn’t really have to produce anything more than an idea and like maybe a very, very simple, low-fidelity, you know, proof of concept. So, so 2 consecutive years we, we did this exercise. And the first year we did it, the winner was Helm. And the second year that we did it, the winner was Brigade. Helm and Brigade both came out of the same process at Deus. The process was kind of making this comparison of Kubernetes to an operating system, which is kind of a popular-ish comparison to make, because if you stop and ask, well, what is an operating system? It’s, it’s the program that once it’s loaded into memory, you know, manages all the other programs, all the other processes. And Kubernetes is very much the same thing. It’s what you put on your cluster to manage the rest of the cluster. So with, with this comparison, between an operating system and Kubernetes, we started asking ourselves, you know, what are some things that, you know, a traditional operating system that you’re used to, you know, macOS or Linux or Windows, what are some features or amenities that you have there that don’t exist yet in Kubernetes? And how can we close that gap? So with Helm, gap they were closing was, well, Kubernetes doesn’t have a package manager yet. And with Brigade, the gap that we were closing was that Kubernetes did not yet have some kind of scripting environment.

Bridget: [00:07:10] Quick sidebar, because you mentioned the Helm origin story, and I happen to know that it had a very different name at the outset. It was called Kate’s Place. And then it ended up getting the Helm name. So I’m curious, if you, if you ever had a different name for Brigade or other, alternately, maybe at the end of this pod, I’ll ask you, what would the quirky alternate name be? You could think about that one.

Kent: I’m not, I’m not, I’m not aware of there ever having been an alternate name for it. There was no name attached to it when it was pitched. But I’ve always thought that with Kubernetes having, you know, nautically themed names for everything. I’ve always thought that Armada would have been more appropriate than Brigade. But, you know, we’ve got enough name recognition now that I think we don’t want to go mess with that.

Bridget: Oh, yeah, totally. But it’s just kind of funny to think. I think for our listeners who are familiar with Kubernetes, they’re very familiar with this control loop structure, or just like, hey, we’re gonna reconcile desired state, we’re gonna get to the desired state. Great. We’ve defined everything, so much YAML. Oh, God, Oh my God, I’m drowning in YAML. Now we have everything we want, also YAML. How is the Brigade experience different from what people would’ve already been doing? Like, how does, like, you’ve given us the concept of what it is, but like, how does it look? What is it like?

Kent: [00:08:39] The thing to emphasize with Brigade is that it’s event-driven. So it’s not just a scripting platform, and it’s an event-driven scripting platform. And probably, you know, going back to the operating system comparison, Probably the best comparison that could be made, I think, is— I don’t personally use it, but I think it’s AppleScript or ActionScript or something like that. You know, where— because that’s very event-driven. You know, it’s like, you know, when you make this gesture, run this script. You know, that sort of thing. That’s the thing to emphasize with Brigade is that it’s very event-driven in nature. It’s a little bit different from what people may be used to with Kubernetes because it’s not simply declaratively saying, hey, do this and go reconcile it. It’s a very different model. It’s a model where something happened, now I’ve got to do something. An event occurred, and now I have to handle that event.

Bridget: [00:09:48] I think that definitely meets a need that people who have started using Kubernetes might be saying to themselves, oh, was trying to hack something together to accomplish that. I need to do that. And of course, the Kubernetes ecosystem being as it is, there are plenty of projects out there that do some overlap of this sort of thing. If somebody is evaluating Brigade or just figuring out that they need to do something with events, can you give us a few of the highlights or decision points that might help someone understand if Brigade is right for them?

Kent: What I find it’s very useful for is for just, you know, doing work in the background. It’s, you know, it’s— they are your minions, right? You know, there is a little bit of a misconception that Brigade is a CI/CD platform. And it’s not. But it happens to do CI and CD very well. So, I’m gonna use that as a convenient example. Because that’s actually the way that we the Brigade team actually use it quite extensively is we actually have it tied into GitHub. So, whenever we open, for instance, a pull request, that’s an event. That’s something that we can respond to. And so, when somebody opens a pull request, we actually run our build and all of our tests and everything and send results back to GitHub. So that’s one example of the sorts of things that you can do with it.

Bridget: [00:11:24] That’s really interesting because one of the reasons we’re chatting is because you have Brigade v2 coming up. And so I’m immediately thinking, oh cool, all right, you’re drinking your own champagne. We’ll go with that instead of dog food, why not? But if you’re testing Brigade with Brigade, but you’re also in the process of building a v2, does that mean you’re testing Brigade original recipe with Brigade original recipe? Are you testing everything with Brigade v2? Kind of give us a sense of what’s going on here with your step into v2, and then even why is there a v2 that is different?

Kent: So I’m going to answer the last question first. Why is there a v2? Now, I guess, is the point where we address the fact that we said we weren’t going to just be talking about Kubernetes, and yet we’ve said Kubernetes so many times in this conversation. So, so, so that’s why there is a V2 that, that we’re working on is, you know, V1 was very good, but I would still call it a minimal viable product. And it was very, very lightweight. Lightweight is good. Lightweight is good. But there, there were some consequences that, that came along with how lightweight it was. So there was, for instance, no API. All of the persistence, anything that got stored anywhere, it was just a Kubernetes secret. Now, how were Kubernetes secrets created? Well, and when I say everything was a Kubernetes secret, I mean every event that Brigade responded to was represented as a Kubernetes secret. How did those secrets get into your cluster? Well, Either it was created by a user typing from the command line, hey, here’s an event, go do something, or it came in through a gateway. Gateway kind of bridges the gap between external systems like GitHub and Brigade. So how did they get their secrets into your Kubernetes cluster? Well, they were just talking directly to Kubernetes. There was no Brigade API. Now, the consequences of that are that you, Bridget, if you were using Brigade 1, you had to have credentials for the Kubernetes cluster. You had to have direct access to the Kubernetes cluster. Now, if I’m the operator who owns that cluster, I’m not giving you that unless I know, unless I know that you’re a competent Kubernetes user.

Bridget: [00:14:09] So, so there’s barriers there that don’t need to be there necessarily.

Kent: Yeah, it was a very high bar, um, a very high barrier to entry because you kind of had to be competent with Kubernetes to get some value out of Brigade. But we knew that it didn’t have to be that way. We knew that people who really didn’t know much about Kubernetes, or maybe knew about Kubernetes, but just like nobody was forking over the credentials to a cluster, you know, we knew that those people could get value out of Brigade. And so something we set out to do with v2 was to abstract Kubernetes away from the end user, to the greatest extent possible, so that we lowered that barrier to entry. And what, what I like to say is that we have gone through this subtle transformation of being an event-driven scripting platform for Kubernetes to being event-driven scripting parentheses for Kubernetes. So Kubernetes is an implementation detail now, and we use it to get the work done, and that’s it. So that’s, so that’s why you, you teased at the beginning that we were not just going to talk about Kubernetes today, because we’ve, we’ve tried our hardest to make it fade into the background and make it not something that the end user has to deal with.

Bridget: [00:15:48] And this, of course, opens up so many questions about like, huh, if Kubernetes is a detail, does that mean that Brigade can be used, or maybe in the future will be used, on different orchestrators or in a Kubernetes-less environment? A Kubernetes-free environment, if that’s how you feel?

Kent: That’s a great question. There are no plans to do that at the moment, but we are architected such that that is a possibility in the future if it becomes relevant. Don’t get me wrong, I love Kubernetes. But I don’t want to make the assumption that Kubernetes is going to be around forever. I don’t want to make the assumption that something better will never, ever, ever come along. And I would like for the project to be able brigade, that is, to be able to continue on into the future, even if 5 years from now there’s a much more popular orchestrator.

Bridget: [00:16:51] There’s also, of course, uh, spaces like, you know, Functions, etc., that people may be trying to figure out how do traditional— are they traditional by now?— orchestrators work versus, you know, uh, Functions versus any other thing that people come up with. People come up with a lot of things. And so I’m curious, as you’re, as you’re making Brigade as decoupled and future-proof as you can to make sure it meets its goals, like, what’s— that’s some big changes. And I want to kind of dive into what surprised you of— I mean, this is— you’re doing a major version, like with kind of a bit of a— not, I wouldn’t say pivot, but at least a rev of the approach. And I feel like a lot of our audience might have either lived through the fallout of or tried to make some of those decisions. Can you talk a little bit about how do you even decide to do that? And what, what challenges does it bring?

Kent: [00:17:58] Yeah, so that, that’s an interesting question. There’s actually a very very lengthy— I think it’s probably 20 pages or so— proposal that we put before the Brigade community before we actually started to undertake the, the V2 development effort. And, and it articulated, um, you know, in, in nauseating detail, um, all of the things that were not optimal about v1 that we couldn’t fix without breaking changes. So there’s basically a 20-page document, you know, justify— justifying why we were going to do all of the things that we were going to do. And abstracting Kubernetes was certainly not the— it was certainly not the only thing on that list. But a lot of the changes can be traced back to how tightly coupled we were to Kubernetes preview.

Bridget: [00:19:00] I’m curious, in the Kubernetes world, they call it a KEP. In the Brigade world, is it a BEP? I feel like you would need a cute cat mascot if that were the case.

Kent: Oh yeah, no, we are pretty light on process at this stage compared to Kubernetes or Helm. I think Helm does those now, right? Is it a HEP?

Bridget: It’s a HIP, actually. Helm Improvement Program.

Kent: Oh, it’s a HIP. Yeah, we’re pretty light on process still, um, you know, and that’s not to say that we aren’t, you know, very diligent and disciplined about how we do things. We certainly are. But I don’t, I don’t think we are, uh, at the point as a project where, um, we need to, to do that for everything. Um, but, you know, it was worthwhile to do it when we were talking about such major changes as we were, because it’s— because really v2 is a complete rewrite. Um, it— we started from scratch.

Bridget: [00:20:04] When you mentioned that you’re not at the place where you’re going to institute a lot of heavyweight process, but at the same time you of course do want to grow the community, can you talk a little bit about that? Like, how does community involvement in an open source project that people might stumble upon, realize it solves a problem for them, start using But what does that leap to and become involved look like?

Kent: You did ask previously about what were some of the things that surprised me, and community things surprised me, to be honest. And some, and some of it is, is, I would say, unfortunate. I think that there we had a relatively vibrant community going into V2. And, you know, certainly not to the extent that Kubernetes itself is, you know, if we had BrigadeCon, we’re not going to have 15,000 attendees. But, you know, we had a fairly vibrant community. And I think my observation, I think something that happened is people became aware that we were making this major shift that we were doing v2. And I, it seems to me that people have, community members have been content to kind of step back and let the maintainers handle it. And that kind of, you know, gives me the sads a little bit. You know, I want to bring our community, you know, back together and start rebuilding on top of this better platform that we have now. And I think the project has reached a point, you know, we are in beta right now, and we have a lot of different integrations that we’ve built as well, which are also in beta, or some are in alpha. But we we have reached a point where things are pretty stable. And we really think it’s safe for people who, you know, might have been intimidated by the large pivot that was going on. We think it’s safe now for them to come back and get involved. And I really want people to get involved because we have something I’m very proud of. We’ve made it much easier to build integrations with Brigade. It was very tough to, you know, write new gateways and things, you know, sources of events. It was tough to write those for v1. For v2, we have such a rich and powerful API and language bindings for those APIs. So we currently support Go, and JavaScript and TypeScript, and we have Rust, a Rust SDK that’s currently in the works. So we have made it easy for people to come along and with just a small amount of code, write interesting things that integrate, will integrate Brigade into different sorts of workflows. It’s a great time right now for you know, community members to get involved or get involved again and start building some cool stuff. And I’ll say that, that we have some awesome new swag that we’re working on, and I would be really happy to set that aside for anybody who wants to help us kick the tires or anybody who wants to contribute some interesting integration.

Bridget: [00:23:33] Now, that is exciting because I got to tell you, in this several-year period of our apocalypse, the, uh, the swag, um, count has been way down. So yeah, it’s dried up, right? Because, right, yeah, no one can go to events. So I’m curious, um, I know that, uh, Brigade will have, um, at least I think Brigade will have a virtual office hour during the upcoming KubeCon North America, and I think that you have project meetings, maybe, dot dot dot. So like that, I would love to hear if people want to get involved, which avenues are their on-ramp to get to know where in the codebase or where in the project or like where should someone start if they are like, maybe I, hey, I did kick the tires on this, I want to use it. Now I’m confused because I don’t know if I should open pull requests because I guess there’s a different v2 branch somewhere. Where would you recommend people get involved?

Kent: [00:24:34] I’ll highlight some of the, the ways that people can get involved. We have a Slack channel on the Kubernetes Slack, so there’s a Brigade channel over there. I hang out in there, and so do other maintainers. So it would be great, you know, for people to show up there and ask us questions or show us something cool that they did. And of course, find us on GitHub. And, and you’ll— I know you’ll put all these links in your, your show notes. The one thing that I do want people to know about finding us on GitHub, and you kind of said it already, is that the V2 work is happening in a V2 branch. So if you do come and find us on GitHub, just know that V2 work is progressing in the V2 branch. So just make sure you’re looking at the right thing.

Bridget: From the point of view of you’re a CNCF project and you’re not bound to any specific release schedule, but maybe I can have breaking news on the podcast. Do you have any word for us about when does v2 come out? When do you have exciting CNCF next steps? Like what else is coming down?

Kent: [00:25:50] Yeah, we don’t, we don’t have a specific release date yet. I feel like it’s like all my favorite TV shows, I periodically go and I Google when is season 4 of XYZ coming out. Then I always see the disappointing news that no date is set yet. Yeah, we don’t have an exact date yet, but it’s, it’s, it’s definitely happening in Q4 of this year. We’re pretty, we’re pretty stable at this point. And we are just continuing to work on stability and integrations. You know, feature development is, is pretty much done. We are avoiding breaking changes at all costs at this stage. It’s kind of like Kubernetes. When something becomes beta, we start treating it as— we start being concerned with backwards compatibility at that point.

Bridget: But you’re not going to make anyone fill out a production readiness review?

Kent: No, no. And also, I think it helps, you know, because I did say that we’re light on process for the time being. We are a CNCF sandbox project at this point. We would, of course, course, like to graduate to the incubator at some point. But besides being contingent on V2 going GA, I think we do need to do a lot more community building to make that happen. And something else I’ll mention, because I am making a plea here for people to come and play with us, right? You know, one thing I’ll also mention is that we’re looking to diversify the ranks of our maintainers, you know, not just in, in terms of gender or race or anything like that. I mean, certainly those, but also just in terms of what companies our maintainers represent. So at present, most of our maintainers are employed by Microsoft. We have a few that are not, but they’re also not particularly active currently. So we are looking to grow the roster of maintainers. So getting involved right now is a really good way to get your foot in the door if, you know, you want to get that onto your CV that you’re, you’re the maintainer of a CNCF project. So, you know, like I said, come, come play with us. We would, we would love to have people come and, you know, contribute, ask questions, make feature requests, you know, and it’s not just coding either. You know, anybody who can, you know, help us grow the community, you know, that’s, that’s a skill set. And, you know, frankly, one that I don’t have, you know, you’re very good at things like that. My PM, Karen, is very good at things like that. And, you know, there’s a lot of ways that you can— that people can contribute to a project without writing code. So whatever people can contribute, we would love to have them.

Bridget: [00:29:02] I suspect that your answer to, hey, how can people learn more about Brigade, is going to come right back to that.

Kent: Oh yeah, absolutely. You know, I mean, besides our blog, And besides our documentation, and, you know, I already mentioned GitHub and Slack, but yeah, just come find us, come talk to us. We would love to talk about Brigade.

Bridget: Just to make sure we cover it, because I know we talked about it a little bit before, but like, if there’s a pattern that you mentioned earlier that people might find interesting or want to learn from, about using Brigade to build Brigade. Can you talk a little bit about where people would look in your GitHub to see how that works?

Kent: Really, if you, if you look at, I think, most of our projects at this point, most of the repositories under our Brigade Core GitHub organization, I think in most of those you would find a .brigade folder. And in there you will see project definitions and scripts that we have used for the sake of building those projects using Brigade 2.

Bridget: [00:30:22] All right, so you mentioned that, of course, we’ll put links in the show notes to the GitHub organization and the repos. Is there a specific repo or repos? I know there’s a lot of repos under the the Brigade core organization, is there a specific one that you’d highlight that people should look at for the best place to jump in?

Kent: Oh, sure. You know, probably the, the just, you know, plain Brigade, just Brigade is probably the, you know, that’s the main repo. That’s where, where, you know, most of the magic happens. But, you know, we do have a lot of integrations that we’ve developed mostly in the, in the form of gateways. So again, a gateway, the role of a gateway is to bridge, you know, the gap, to bridge the divide between Brigade and some upstream source of events. So, you know, we’ve created gateways for GitHub and Bitbucket and Docker Hub and Azure Container Registry and CloudEvents, and I’m working on one for Slack. Currently, I’m gonna do one for Teams. So we, we have a repository for each of those as well, and each of those is in and of itself an interesting project to look at.

Bridget: [00:31:48] Oh yeah. So if somebody already has an interest in or is trying to do their own integrations with one of those, then diving into the codebase for one of these specific integrations would be interesting and valuable.

Kent: Yeah, and most of them are pretty simple too. So, you know, by all means, if you want, go clone one of our gateways and slice and dice and do what you want and make it work with another system. And, you know, we would love to have people do stuff like that.

Bridget: All right, so that’s a roadmap for people. You’ve gotta become a contributor, take over the world, possibly help with the process of taking Brigade to incubating in CNCF. Anything else?

Kent: No, I don’t, I don’t think so. I, you know, I’m just really super excited about the, the work that we’ve been doing, and I’m really super excited to, to, you know, start, uh, growing or regrowing, um, this community and having, um, you know, more people, you know, come out to play and have fun with this platform. Um, and, uh, Yeah, I’m just, I’m just super excited for all of this. It’s a really good time to be working on this project.

Bridget: [00:33:04] Kent, where else would you recommend people go to follow your work, to catch up on the project if they want to dive in now that they’re all fired up and excited?

Kent: Yeah, you know, definitely GitHub and Slack are the best places to find us. I would love if people wanted to go star and watch our repositories, that would be great.

Bridget: So, smash that button, like and subscribe.

Kent: Smash that button. But yeah, really, this is an open invitation to come find myself and the other maintainers wherever we may be. You know, find us, talk to us, because, you know, we’d love to hear from you.

Bridget: Well, that does it for our time. So head over to arresteddevops.com/brigade for this episode’s show notes and contact info for Kent. Visit arresteddevops.com/itunes and leave us a review in the iTunes store if you want to help other people find the podcast through some sort of algorithmic magic. We’re also on Spotify and iHeartRadio if you’re into those systems. Thank you so much, Kent, for joining the podcast today.

Kent: [00:34:17] Oh, thank you, Bridget. This has been wonderful.

Bridget: I’m Bridget at Bridget Krumhoop. This is Arrested DevOps, and remember, there’s always DevOps in the banana stand.