 So, let's go ahead and get started. I'll introduce the first couple of lines that I have in there. Cool. Welcome. We're going to get started here, but first, I wanted to mention that we do operate under a code of conduct here at KubeCon, also at all of the Kubernetes open source meetings, which essentially says to be respectful of your fellow attendees and speakers and generally be excellent to each other. And of course, there is closed captioning available if you would. It's going to be an issue. If you would find closed captioning helpful, there's more information about that here. I'm not going to go over it all, but do make use of that if you would like to. And Rich? All right. This is Build Your Own Path in the Cloud Native Ecosystem. I'm Rich Burroughs with Waf Labs. I'm a developer advocate at Google Cloud where I focus on Google Kubernetes Engine and open source Kubernetes. And I'm a developer advocate at Waf Labs. I work a lot with this project called Vcluster. And we're going to be talking about these podcasts that we do. Yes. So I have a podcast called KubeCuttle that I created just right at the start of the pandemic. Maybe good or bad timing, depending on how you view it. But I interview people from the community. The focus is a lot on the people and less on the technology. And I am one of the co-hosts of the Kubernetes podcast from Google. It was previously hosted by Craig Box and Adam Glick. Now it's myself, Cousin Fields, and Abdel Sigour, who I don't know if he's here. It doesn't look like it. Well, you're going to hear his voice anyway. They want us to stand a little further away from each other. OK. Thank you. So the idea of our session today is that we're going to be showing you a bunch of advice that we've gathered from leaders in the community through interviewing them for our respective podcasts. So that's why we wanted to mention the podcast to you. And as you saw as we worked through our technical issues, we will be playing a bunch of quotes from them. Yeah. And it's a very fortunate position that we're in to be able to talk with all these experts in the community and learn from them. And we want to make sure that we can pass some of that onto you. Yeah. So here's our agenda for what we're going to go over today. We're going to start out with understanding open source. Then we're going to go over some Kubernetes history and a little bit about becoming a contributor. And then since this is the concept of this is to help you build your own path within the cloud native ecosystem, these first three kind of give you a baseline of understanding where we came from and kind of the world that you're in. And then the last two are a couple of deeper topics that I think are particularly trendy and interesting, security, and AIML HPC. So we'll dive a little bit into those. Hopefully all of these give you tools to build your path through the ecosystem. Yeah. So understanding open source, open source is obviously a big part of Kubernetes in cloud native. Kubernetes is the second biggest open source project in the world after Linux. And last I heard. Yeah. And once you get into this, it's pretty natural to end up, if you're someone new, kind of wondering about how do these things work? How do I participate? And open source is a big world. It's not just Kubernetes. There are all sorts of other projects within the CNCF. So lots of folks end up moving around or being part of multiple projects. So we want to give you a general kind of sense for why you might get involved with open source. So first off, we're going to hear from Kubernetes 1.26 release lead, Leonard Palke. He is also a, I think, one of the chairs of the CNCF tag for environmental sustainability. So he's involved with Kubernetes. He's also involved with the CNCF in kind of a broader capacity. So I'll let him tell you why he got involved in open source. Hi, everyone, Petrus. I was working for a company, mainly focusing on ARS. So I was kind of already in this cloud space. And a couple of colleagues were very into Kubernetes and the cloud native in general. And some of my colleagues were just showing the Kubernetes and this entire space. And I think it was super interesting to see how cloud native technology can be used anywhere. It's not dedicated to any provider. So I thought this would be an interesting step, besides ARS. And because everything is open source technology, I'm going to introduce him to the full source. So something important that I think he's pointing out here is getting involved with open source. Most open source projects are not vendor specific. They're vendor neutral, theoretically. So whatever job you get involved with, you may have a specific vendor that you're going to be working with. But as you move through your career, you might end up working with other vendors over time. Getting involved with open source technology can give you a baseline of skills, which are transferable between different vendors. And that's one of the reasons that Leonard got involved. Yeah, and Leonard's situation is really interesting, I think, in that he got into Kubernetes first and then open source through that. And I think a lot of people followed that opposite path. They learned about open source and then maybe about Kubernetes. So it's cool to see that people have different ways of getting involved. Also, if anyone that we're quoting is here, please raise your hand so they can point to you. So they're slightly less embarrassed. And I spoke with Divya, who is a very awesome person in the community. She's one of my favorites. And we talked a little bit about imposter syndrome and the kind of pressure of feeling like you have to be an expert. Yeah, I think that's really important. There's a lot of really great people in the community and they're very welcoming. So sometimes it can be intimidating, to go into a Slack channel or something like that and ask a question, but you should know that there's a lot of kind people out there who want to help you out. And I also spoke with Carolyn Van Slike, who is a very awesome person as well. And we talked a little bit, she works on the Porter project a lot. And we talked a little bit about this idea that it's kind of similar to Leonard, that being an open source actually gives you options in your career. Point of saying, the people I work with, if I change employers, are still people who matter in my network beyond just the next job recommendation. I'm still working with them. If I switch from one company to another, if I'm still working on Kubernetes or I'm still in a CNCF ecosystem, those relationships still matter because that's probably the only consistency I have sometimes when you switch. And I think that's really powerful and you get a chance to work with, I think some of the people who have the great idea about how to attack life and technology and what we're trying to do, because I found that in the Kubernetes ecosystem especially, people are extremely focused on fostering a healthy inclusive community and not just lead code or a cache, whatever you want to call it. So I value the relationships I've made in open source so much, almost more than the license. Yeah, I think the phrase is same team different companies, is that it? And it really can be empowering to know that you have this community of people that you're involved with and that if your job goes away or you want to pursue an opportunity somewhere else, you can potentially get a job doing like literally the exact same thing with a different employer. Yes, I think this might be one of my favorite quotes in this entire presentation. It's so true that you kind of build this safety net and support network that goes beyond your work. And next we're gonna talk about Kubernetes history. This illustration is one that I did during a meetup, a Docker meetup in 2018 with the three founders of Kubernetes, we generally consider them to be, Joe Beta, Craig McLucky and Brendan Burns. So they were all engineers at Google who decided that they should take the Borg system that Google uses internally for running a lot of our own applications across a data center and generalize that into something that folks can use. So that's kind of where Kubernetes came from and also the person moderating the session is Chris Nova who is also a big community member. So I had a chance to speak with Joe. It was really exciting. I'd wanted to talk with him for quite a while and I actually had some imposter syndrome about this. I like didn't approach him for a while because I was like really intimidated but we had a wonderful conversation and we talked a lot about the early days of Kubernetes and I think it's important to understand that this thing wasn't fully formed like out of the womb or whatever. It's something that's evolved over time. And this quote also is relevant with the keynotes that happened this morning if you saw those. There was a lot of shade thrown around like the early version of Kubernetes around that. We didn't target scaling beyond say like 100 nodes. And that was a conscious choice because we knew we could solve that eventually but the thinking was let's make sure we get the experience right because nobody's gonna be using this as a hard-to-getting tool right? Sure. But that led to a lot of people throwing shade and so we eventually decided to focus on that and that led to the first SIG because we sort of worked off a set of posts to start looking at that and that ended up becoming 6K at the scalability and then I do know being able to sort of carve off groups of people to focus on something like to sort of the way the project is organized now around SIGs. So yeah, I think that, like I said, it's important to understand that early on and if you get a chance, watch the really awesome Kubernetes documentary that the Honeypot folks did. We talked about that some in the interview. It goes into a lot of this but like in the early days, there were several of these different orchestrators competing and it wasn't at all clear that Kubernetes was gonna win. Yep. And by the way, SIG stands for Special Interest Group. And I spoke with this guy that you might have heard of, Kelsey Eidauer, had a really wonderful conversation with him and if you're not familiar with it, he has this project called Kubernetes the Hard Way where it walks you through like building a Kubernetes cluster but by like typing out all the commands, you know, one by one. And we talked about that, the fact that he's still maintaining it to this day. I think a lot of people going to use Kubernetes, I agree, you should just make it easy, something like GKE autopilot is cool, the cluster is hidden, you know, Fargate has similar ambitions. That's cool, but if you are a platform team or you're the first one who's responsible for fixing it when it breaks, then you need not necessarily easy people on understanding. So Kubernetes the Hard Way is really about saying as I learn more about Kubernetes, as the project updates and changes, let me keep that document up to date so as newcomers come in or anyone that wants to refresh it, they can step through it as tedious on purpose, it's like building a 10,000 piece JSON puzzle. But it's tedious so that way you know where all the pieces fit. So when you're done, you can step back and see the big picture and say, I built that. And then it's still a different level of confidence than clicking the automation button and having something else do that. And I think it's really important to keep in mind that everybody does have different kind of contexts. And like Kelsey said, if you're the platform team, maybe you need to know more than an application engineer who's just deploying their apps to the cluster. And I think that's also reflected in the certifications that the CNCF offers. There are some that are a lot more focused on general kind of overall cloud native knowledge and some that drill really deep into specific topics. And I think it's really cool that Joe's quote and Kelsey's quote, if you saw Aparna Subramanian's keynote this morning, she kind of gave a review of if Kubernetes is delivering on its promises. And the two things she called out that really need work in the Kubernetes space were scaling and complexity. And that's what these two quotes are about. So we've heard a little bit from Joe about some of the early considerations and some from Kelsey about the early ways that folks started learning about Kubernetes. I also wanted to add in a quote that tells us a little bit about how Kubernetes as an open source project and contributor community functions today. So special interest groups, which Joe mentioned will come back into this. But this is going to be an explanation from Benjamin Elder, who is a steering committee member for Kubernetes, talking a little bit about what steering does. Yeah, so the Kubernetes steering committee is the top level governance body for the Kubernetes organization, the project. When we say that we mean because the Kubernetes project has established documents and governance for how everything is handled from the CNCF owns the project to the delegate to steering, then steering delegates most things down to special interest groups for different horizontals of verticals in the project. So steering doesn't make technical decisions, but steering does help be an escalation point for things and interface to the CloudAid computing foundation who actually hosts and owns the project and all the code and trademarks and everything. So we sort of advocate for the project with our host organization and partners and we establish the governance for the rest of the project. But things like how particular portion of the project is administrated are handed off to the SIG groups. So that's something that folks often have trouble understanding with steering. It's like you think that they would be making all of these technical decisions, but they're really more of a body to manage a lot of the process that goes on around running a major open source project as part of a foundation. One thing that really struck me in my conversation with Ben was that the Kubernetes project functions a lot like a business. As you go through your career, you'll probably see a lot of similarities, but same team, different companies. Yeah, and I think that there's a lot of acronyms to navigate. You've got the CNCF, you've got the Kubernetes project, there's tags and SIGs and all of these things and I think it does help a little bit to kind of familiarize yourself with what some of that lingo means. Yes. Becoming a contributor, so. Oh. I think it was actually like that. We want to talk a little bit about the actual act of contributing to a project and contributing can mean a lot of different things, right? A lot of people tend to think of it as contributing code and that's certainly very important, but people contribute in lots of different ways. Docs, even evangelizing projects, advocating for them, all different kinds of contributions are very welcome. So I wanted to hear a little bit more from Benjamin Elder since he's such a leader in the open source contribution community within Kubernetes about if you're interested in getting started contributing to open source, some of his advice for you. In fact, some of the areas that you're hardest to contribute to are great areas because if you keep persisting in that and people are like, hey, this isn't really being handled and we have someone else that has shown up and is working on it and trying to take care of it, that first part's going to be frustrating where apparently this area that isn't already being really well handled and is a good spot for someone to come in and take over because it isn't so well handled right now, it's going to be hard to get that initial work done and people are going to be busy. It's just such a unique project. We have so many issues open and features and everything. It's really hard to keep on top of everything happening here. You can't really do all of it and even if you try to pick some area that they expand over time, but if you can just keep coming back and be persisting about it, people will notice and I think a lot of open source intermediaries will also start to go a little bit more out of their way to try to help you specifically if they notice that you've really been trying and trying to make sure that you're not stuck forever. It's hard to figure out what is even fair for how much time do I spend reviewing things and where do I spend it and things like that, but definitely one of the things that I know I pick up on is when someone just keeps coming back and like, well, I feel for them at all. He's stuck forever, they've been trying so hard. Let me make sure that I'm getting to some of that. Contributing to open source, especially starting to contribute to open source is hard, one quote that I absolutely love from Nadia Eggball's book, Working in Public about open source communities, is that it's not technical capability that keeps people from contributing to open source, it's fear of committing a social faux pas. Yeah, I think it's important to remember too, as Ben mentioned, that the maintainers are people too, right, and this is something that they're doing in a little slice of maybe even what they do in their day-to-day job, and so being patient and being persistent are important. And if you feel the first time that you try to get an open source, don't worry, most of us do. So we're gonna talk a little bit about the topic of security. If you've been involved in the Kubernetes project for a while, you'll know that it's an area that's rapidly changing. I think the platform was pretty wide open in the beginning, and as time has gone on, there's more and more new features showing up, and it's a good thing. It's something that people are paying a lot of attention to. So we are going to start off with our newly emeritus human co-chair, Emily Fox, talking a little bit about the unique characteristics of cloud-native security. There's just, I don't know, there's so much to consider when it comes to cloud-native, and it bleeds heavily into just general open source security. You'll see this in a lot of the security technical advisory group's issues and discussions, is we are starting to get to a good saturation of what is secure practices in the cloud or secure practices with open source, and where that overlay with cloud-native makes it for technical uniqueness. Those are becoming more and more challenging as the lines get blurry, because we're seeing more mature security guides from the cloud-native ecosystem applied outside of our architectures. So we've done really good, we've gotten ahead. People are using the products and the deliverables that come out of that group, and now we're trying to figure out what's the next thing that hasn't already been covered, or where do we point to existing material that is more refined and more use case specific for adopters. So as you're finding your way in the cloud-native community, I want you to know that security is a very important and trending field. There's also a lot left to do. There's a lot of space there to explore new things, and create new standards. Yep. I had a chance to speak with Brad Giesman, who I think of as one of the kind of cutting edge folks in the Kubernetes security space. I mean, he's actually giving a talk panel later on today with Ian Coldwater and some other folks that should be amazing. But we talked about this idea that there's been some sort of arguments on Twitter at times about how secure Kubernetes is. Is it secure by default, or what do you need to do to make it a place where it's safe to run your applications? I would say that in the model line, you've got at least two tenants. And by that I mean, you have a persona that cares about the workloads, and you have a persona that cares about the cluster and its system workloads. And you probably don't want those to cross paths because if one of the front-end-facing containers is compromised, you're not doing anything else to protect your other persona by definition of multi-tenant. So I think there's a fair bit of work that you tend to have to do to make sure that those set of assumptions are well-guarded. So, you know, our back network policy, initiative control of some kind, providing a lot of payloads. But also I think what tends to happen is that advice works for smaller setups. Like it's reasonable to understand when it's just two namespaces and a couple of pods here and a couple of pods there. Where I think the challenge is this one if it comes a multi-tenant cluster or a soft multi-tenant cluster where it's like five teams of similar trust level in the same morning, and you have things like ingress that are shared or you have keys or certificates that are shipped. That's where it gets really tricky. I think that's where when folks say, oh, it's insecure by default, they're saying it's insecure by default for my version of what I want as far as isolation. And I think you have to use the tools that are there and sometimes add some other tools that are the purpose built for this to make those boundaries be what they want to be for your use case. What are some of those other tools? Things that are like admission control sometimes pop. I made a editing mistake on that one, but I do think it's important to keep in mind that there are these, you know, primitives there like, you know, our back and admission control and network policies. And if you're interested in security, those are a really good place to start in terms of like kind of trying to dig in and learn how those things work. I also had a chance to speak with Liz Rice, who you may know of. She works at Isovalent. She works also at Emeritus Keep Country. Oh, yeah, yeah, yeah. She's done all kinds of things in the CNCF. And she's somebody who she works a lot with EBPF, which is basically a way to program the Linux kernel and an open source tool called Cillium that leverages EBPF. So we talked about the fact that because EBPF is operating like right in the kernel, there are some advantages to it, like performance. These are also some trendy concepts. It's very good at efficient networking because we can bypass essentially the host networking stack in a lot of cases rather than having to, well, in most ports run in their own network main space and that means they have their own network stack. So in a traditional non- EBPF environment, a pack that has to go all the way through the host network stack through the virtual ethernet connection into the pod and then through the pods networking stack. But with Cillium, because we know, ah, here's this packet, I know, but pods that it's destined for, I can just send it straight into that network main space without having to go through the host network stack, which gives some pretty significant improvements in performance. Yeah, so if you're interested in security, like Kassel had said, I think that the EBPF and Cillium stuff is really becoming very popular right now and so that would be an area to poke into a little bit if you want to. And I think from this, you can kind of see why. There are some performance benefits and things to be gained there. Yeah. All right, for our last section today, how are we doing on time? Pretty good. We are going to have a little bit on AIML and HPC since that is a big thing that's going on in this space. So on the Kubernetes podcast, we had the opportunity to interview Louis Bayou, who is an engineer at PGS and they came on to talk to us about supercomputing in the cloud with Kubernetes. So PGS at one point had one of the world's leading supercomputers on prem and they have switched over to the cloud. But first, let's talk about what a supercomputer is. It's a lot of the same, a lot of different things. So I still like CPUs around the network and all the stuff you find in any desk and they're just highly condensed. So in supercomputer, the main thing is basically power density. So cramming as much as you can in the same Chrome space, CPUs, memory and everything. And also, it's most of the time used very special as networking. So it's an infinite loss of fabric in order to register it and see what you know. So supercomputing is all about performance and just compute density. Just getting as much compute storage and everything as you can into one space, essentially. So now, Louis is going to tell us a little bit about how that applies to the cloud and Kubernetes. It was a long past when we got to this and it definitely wasn't something we had decided from the get go. We ended up there more than we actually chose to go through. The main thing is basically like in 2020, yeah, we've been impacted by everybody and we ended up in a financial situation that meant that renewing the long-term platform was just out of the question. There was no way we could actually do it or find us at the time. So we had to find a solution. Because we've been getting off of waiting in the cloud and we're starting to see what was working and what was not, we were starting to see that actually, if we go a bit further in, there is probably a way for us to completely shift our ID on the set and instead of going, yeah, 20% burst in the cloud, actually going 80% in the cloud and then releasing the credits. So we started to explore that idea and because we didn't really knew what we were doing we started with the approach of taking what we knew from our practice and looking at the different component that had like credit pieces or had that component that could be used. So we effectively like did a lift and improve in that case. So we took a lot of the ecosystem we already have and started to build like accounting to PC. So I think this is really cool because we've established that supercomputers are essentially a whole lot of compute all in one place. By the way, HPC stands for High Performance Computing, that's supercomputers and AIML of course require a lot of this. And so what Louie is saying here, if we think about Kubernetes, Kubernetes is a distributed system. It's there to combine all of that compute that you get into the cloud into one thing that you can send your workloads to. So in that way, it does have quite a bit of similarity to what you're trying to achieve with supercomputers and PGS found a way to make that work for them. I love that phrase lift and improve instead of lift and shift. I think a lot of people, if you've done some time in the cloud, you've had that experience of migrating workloads over from on-prem and things change. It's a different kind of system and so sometimes that makes things harder but sometimes it means that you can find more efficiencies. And so in closing here are some of our key lessons that we got at least out of putting all of this together for you. For one, open source, getting involved with open source helps you build a career that's robust and will last. And Kubernetes developed slowly over time and didn't become the prominent tool it is overnight. Learning Kubernetes for the first time can be tough but it will help you to do it the easy way later. And in terms of contributing, you don't have to be a Kubernetes expert to get started with that, feel free to hop in. Help maintainers help you. If you stick around and just stay stubborn, you will eventually become a contributor. And as we mentioned, security is still a very growing, maturing field when it comes to Kubernetes. There's all these new features getting added and so I think it's a really good place for people to come in and add their efforts if it's something you're interested in. Changing and improving a lot. And in the world of artificial intelligence, machine learning, and high performance computing, the cloud changes the landscape of what we have previously considered to be supercomputing. I hope you enjoyed learning from us today. If you have feedback for us, this QR code will take you to the feedback form. Oh, and you know, both of our podcasts are radio podcast players. So like, subscribe, hit the bell, do all of that. Thank you. Do you have time to take a couple of questions if anybody has any? Cool, so if anybody has any questions you wanna ask on the mic, do you feel free to do so or you're welcome to come up and talk to us. Cool, yeah. So, I mean, thanks for the great talks. It was insightful. So someone changing their careers from developer to DevOps. So like understanding Kubernetes was easy but when it comes to security, it was quite tough. So how do you recommend for someone starting out? Like, when I went to the solution showcase, there were too many things. Yeah. I don't know which one is the right. Welcome to the world. Yeah, so there is the CPS, you know, the certification that the CNCF offers. And I think that wouldn't be a bad place to start. There are some really great guides out there. Some that are even free, you know, that are like preparation guides. I know Siam Paphic, I think he makes one that's free. And so even if you decided not to take the test, you know, to do the actual certification, like going through those... Those are five Kubernetes security specialists. Yeah, but going through some of those, like training materials, I think would be a really good way to expose yourself to a lot of ideas. Oh, they also just released the Kubernetes Security Associate certification as well. That'll be a lighter weight one. So maybe start there. And then this gives you a couple of goals to work toward to get all of that security knowledge. The other thing too is that the SIG meetings and stuff are open, right? So I mean... If you want to hear the latest. Yeah, so the SIG security folks are all great. They're super, super kind people. And I'm sure if you wanted to like hang around with them, that you could absorb a lot that way too. Yeah. Anyone else? Yeah. Thanks for your great talk. It was nice listening. I'm pretty new in the field as well. And it was very recognized like being able to contribute. You have this thing in your mind that you can only think you can do that when you can code. Yeah. And I'm pretty good at editing yambles now and stuff. And I came a long way because I used a Windows sys admin. So, but I'm trying to get into coding more to be able to feel more useful. So, how do you pick that up? I mean, do I start with the goal? Where do I start? This is definitely something that I've struggled with. By the way, there is a certification for being a YAML engineer. It's called the Certified Kubernetes Application Developer. It's essentially a YAML certification. But getting started with code contribution. So, if... And just kind of getting more comfortable with code in general. So, if you are aiming for contribution as one component of this, getting started with Kubernetes contribution not in a coding sense will still start getting you more familiar with some of the tools because we do pretty much everything you get. So, you're gonna have to get really familiar with Git even if you're just contributing to docs. So, you start building those skills there. Docs is also a really great opportunity for you to start getting familiar with the code base. Like you mentioned, should I start with Go? Should I start with this? There's a lot of those questions there. Kubernetes is, of course, written in Go. So, that might be a good place for you to start. But I'm pretty sure Kelsey Hightower at some point said the best programming language is the one that you know. Yeah, I think that's true. I think lots of people say that. But yeah, it is definitely a Go ecosystem around Kubernetes and a lot of other cloud native tools too. So, if you're interested in learning about Go, I was just on my phone trying to remember the person's name. There's a guy named William Kennedy, Bill Kennedy who does really, really excellent training materials for Go. So, he has a class and a book and things like that. And I highly recommend his materials. Half of learning is finding motivation, though. So, like we suggested, using the certification as a goal, maybe getting involved with a specific contributor group as a goal or something like that. Thank you. Yeah. Yeah. Anyone else have any questions? Oh, it looks like there's a lot's back there. Nice. I feel important. I wasn't sure if there would be any questions after this point of view. Thank you for the presentation. My question would be, after you get all these certificate bundle for Kubernetes, CK, CK, and CKD, what would be the next step in your journey? Do the work. And is this enough for you to kind of be involved in the community and contribute? You don't necessarily even need certifications to be involved in the community. I don't have any of them. Yeah, I don't either. It's one of those things like I think certifications are a thing where if you're applying for a job, I think it can help you, especially if it's a place where nobody knows you. And it can let them know that you have done some work and have some knowledge. But I don't think that they're at all required. And I don't think if somebody doesn't have them yet, don't let that hold you back. But I do agree with Kassel and that it's really about getting practical experience at that point. So what's not 100% clear for me is having all the certificates. I'm not talking about having the certificate itself. I'm the knowledge we should gain from the certificates. We'll help you manage all the YAML files, be aware how the Kubernetes is working behind the wheels and stuff like that. But your contribution to the community, the contributing to the Kubernetes itself, I expect to be a writing goal and making more percent to the repositories. So how does that do with that? It doesn't necessarily have to be that. It can be. But like we were just saying, there's a lot of other ways to contribute. I have never contributed a line of go code to a project at all. I've contributed to several open source projects. And a lot of times it's been like just going through the read me and seeing if I can do the thing. And if I run into a problem submitting a PR to fix that thing so the next person who comes along doesn't run into it. So there's a lot of ways that you can contribute. I do think the SIGs are a really great resource. And if you Google Kubernetes SIG, you'll find a list of them. And that would maybe be a place to start is just look at the list of SIGs and see like if there's one specific one that maybe matches your interests. I'm headed to the SIG meet and greet after this if anyone wants to join. But as far as the connection between certifications and the community, the certifications are more geared toward end users. If you are someone who is using Kubernetes, that's mainly what those certifications are geared towards. If you are creating Kubernetes, I like to say the people creating something are not the same as the people who use the thing. So a lot of the folks within the community, some of them have those certifications, but many don't. And you need slightly different skills to do the contribution versus the certification. It will be helpful. It's not like it won't help, but it's not required. I mean, you have a great point in that the knowledge is what's important. And I think that generally when I talk to people about the CNCF certifications, they're pretty well regarded. There are certifications out there that aren't very hands on and where it's just like memorizing stuff from a book. But these really do test your ability to do things. And so if you've been able to pass some of those, then I think you're doing great. From an end user perspective. Yeah. Yeah, thank you. Can you just repeat you suggested something for Go as learning material source? Yeah, the guy's name is Bill Kennedy. OK. Yeah. If you just Google Bill Kennedy going, I'm sure you'll find him. All right. Yeah. Thank you very much. Yeah. There's more questions. Yay. Oh, wow. Oh, we're out of time. OK, yeah. So come up, come up, and yeah. Thank you so much, everyone. Thank you.