 Well, hello, everybody. I'm not sure if that was quite the right bumper as we went in. But this is actually the KB Insider show. And we are just starting. We air the show about once a month. And we so we normally do I think it's the last Tuesday of the month is the normal idea. But the goal of the show is to talk to various people who are what we refer to as insiders in the Kubernetes community. And the reason we like to talk to them is because it gives us a good idea of what the what the people who are actually doing the work are thinking is going to be happening soon in the Kubernetes space. And that way, as a audience member, as a, you know, attendee or whatever here, you can try to get a better sense of what will be happening so that you can have a better sense of what you will be doing soon. So but we always like to kick it off with first, you know, I'm Langdon White. I am currently a professor at Boston University. I'm formerly with Red Hat. And I've been involved in the kind of container space for many, many years now. And I'm joined here with Steve Spiker. And I'll let you introduce yourself. Yeah, thanks, Langdon. As mentioned, Steve Spiker, I work at Red Hat. I've been a product manager and then the Kubernetes space pretty much since 2015, I'd say. So I've seen a lot of changes. I'm the director of the developer tools space and a CNCF ambassador. So help run a local eatup here in the Research Triangle Park area in North Carolina. Nice. And our other regular on the show is Mina. And I'll also let her introduce herself before she helps us out with the news. Yeah, definitely. Hi, everyone. I'm Mina. I'm pretty sure if you've seen this show before, you've seen my face before, like Langdon said, we're here once a month. Although, right now, obviously, this is a little bit out of our usual timeline due to the holidays and Thanksgiving. So this is actually our last show of the year. We're very, very excited to be with you guys. I work at Red Hat as well. I'm on the products marketing team. And I do KBE news on the KBE website. So I'm excited to share you guys share with you guys some highlights from this past month. Should I go ahead, Langdon? Yeah, why don't you give us an update on the news? Sounds good. So let's start out with some announcements from the Linux Foundation. KubeCon North America 2022 will actually be on October 25th and 28th in Detroit, Michigan. I will be putting all the links to some of the announcements or the articles that I mentioned here so you guys can always go ahead and look at those after after I talk. And then one important one is that KubeCon EU CFP closes on December 17th. As a reminder, KubeCon EU will be an in-person event from May 17th to May 20th. So don't forget that submissions must be received by 11.59 p.m. Pacific time on Friday, December 17th. With that, we can highlight some of the articles that we shared on KBE news this past month. With Fintech on the rise, we have an article talking about how Kubernetes simplifies the operation of Fintech apps. Currently, Kubernetes is used by over 45% of companies. The convenience speed and reliability of this solution has been appreciated by finance companies like HSBC, Capital One, Starling, and ING. And there are some of these are the reasons why large corporations and Fintech startups choose Kubernetes. One, data security and failsafe operations. Two, automatic and safe scaling. Three, fast and economical operation of apps. Four, no downtime and convenient interface. Five, simpler to develop, update and rollback apps. And then we have Jonathan Kaphson discussing the nine open-source developer tools for Kubernetes. The community surrounding Kubernetes is constantly sharing new tools and features to help developers run, test, and code cloud-native services within Kubernetes. While 2021 was a massive year for this kind of involvement, there's definitely a lot more to come. Here are some additional emerging open-source tools you should check out for testing, software delivery workflow, monitoring, networking, scanning, and service mesh, among others. Cube monkey for testing. Devtron for software delivery workflow. Prometheus for monitoring. Argo CD for Kubernetes delivery. Calico for Kubernetes network. Istio for service mesh. Cubescape, Chekhov, and Trivi for Kubernetes scanning. So again, while 2021 was a pretty big year for open-source extensibility with Kubernetes, a high number of high-quality products, there's still plenty of opportunities for new innovation in the future. And then according to Matt SA in his article, enterprises get closer to the App Store experience with Kubernetes and GitOps. The big enterprise problem isn't running hundreds of apps across multiple clouds. The big problem is running the same app consistently on just one cloud or data center. This is definitely a really interesting opinion piece, so definitely go and check it out. I had a really, really good time reading it personally. And then we have a couple announcements. Hamburg-based, Kubermatic, a company that automates operations of Kubernetes clusters across multi-cloud on-prem and edge environments, announced that it has raised about $6 million in its seed round of funding. I think it's definitely very cool to see smaller startup-stage companies innovate in this busy space, as we have seen over the last couple months and over the past couple years as well. And then as always, we cannot close out this new section without mentioning security somehow. Kubernetes default configurations don't always provide optimal security for all workloads and microservices deployed. Plus today, you're not only responsible for defending your environment against vicious cyber attacks, but also for meeting a wide variety of compliance requirements. So we have an article that helps you understand Kubernetes compliance and security frameworks. Jonathan Kaftan examines five major frameworks and how they can help your business use Kubernetes more securely. Again, security are the biggest issues that we've seen lately. So definitely recommend you to go and check this article out. And while compliance may take some upfront work, the payoff in resilience and long-term business continuity will be worth it. In many cases, organizations discover additional benefits, such as optimization and eliminating inefficient processes and services. I do want to end here with a blog post from our guest today, Kastlin Fields. As I mentioned earlier, KubeCon EU CFP closes on December 17th. Kastlin has been part of nine sessions at six different KubeCons and served as a track chair and CFP reviewer. In this post, she goes over things she thinks you should know about the KubeCon CFP. This is a really timely post and I highly suggest you go check it out on her blog. I'll be posting all the links, so I'll make it easy for you guys to review some of the stuff I highlighted here. But thank you and back to you and back to you, Langdon and Steve. Thanks, Mina. As always, it's a good idea to try to keep up with the current events. And I know for me it can be whirlwind to try to keep track, plus obviously, like many of us, we do a lot of things that are not just Kubernetes. And so keeping track of this particular space, I think it's really helpful to have kind of a review there. And a phone that I didn't even know worked is currently ringing, so that's kind of annoying. All right, so today, we would like to welcome our guest, and let me see if I can... Oh, there it goes. Okay. We'd like to welcome our guest, Kastlin Fields. And thank you, thank you. And... Hello, welcome. Thank you. As kind of a pretty strong member of the community and pretty visible in that community, we like to talk to you about what's going on. And in particular, I think we could kind of start off with, I know when you were at KubeCon, you gave a keynote about multi-cluster. And obviously, we would recommend people going and checking out the video of the recording. But I would like to ask, why are you interested in that space? In general, why is the Kubernetes community kind of interested in multi-cluster? What's the big deal there? Yeah, so also, I should probably do a little bit more introduction. Mina already introduced me to some extent, but I'll say it again. Hello, everyone. Sorry, that phone really threw me, my bad. All good, no worries. I know how it is. It's also 8 a.m. for me, so... But hello, everyone. I'm Kastlin Fields. I'm a developer advocate at Google Cloud where I focus on Google Kubernetes Engine as well as open source Kubernetes. So I'm a contributing member of the community and as part of contributor comms in the upstream... Well, gosh. We call ourselves a couple of different things, contributor comms in the upstream marketing team, which is part of the contributor experience team. Anyway, that being said, I also made a blog post of my KubeCon North America keynote. So if you haven't seen it and you'd like to check out the content, you can check it out there. And I also have the link to the recording on there. But as you said, it's about multi-cluster. And I think from a variety of perspectives, that's an interesting topic to do a KubeCon keynote on. From the contributor community's perspective, it's interesting because... I mean, Kubernetes came about in 2016, was the very first commit to the open source repo in GitHub. June 14th of 2016 or something like that. I have it on my wall usually, but I took it down today. And so it hasn't been around for all that long. Like it's been around for a few years, but it's been steadily growing. The contributor community has grown immensely, of course, the user community has grown immensely. So for the first several years that Kubernetes existed, it was first this new technology that there was some buzz about, and there were these early adopters. And now it's gotten to a point where there are a lot of companies using Kubernetes in production today. And Kubernetes is a tool for running workloads and applications at scale. So a lot of these companies are very large. And when you have companies that are very large, just one Kubernetes cluster will not do. So early on in Kubernetes existence, multi-cluster wasn't that big of a deal because it was already handling... You could handle a lot with a single cluster. But now with these really large companies, often very distributed companies using Kubernetes, there are a variety of reasons why they need to have multiple clusters. And so that makes them ask, how do I manage all of these multiple clusters? Where Kubernetes is a tool for managing the applications? Now, how do I manage the clusters themselves? So that's why multi-clusters exciting right now is that a lot of companies are actually getting to the point where they need multi-cluster. So from the open source perspective, more folks are starting to get involved with contributing to multi-cluster workloads because more companies need it. There's more information, more customer use cases to work off of to build tools for multi-cluster. And then from the user perspective, of course, a lot more people are using it. So they need those tools. So that was, I think, a very timely thing to talk about in the Kubernetes. Yeah, definitely interesting. And particularly, I think the challenge with multi-cluster rate is that you don't always want it to feel like multiple clusters, but then sometimes you do. And so I think that's a particularly challenging space. I think that's been an interesting model. I think it also plays into a lot of these ideas of Kubernetes as a control plane. We've actually talked about it on the show before, but you've also seen various people in the community kind of talking about this idea of Kubernetes can maybe be a backplane for lots of different things. So I think it's a really interesting and, as you say, kind of timely topic. I know, Steve, did you want to ask more about the multi-cluster? Yeah, I mean, I think it's a really interesting space because we've done a lot of experience in large clusters, but the way we hit limits with our customer base is, I think you talked about it in your keynote as like 10,000 nodes within the cluster. But I think back like in the news around GKE and running Pokemon Go, and it's like one application scaled really large, where we get a lot of tenants on our cluster's way typically run, so our customers run it. And so the scale kind of breaks down more because of a number of namespaces, a number of secrets per namespace, and SCD limits, and the watch as all the controllers just tend to struggle a bit when you get to a certain size. So I guess I'm not asking a question, but I was just kind of curious your thoughts, too, when you've seen that explosion of where it's a multi-use kind of cluster where I think you talked about the importance of segregation also for security reasons between those organizations. So I don't know if you've you've run into much about that where it's packing a bunch of people, if you will, into a cluster and then the problems that's caused. Yeah, in my keynote, I mentioned a few different use cases where companies come up against this and they need to have multiple clusters. And I love that you pointed out several that you've seen in real life. So one of them was multiple regions or environments. If you're running in different regions or environments, then of course you're going to have to have different clusters. And one of them was this security consideration of if you have multiple tenants that you need to keep separate, what tools do you have and at what point do you have a separate cluster? Because in a regular, just a single Kubernetes cluster, there's a concept of namespaces and role-based access control. And by using namespaces and role-based access controls together, you can create a pretty solid structure for multi-tenant use cases, a lot of them. But there are still some cases where businesses feel more comfortable just having workloads on separate clusters, sometimes for compliance reasons, sometimes for extra security, just having the whole cluster boundary as a security boundary can sometimes just make things simpler and sometimes you need that. So there are a variety of security reasons why folks approach multi-cluster. And like you said, it's about managing all of these Kubernetes clusters together. I often think about it as Kubernetes for Kubernetes because people come to Kubernetes as a management tool for managing applications that scale across many different computers of varying sorts. And so having a concept of that but for whole Kubernetes clusters is often what people are looking for, I find. Yeah, that's interesting because one thing I was going to ask about is one of the coolest names I think of a sub-project that Kubernetes was Uber Nettys early on, what they did the first kind of wave at multi-cluster. And then there was cube fed too and so I was kind of curious because there's been a lot of learning that's gone on in the community about what to do with multi-cluster and how do you think those lessons have played into the current approaches of multi-cluster? Yeah, the state of the art. I used to talk about cube fed quite a lot because that was, I think it was a pretty interesting attempt by the community to address this challenge. But when I interviewed the chairs of the special interest group for multi-cluster use cases within the open source project, the folks working on it there told me that cube fed was mostly informed by what the contributors thought was going to happen when we reached this point where companies need to have multiple clusters and they need to manage multiple clusters. But when they created cube fed, that wasn't a big use case that they actually saw. So they didn't have good user data to build these tools off of. So cube fed was very opinionated and it made a lot of recommendations about this is how you do this and this is how you do this. But over time they found that those were maybe a little too rigid and they needed some different solutions to actually solve the problems that are happening with multi-cluster today. So in the talk I talked about a couple of different solutions that the folks in open source are working on. The main one is the multi-cluster services API, which is new and it is a API standard that the SIG multi-cluster is coming up with. The interesting thing about API standards is that they're not implementations. So this multi-cluster services API isn't something that's going to be in Kubernetes itself. It's something where you're going to have to be using some sort of environment that implements this standard that the open source group came up with. But the concept here is for different Kubernetes clusters to be able to share what services they're running with other clusters. So that you can log into one cluster and that cluster can know about all of the services it needs to know about even if they're running on a different cluster. And that gives you some really interesting capabilities, which pairs really nicely with something that the networking open source group, SIG networking within Kubernetes, has been working on, which is Gateway API. That's been around a little bit longer. There are more implementations of that, but it's also an API standard. So the concept of Gateway API, which I often here refer to as Ingress V2, which I find interesting, but the concept is basically to give users better tools for connecting their Kubernetes clusters together. So Ingress and Kubernetes is a tool for managing incoming traffic to your services from outside of the cluster. And so Gateway API takes that concept a bit further. It was pretty basic in the initial implementations of Kubernetes and Gateway API adds some additional tooling for managing the incoming traffic and also for managing the different types of, many, many different types of networks you could have for your Kubernetes cluster and for other Kubernetes clusters. So by working with Gateway API for managing networking, managing traffic and this multi-cluster services API for allowing a cluster to know more about what's going on in other clusters, we start to get a really nice solution here for multi-cluster environments, where you can actually do more things with managing multiple clusters that are not completely native to Kubernetes, but at least from the Kubernetes open source project designed for how they see it being used. Yeah. I mean, one of the things I think that is really, you know, kind of interesting about how we do development a lot these days, which is so much better than it was when I certainly got into it, is, you know, kind of the idea of, you know, approaching a problem once there are users who are actually experiencing that problem, so that you can kind of get feedback and actually build on and build what they actually are looking for, rather than, you know, trying to build something that you theorize that they may need, right? You know, I think a lot of this has to do with the technology changes, right? It's so much easier to, you know, kind of build something that's incorrect in Python and tear it down and build it again that has made that kind of style of development significantly simpler, but it really does change things, right? And I think that's part of why it's kind of important to kind of follow the, you know, the news, as it were, in, you know, your open source projects or whatever, because you, you know, people, it is adapting. There is no big massive roadmap for the next 20 years that says, this is exactly what we're going to build and how we're going to build it and what it's going to do. The other part that I think is interesting that you kind of alluded to is you have semi-competing options or implementations or whatever, you know, and may the best tool win, you know, which, you know, can be a little, you know, a little scary, you know, you know, thinking of like, Mesos versus Kubernetes, you know, a while back, for example. But there have been many, many others. But so that's another reason why kind of keeping tight with the community or, you know, and the project itself is a really good thing. And being honest within the community about what's happening, I think is also really important, you know, that you, you know, that it's not, you know, it's not some secret cabal making a decision, nor is it every solution is the right answer, right? It's that, you know, there's certain use cases and that kind of stuff. So I think that's a really, this is the multi-cluster stuff I think is a really important thing to watch, as well as the fact that I think that when you hear multi-cluster, I think a lot of people aren't thinking of what the Kubernetes community really means. And what I mean by that is like, you know, when you say multi-cluster, usually it just means like some, you know, interface or some UI or something that, you know, goes and triggers them independently. This, this seems at least like it's going for something more than that, right? It's more, it's in a sense more, not complex, but more sophisticated, maybe is a better word. And I think that's kind of, yeah, yeah, like, yeah, I can't think of a good, you know, English word for it. Yeah, that's similar. I was thinking through like the use cases around this networking, the gateway API, and it made me think, and I think Blaine did touch on it too, is like the choice of the community, because we heard some news about Istio and I started thinking people here are Istio in some of these cases and what that does, and it solves some multi-cluster mesh issues and people solve mesh there. And I don't know what you could say, maybe a little bit about the different use cases between the two, why they're different, how they come together, or I think that would be, that would be a, would help me. Yeah, they're not networking native people out there who would be interested in the year. I love that you made that connection between the gateway API and service mesh. It's not something that I had thought much about, but I talk about service mesh quite a bit as well. And yeah, there's a lot of kind of parallels there in this concept of managing Ingress as well as kind of managing the networking of your cluster and between your clusters. So I would say that service mesh, if you've ever tried to work with a service mesh, you'll be very familiar with this. They are pretty complex. I tend to try to avoid that, but I think with service mesh, it's hard to avoid saying that they're pretty complex. They have a lot of moving pieces and a lot of things. When I first started talking about service meshes, I thought of them as like, you've got your Kubernetes cluster that's running all of your applications and it's doing a lot of really nice management stuff. But once you start to get into it, you start to see these gaps of things that aren't really in scope for Kubernetes, things like observability is something that's kind of missing there and some Ingress controls like proxies, having a proxy there with your application that can maybe manage permissions for what can talk to your application at a more granular level, some logging and monitoring. So there's a variety of tools here that aren't really within the scope of Kubernetes, but you really need in order to run Kubernetes effectively. And so service meshes came in and they just kind of had all of these tools as part of them. And they were kind of trying to fill all of these gaps, which naturally made them sort of complex to understand and to use. So they're trying to solve a lot of different problems, I think, whereas the Gateway API is really focused on this problem of gateways and networking of making sure that things can communicate effectively. So it does address some of those challenges that I think that service meshes also addressed, but it's much more limited in scope is how I think about it. That makes sense. Yeah. Cool. So kind of maybe changing directions a little bit. But I kind of in the research for kind of doing the show, you have a lot of kind of involvement in kind of new contributor activities, let's say. And so what I'm curious about because I watched your panel from KubeCon, which I found interesting. And I also found my new favorite phrase from Kat Cosgrove. But I wanted to mention, so that's all about noncode contributions. Why do you feel like that's really important to Kubernetes? And or is it a gap? And why might do you think it's a gap if that makes sense as a question? Yeah. Yeah, that makes sense to me. So it depends on what perspective you're coming from, how you see noncode contribution. For the Kubernetes community, we have this gigantic project. It's one of the largest open source communities in the world, second only to Linux, I think. That's still the case. Yeah. Definitely in the ballpark. Yeah. Yeah, it's huge. And it's got this huge user base as well. So there's always new requests coming in. There's always new features that need making. But something that you might not think much about with an open source technical project like this is there's a lot of behind the scenes work that does not involve coding that keeps this project running. Some of it is creating documentation. That's a form of noncode contribution. For writing documentation, you have to get a really good understanding of how the project actually works. So that can be a great way to learn. And then also help others because you're contributing documentation back. There's also things like product management type roles basically that have to happen because there's a lot of different features of Kubernetes. There's these special interest groups which have chairs who kind of manage what's going on in those groups. But at some point you have to, like I'm part of the release team right now. There's a lot of noncode contribution in the release team because we have to, I'm part of the comms group for the release team this time. So for example, we have to create blog posts about here are the different features that are going to come out with the new release. Here's kind of an overview of what's going on with the release. There's a lot of communications that have to happen to make sure that the user community and the contributor community are aware of what's happening in the release. And there's all sorts of communications that go on in the meantime about changes and discussions that are happening in contributor communities. Maybe a new feature came out a while ago and nobody's really using it. Nobody seems to know it exists. How do we get people to know that exists? So I spent a lot of my time on communications and marketing type noncode contributions. So there's all of these different activities that have to happen for the project to be successful that don't involve code. And I think when you think about contributing to open source, that's not the first thing you think about usually. Yeah, I mean the documentation question I always think is really interesting. For many years whenever I was leading a dev team, if I got a new person on the team, their first job was to update all the docs for the onboarding. So usually somebody did a half-baked attempt at least initially. But then every time you get a new person, things are new. And because they're new to them, it makes a big difference. And there was a point that was made in the panel. I don't remember who exactly made it. But as a newcomer to the community, you have a lot of experience with not Kubernetes that you can help with things like communications, where you can say, hey, can you read this over? Does it make sense to you as somebody who is not embroiled in this all the time? Or docs as well, the onboarding content? I'm a big fan of that as well. And then what I think is interesting about it too is that non-code contributions doesn't mean you aren't a coder necessarily either. Is that when you're approaching a project or you're approaching getting involved in a community, even as a coder for many, many years now, one of the things I do look at is I look into the documentation, I look at the open issues, I look at who's involved in the project, I look at all these kinds of different things. And I try to give back there. For one thing, I spent too much time as a college newspaper editor, and as a result, I fix grammar by default. So I try to contribute in little bits as we go along. And I think it's really, really important whether you're a coder or not a coder. I mean, there's all these kinds of things that need to happen. One of the things I wanted to also kind of ask in a related way about that was it came up a few times, and I've heard it elsewhere as well, is that the Kubernetes community is very social compared to many open source communities. And could you elaborate on what that means? And why as somebody who is a consumer of Kubernetes, why does that matter to me? Yeah, I love that question. That's really fun phrasing too. I don't think I've ever heard someone refer to the Kubernetes community as social, but I think it's absolutely accurate and makes total sense, and I think people should say it more. So the concept here I think is, this actually reminds me, I was looking at the game awards last night, and one of the categories for the game awards is games where the developers of it, the creators of the game, are very engaged with the community and the community is very engaged. That's what kind of we have going on here with Kubernetes is the folks who are making Kubernetes the open source contributors. We have Slack, we also have the CNCF Slack that a lot of us are in. I have a lot of people who we chat with each other and we end up on the CNCF Slack talking about a Kubernetes issue or a price versa. So we were very communicative in that respect. We have all of these challenges, channels for the different special interest groups like contributor experience, networking, multi cluster, they all have their own channels. So if you had a question for the people who work on that specific thing, you could go to that channel and ask, and there they are. So that's really important for end users, but also we have our own blog. So for external communications that the Kubernetes community is just pushing out there, we have a blog, we have a Twitter as well for the Kubernetes project as a large, as a whole, both of those. We also have a Twitter just for the contributor community, for contributor news and what's going on in that community. So both from the end user perspective and from the perspective of being a contributor, we're always communicating in open spaces. Also everything we do on GitHub, of course, is open and available and you can look at it, all of our meetings, like SIG ContribX, even the steering committee of the whole Kubernetes project itself, a lot of those meetings are recorded and put on YouTube. If you ever want to know what happened and who was in the room when it happened, you can find out. Because all of that stuff is open and available and you can see it. So that's a great thing for end users because they can see what's going on and it's a great thing for contributors because they can see what's going on. Yeah, I mean, I think, you know, like you kind of raise a good point, right? It's like if you're not sure about what's going on or like why a decision was made or whatever, going back and actually hearing the argument, right, really can help a lot. Sometimes it reinforces the reason why you disagree with them, but it can also kind of educate the, give you a little bit of background and tell you why the choices were made and whether it's a good, you know, and maybe where it's going to go in the future. Because I think, rarely does it occur that when you make a decision, for example, to drop a feature, it's not that the feature is completely useless, quote unquote, as much as it is, the approach maybe isn't the right one or, you know, and so there's a plan to do something else, or as we were kind of talking about earlier, the users aren't there, so we're not getting good feedback on the feature. So we don't necessarily want to support it because we don't know that it's actually working, you know, then it gives you an opportunity as a user, right, to say, oh, wait, no, I am here, you know, please, you know, please bring it back or please let me, how can I contribute so that I can help you bring that, you know, feature or whatever it is back. Yeah, so I think I thought that was an interesting remark, like I said, I've heard it in kind of a couple different contexts. You know, I think one of the things going to your kind of your day job, right, as a developer advocate, I used to be a developer advocate at Red Hat. And what I think is funny is there's a book about developer advocacy that I'm not think I can't think of the name of right this minute, but one of the things it comments on is that while that role is kind of new as a job title, the role has actually existed for a very long time. And I know I played it in a lot of different projects, you know, well before I had it as a title. But I think Kubernetes, you know, kind of the CNCF ambassador community, as well as there's a lot of developer advocacy type people in the community, I think that has really increased that communication and that social aspect of it. Because you have, you know, developer advocates, generally speaking, are kind of good communicators by default, right. So as a result, I think that's really improved the communication within that community. And, you know, there's a number of other communities we can mention that, you know, don't have similar or have kind of the reverse challenge that, you know, but we won't talk about those today. Yeah, I was gonna, yeah, I was gonna notice because like the social part was an interesting way to phrase it too, because I think it goes a little bit to what Kassel has said, is the very welcoming, very helpful, very inclusive group. So it's like, that's the thing everyone feels welcome. So they're willing to feel more social kind of about it and as a way of not just going to it for the social aspects, but really, it's that really kind of feeling of community and belonging. So it's really been interesting to see what I've seen as everyone get involved in those that I follow. So I think it's really, and at Langdon's point, it's, you know, kind of refreshing from some of the other projects that have existed and how they've been run. And I think it goes to the early, the originators and the way they want to coordinate these to be accepted and grown. And so I think it's really stuck to its roots. So it's really been been helpful to see. And not trying to make a complete transition from there, but I think it might be a natural one is because of the call for paper things we talked about, and you're working towards, and that's that's that date's coming up as far as that deadline. And that's a great way for people to share their experiences, whether it's at any level, whether they're a lead in it, but also, you know, what that process is. I'm just curious if you have any kind of quick helpful hints of what it means to write a good abstract and that whole process. Absolutely. And I want to also make a comment on something you were saying there. I recently read Nadia Eggball's book on open source working in public, which is here on the shelf behind me, the red one. And she makes a really great comment in there that the reason that a lot of folks don't contribute is not because it's technically difficult or they don't have the skills. It's social fear. They don't want to do something wrong in this community that exists around the project. I think there's millions of eyes watching them make a mistake. Exactly. Yeah. And that's something we talk about in the panel as well. My advice in there is learn in public. It can be really scary to make mistakes in public, but we're all doing it. Yeah, I'm actually that's one of the things that I'm really curious to see how that changes with kind of the current generation kind of getting older. You know, I have a 19 year old son and his approach to doing things in public is very different than my traditional approach of doing things in public, right? And so I'm really curious to see how when we as we see more of them kind of move in to positions of visibility in a sense, are they more willing and more open to doing that? Is that maybe the positive side of the very much drop in general privacy? Maybe there are some upsides to all of that. But going back to Steve's question, do you have a recommendation? Yeah. Talking about abstracts. So I haven't actually written mine yet, which I really need to get on. I need to do that. Well, I mean, you've got to like three minutes before the deadline, right? Isn't that the general rule? Yeah, exactly. It's fine. I have run many a conference as well. And yeah, the the pile you get on CFP announced day and the pile you get on CFP closed day is really kind of hilarious. Yeah. And also it looks like we have a really interesting question from the audience, which we'll get to in a minute. But talking about abstracts for KubeCon first. So in my blog post, I go over a lot of information. It was really hard to figure out what to fit into the blog post. I realized that there are a lot of things that go into a KubeCon call for papers. And I want people to know about how that process works and what the meaning of it is and what it means for you. So it was hard to figure out all the pieces to put in there. But the blog post goes over the timeline of here's the date that's coming up, of course, is the close of the CFP. And for most folks, that's kind of where your work ends for now is you submit something and then you kind of throw it into the void and wait for judgment. But in the blog post, I go over all of the steps that happen in that waiting period, so that you understand what you're waiting for. And it's actually, they get the judging done really fast considering all the pieces they have to go through. And then, yeah, December 17th. And then also hi, Carlos. And then I go over kind of getting to the conference itself, which I'm hoping to do another blog post on later. But your current segment is creating your abstract and submitting, basically applying to speak at KubeCon is what I want to frame this as. If you've ever wanted to speak at KubeCon, or like we said, if you want to have some experience of learning in public in a very public speaking kind of way, this is a good opportunity for that. And there are a variety of different types of talks at KubeCon, so it doesn't have to just be a 25 minute talk, there's also panels. I think this year they're doing lightning talks, they don't always, but I have to check on that. I think there might also be some concept of workshops. But so KubeCon has a variety of different ways that you can communicate your expertise, your knowledge, your experiences using not just Kubernetes, we talk about KubeCon mainly, but it's also cloud-native con. It's the whole CNCFs conference. So if you have experiences contributing to open source projects or working with open source projects, preferably that are part of the CNCF, those are also really valuable experiences to share. And the important thing to keep in mind here is the audience of KubeCon. The folks you're talking to are going to be contributors to these projects, they're going to be users of these projects, and that consists of a variety of roles. It's not just technical folks who are doing coding or running these projects. There's also a lot of folks there from organizations that you might not normally think of, like sales, of course, there are program managers or project managers. So there are folks who aren't directly working with these things who need to know how they work. So there are a variety of different roles and personas to appeal to. And there's so much information that you might have that would be valuable to share. And the Kubernetes community really encourages new folks if you've never given a talk like that before, but you have something that you'd really love to share with those types of communities. We'd love to have your CFP. Well, CFP, by the way, call for papers is, like I said, just an application to speak at saying, here's the topic I want to talk about. Here's how it's relevant to the community. And here's some supporting resources. My number one tip for anyone doing this, provide any supporting resources you have about what you want to talk about. If you've written a blog post on the topic, if your company posted something about your project, if there's anything out there, definitely share that information. I might even go further in the sense that if you want to propose an abstract, go write a blog post so that you can conclude it as supporting resources. If you haven't written it yet, use that as encouragement. The more buzz you can create, even if it's like, the more buzz you can create on your topic, whatever, the more likely it is that they're going to understand what it is that you're trying to talk about. Yeah. And don't feel like, oh, no, I ruined the whole talk by telling them what's in it. No. Tell them what's in it. That was interesting. I was going to ask about that. You said that looking for new speakers, but going through the submission process and the selection rating voting, there's a little bit of making sure people have some speaking experience. Sometimes they want to make sure that it's going to be a quality. I don't know how much you talk about. Sort of have a little bit of history, if you will, which is hard to say to do now on December 7th, but so people can set their expectations on whether they can just, first time ever speaking, submit one versus go through a meet up or two and then kind of say, well, this is getting good attraction. So I was curious if you could coach a little bit on that. Yeah. Of course, if you have an idea and you've never spoken ever anywhere before, it's a great idea to try to get that talking at something like a meet up. Of course, a lot of those are virtual these days or maybe even just present to your team internally. You can't put a link to that recording in your submission, but you can say, hey, I gave this presentation to my team and I got this feedback so that the judges know that it's real. So it doesn't just have to be public, public speaking. It can also be to smaller groups as long as you're practicing what you're doing and you're showing that you are putting thought into the process of developing yourself as a public speaker. That can help to show that you're going to give a good talk. And there are occasional instances where someone who doesn't really have any visible references for public speaking ends up speaking at KubeCon or other events. If you just have a really good idea that you explain really clearly and you demonstrate your communication capabilities, maybe through your blog post, maybe through other medians, that can also help the reviewers to know that you're going to give a good talk. I would also kind of throw that you kind of said meetups in KubeCon, right? But there's also an in-between there of the smaller conferences and not to pitch my own show too much. So we actually do a conference here called DevConf US. There's another one, DevConf CZ, but DevConf US, actually all of them are specifically targeting new speakers as a way to say, hey, never given a speech, a talk before. We do speaker coaching, we do abstract coaching, we actually do attendee coaching as well so that as a way to kind of break into maybe something a little smaller before you're going to something quite as big as KubeCon or CloudNativeCon. So like I said, pitch my own thing, but there's a lot of in-between. There's one, because I think you're based on the West Coast. The one it's, I want to call it sale, but it's not that, but it's got a really, which one? Scale. Oh, there's scale. Yeah, that's definitely. No, I was thinking one. There's another one. Yeah, in Seattle, that's smaller. Seagull, that's it. Seagull. Yeah. So there's a lot of other options in between, but meetups are a good start and then you kind of gradually escalate, right? And it really does make a difference. And if your talk doesn't get accepted, there's even one specifically for talks that didn't get accepted to KubeCon because there are so many good talks, really great talks that don't get accepted because there's just so few slots. So there's a whole other conference that happens right before KubeCon of talks that didn't get accepted to KubeCon. Yeah, it's like the five-dimension fringe, which I also think is the hilarious concept. So we don't have a ton more time. If you don't mind, I kind of wanted to move on a little bit and kind of ask something that I haven't seen you talk very much about before, but one of the things that I think has been really interesting, particularly during the pandemic, is the kind of growth of Twitch, for example, as it places to learn about how to do tech, not just play video games. We don't pull the Minecraft player million views, million concurrent users at the same time, but there is a very quickly growing consumption there. The other one that I think is really hilarious is learning tech stuff on TikTok, which I find really interesting and really hard. And I was just kind of curious, what's your opinion there? What are your thoughts there? I don't know if you're a video medium kind of person. I know I'm not particularly. I tend to do a lot of it, but I don't actually consume it very well. Yeah, I have some similar eccentricities where I produce some types of content that I don't consume as much. I always feel a little odd doing those, but I'm really excited for the huge variety of different types of content, though, that are coming out these days, whether it's live streams or videos or TikToks, like you said, there's some really interesting coding and technology TikToks, podcasts, blogs. I like to do art and comics, which I guess that we haven't mentioned, but my keynote, I illustrated my whole keynote, so the blog post is all illustrated. I have a lot of fun with that. And I think that's a big part of making technology accessible, is having it in a lot of different forms. It's really tough to learn technology sometimes because it doesn't really apply to our everyday lives in a lot of ways, especially something like Kubernetes and these technologies that are really meant for operating at scale and large companies and helping them to do the work that they need to do for a lot of folks that's not part of their daily lives, so it's hard to understand what that means and how they would go about getting involved in those spaces. So the more places that we have that information, the more people it's accessible to, I think, which is really awesome. Right, yeah. Yeah, I think that's the part that's been particularly interesting. One of the things I really find interesting about the streaming in particular is it's not edited normally, so you can watch an expert fail and how they recover. But the really hard part to learn is, how do you recover? How do you debug? Which is, I think, one of the things that's really difficult to learn without just straight-up experience. So I think that's one of the things that I find really interesting about Twitch. So you brought up the comics, and so I wanted to bring that up. I mean, I'm so jealous. I've seen your talks, right? I've seen there's another guy I know, Vashlik Pavlan, who also illustrates his own talks, which I'm like, I just, you know, whatever. And then there's Mo Duffy of the Fedora community, who's been doing comic books to explain tech. They're currently working on one about Knative. So I think that's a really interesting model. How much do you use that technique to teach it to yourself, in a sense? Absolutely. I talk a lot about like conference-driven development. Yeah, yeah. Whenever I'm, whether you're writing a blog post, whether you're making a comic, whether you're doing a live stream like this, you end up learning so much in order to produce the content to teach others. So any way that you can communicate knowledge is a great way to learn. Right, right. Yeah, it's kind of crazy the, you know, becoming a college professor, right? I know way more about the stuff I'm teaching now than I ever did before, right? The ins and outs really, really deeply. So it's been really interesting. So let's see, do we, I wonder, there was something in the audience. Oh, that's what it was. I was like, I know we missed something. Yeah. Carlos had a question about Robocop at KubeCon Detroit. No, just kidding. It was about CNCF hiring dev advocates. Yeah, for Kubernetes are related projects, which I think is an interesting specification there. So when I was at KubeCon, I met someone who is a developer advocate in developer relations with the CNCF. And I think I meet a variety of people who work for the CNCF. I don't always know their role titles. So it's possible that I've met folks who are doing that for the CNCF before, but this person was kind of new to the role. And so we spent quite a good amount of time talking about what does developer advocacy mean, especially with the CNCF, and kind of exploring what the community was doing and all sorts of dev rel type things. So it appears that the CNCF has at least hired one developer advocate or developer relations person. I don't think that they will ever do it on the scale of like every project gets their own, I mean, maybe. But if they did, it would only be for like graduated projects. So for anyone not very familiar with the CNCF, there are so many open source projects that are part of the CNCF. And the CNCF is a nonprofit organization that's goal is to benefit open source cloud native technologies. And so they provide a lot of really nice tools like a code of conduct that applies across all of their projects, some varying management tooling and capabilities and processes that they give to their projects and also some marketing that they do for the various projects. And projects usually come in around the sandbox or incubating stage. Sandbox is something that maybe has a small contributor, maybe not a whole lot of end users. Incubating, you start to get a bit bigger, your contributor group is more diversified across a variety of companies, maybe across a variety of locations, you're starting to get more end users and then graduated are projects like Kubernetes where has huge user base and a huge contributor community that's very robust and likely to keep going for a long time. So if the CNCF were ever to hire developer advocates on a project basis, I think they would only do it for graduated projects, which are the most mature ones. But for now, I think they'll probably just have a few that are more general. Well, I mean, because it's an open source project involved with a lot of very large companies involved, there are a lot of developer advocates being provided to the CNCF. I can name at least one at Google. I can name a few at Red Hat. So there are a lot of those opportunities as well. But to kind of your point, they're usually a little broader than one project. One of the conversations in the chat is talking about platform as a whole kind of advocates. It's funny because I read that and I immediately think Linux, but we also are talking about Kubernetes here too, as the platform itself. So I know, for example, I know Red Hat has that or did when I left. What is your kind of advocacy like focus? Is it Kubernetes? It's CNCF? It's a variety of things. There's always kind of the business side of it, at least for my work. There's the business side of it and there's the community side of it. That's true for any developer advocate. Because our goal, by the way, for developer advocates is we are advocates for the developers or users generally of these technologies. It doesn't just have to be developers even though we use that term. It's very, very broad. So my work and one thing that I tell a lot of folks who are interested in the field of developer advocacy and developer relations is that some companies have developer advocates or developer relations as part of their sales groups. And that can be really tough for the developer advocate to do the work they need to do because you come in and you have to be like, well, I am part of sales. And that instantly, any community that you're talking to, any user that you're talking to is like... Changes your relationship. Yeah, it changes the relationship. I don't know if I want to talk to you about my problems because then you're going to try to sell me something. So that just makes our job as developer advocates really hard because our goal is to advocate for you. We want to hear about your problems so that we can make our products better. And if you're not willing to communicate with us, then that's not helping us. So I think platform advocacy, like being engaged with the engineers who are actually doing the work, is essential to any developer advocate's work. Yeah, one of the things I did at Red Hat actually when I first started there was... My first role there was a developer advocate and I was like, well, now I need to meet all of the engineers. And so I started what I referred to as the sticker depot. And so I started keeping stickers on... We had really big desks in our office. So I had kind of this empty area on my desk and I would keep stickers there. And I had to take a sticker, leave a sticker policy. And I got to know everyone because that worked really well to get people to drop by and say hi. And so I got to know lots and lots of engineers. See, it's even harder now than it was then because I think Red Hat was about 5,000 people then, maybe half or something being programmers. And now it's 12,000 plus. So it's a little bit more difficult. But yeah, getting to know all the engineers because you want to be able to communicate... Yeah, you want to be able to communicate... Well, yeah, if you include IBM. If you want to be able to communicate kind of both outbound and inbound about what is going on with their experience, what a developer's experience is. I thought it was a really interesting job. But I left it because as I joke, they got tired of me complaining and made me come and fix stuff in engineering. So that's what I went and did. But the thing like developer, when a developer word starts and ends, and that's like we argue about this all the time in my role. Yeah, because it's, if you look at like, I don't forget which Kubernetes it was, like 60% of the attendees were developers. So it's Seattle. And I'm like, it's like, and but then you look at the technology, they use these terraforms and it's like some of the things. So like a lot of them are kind of, some people would call infrastructure here, but really, they see themselves as developing for the infrastructure, as well as representing their developers in the end. It's, you know, helping them be a really interesting anonymized data point for you. A lot of the users that I've been talking to lately, I came up with this little survey that I give a lot of folks sometimes whenever I can. And people never like to identify themselves as operations something I've learned. People always want to be developers, no matter what they do. Like I try to describe the roles, not as like, this is your role title, but like this is what you do. And they still shy away from it. I feel like they still shy away from it. That might just be confirmation bias or something, but right, right, right. That's a problem when you're doing like surveys, right? If you're handing them out, you know, it obviously tends towards bias. We are just about out of time, so I don't want to, you know, kind of go over too much. I did want to get to my final, final question, which was that we saw your get cheat sheet, what, you know, and I've been working on trying to actually have a location where I could like stick cheat sheets. Any other cheat sheets you, you strongly recommend? Oh yeah. You mean this one? Nice, nice. This is by SOSplush, by the way. So SOSplush, I don't know. I think it's SOSplush. But she's on Twitter. She has her own shop and she makes these great little mouse pads, as well as I have the like print version as well that I can put on my wall. So I have the get one and I also have a Vim one. And there's a great Keep CTL cheat sheet on the Kubernetes documentation. I love fun fact style learning. Cheat sheets are always great. I think putting them on walls, putting them as mouse pads, all sorts of places is a great, great place for fun fact cheat sheets. Right, right, exactly. Well, thank you so much for coming, you know, and you can, you can find Kasselin on her blog at Kasselin Rocks, or Kasselin.Rocks, and on Twitter as your Kasselin fields, right, on Twitter. And, you know, obviously, and speaking at lots of conferences and, you know, going and advocating for Kubernetes and CNCF all over the place. So thanks so much for coming and giving us a little insight into how you see what's happening at Kubernetes. Yeah, thanks so much for having me. It was great talking with you. Thanks for having me.