 Hello everyone, and welcome to the last talk of this KubeCon. So whose server is here? You all are the best people in the entire KubeCon. So this is a part of the student track. So we are happy that student track was there in this particular KubeCon. And we will try to navigate the CNCF landscape, try to show you how, from our perspectives, how to navigate the landscape in the right way. And that's the talk. So I'm joined by my name is Sayam Bhattak. I'm from Sivo. And we have Divya. Divya Mohan from Suse. And Savita Raghunathan from Red Hat. And Kunal Koshwaha from Sivo. So we will be now getting started with some of the questions that we have gathered, some of the most important questions that conversations we had with the students with respect to the challenges they face when they see the landscape or what questions pop in their head. So we'll try to answer those. So first, it is an interactive kind of session that we'll be doing among ourselves. But yeah, we'll be having a Q&A as well so that you can ask your additional queries with respect to whatever we have. So first, I would like to ask Divya on setting the context. What is Cloud Native? Yeah, great question, because that's something that confounded me when I started off. Why is there a need for Cloud Native in the very first place? So I come from a background where primarily applications were deployed on self-hosted servers or dedicated servers. And we gradually moved from physically hosted servers to sort of moving towards the cloud and then towards a multi-cloud environment. So when I started off, there was cloud, but it was not so prominent and out in the market. But it sort of went out in as my career progressed. So Cloud Native as a paradigm evolved because of the requirement of a vendor agnostic platform for all these benefits that the cloud offers. And this was primarily a requirement, not just because of that, but it was also because there was a move towards a more declarative approach of deploying and building your applications. So that's where Cloud Native as a paradigm emerged. And as we are moving forward in this landscape talk, you'll see how the different aspects of building, deploying, and securing your applications can be achieved with the help of the various cloud-native tools and technologies in the landscape. So I think that will be covered by Sayum and all of the rest of my panelists. Cool, so now we know what Cloud Native is. So let's try to understand from the view of what a CNCF and why was it required in first place? Yeah, so like I said, there were many clouds. And given the requirement of a vendor agnostic platform, all of these members sort of came together. And CNCF was formed as an organization under the Linux Foundation for the development. And I wouldn't say propagation, but it's not propagation. It's proliferation of this cloud-native paradigm. And the requirement, again, was the basic leveraging of all the benefits that the various clouds had to offer, but in a vendor agnostic way. So I think the next thing that we sort of want to look at is what are the different types of projects? So Savita, do you want to talk about that? Sure, so there are three major categories where these projects get grouped into. Let's start at the sandbox. The sandbox is like the experimental projects where you have all your ideas and they are not prediction-ready, and you are moving way too fast. So that's where all the ideas and all the innovation and creativity is happening. And so there are certain criteria to get into the sandbox project, and that is available in the CNCF website. So once it passes and it gets reviewed by the specific tag, which is like a technical advisory group, and then it gets in the sandbox. And after a while, once it satisfies certain requirements, it's going to be moved into the incubation. Now incubation projects are run in prediction by a small number of users, and they have a good number of contributors contributing to it, and it's in a steady state. And then after a while, the projects mature, and they become more and more stable, widely adopted, and then they have a large number of contributors flocking and contributing to it. Projects like Kubernetes, Prometheus, and many more, and they fall into the graduated category. There is one more, which is not mentioned here. Like there is this group called Archived, which are not no more relevant, or they have achieved their end goal, end of their life, and you found something new. And it's like this one idea, and you move on to another idea, which is the old idea is not relevant anymore. So those projects get saved there. Now that we have heard a little bit about how these things are, then let's ask Kunal. What is the landscape? Cool. So hello, everyone. I'm Kunal. And even though this is a part of the student track, I think we all can agree that even folks who have been in the industry for a while can relate to this when we talk about navigating the CNCF landscape. So can we go to the next slide? So when we talk about it, so as you can see, the goal of the cloud native landscape is to compile and organize all the cloud native projects, be that open source or proprietary software, into categories. This makes it easy for us to navigate through it, and we're going to be covering how you can actually pick up the right project for your particular use cases. And organizations, you can submit a pull request and get your projects added in the landscape. It's created in a card shape. So obviously there's a card format, and if we can go to the next one, about the details of the card, there you go. So you can see that this is a card of one particular category, and it has a few small boxes that have projects associated with them. So projects in the large boxes that you can see are the open source projects by CNCF. And some are still like the incubation stage, like Savita mentioned previously, and those are represented by light blue. And the purple frame, while others that are graduated, are in the dark blue frame, as you can see, bitters and stuff. The smaller boxes that you can see, the white small boxes, these are open source projects. And the ones that are grayed out are proprietary software. Move forward. So if we look at a particular card for, so if you click on one particular project, it pops up this more information about that single one. So here you can see the project information from GitHub, the funding, and all the other information, like market cap, and some of the best practices. This is a good resource for getting involved. So if we take an example of Kubernetes, it shows the website, the documentation, the blogs, and the mailing list, Slack channel, and everything that goes on over here. Right. That's a great segue into our next question, which is how to navigate the landscape, Syam. Yeah, so now we know what Cloud Native is. What are different projects in Cloud Native, Sandbox, Incubating, and Graduated? We know what the cards refer to. So you can check which is the most recent commit in that, and which is the most relevant project, or the active contributed project that you can work with, which will be stable for a while before you actually use that in your project in production. So it becomes very important, and that's the whole essence of the talk, like navigating the landscape. So when it comes to the navigation, there are different criterias that we can formalize the landscape into. So first is app containerization. So whenever you have to deploy the application, what do you do? You actually containerize the application first. You use tools like Docker, Kaneko, Nerd CTL, or any of the other tools that you can do to containerize your application. You will be building an image so that you can actually deploy. Because Cloud Native is kind of CNCF was built around the Kubernetes. To deploy to Kubernetes, you need to containerize your workload. To containerize, you need some build tools and app definition tools that are there. And those are the categories, like application definition and the build. So you can see in the categories there are different type of tools which are there that can be used. Next comes the infrastructure provisioning. So after you have containerized the application, then you decide in which particular cloud you actually want to deploy. Like AWS, Ceo, Google, whatever it is. And then there are different infrastructure as code. Infrastructure as code provisioning tools that gives you the power of defining your infrastructure in an automated way. Because now we are not in an era where we are defining everything manually. We have amazing tools that helps us to define our whole infrastructure. And it can spin up in a few minutes, depending on the time taken by a particular cloud vendor. So you have tools like Terraform, Pulumi, all those that will help you in the infrastructure, automation, infrastructure as code. It's not a fancy concept. But it is actually used in production in across all the major projects that companies use. Next is actually the container orchestration. So now we have picked up the cloud. You have created your compute, network storage. You have created all the resources that are required now. You actually want a container orchestrator. Because you have your containerized application or the microservices that you want to deploy to a orchestration engine. So you need to choose that. There are a couple of options. But the most effective one comes to mind is Kubernetes. So you pick Kubernetes, and then you install that. And you will be having a base ready for deploying your application. Now I have mentioned security and compliance here. Because security and compliance is not something we should be thinking of in the end. So we always talk about the shift lift approach. So that starting from day zero, you should be taking your security seriously, supply chain security seriously. So that is why the security and compliance landscape is also there. You know the four C's of the security, which are there, the cloud. So security at cloud level, cluster level, container level, and code level. So that is very important. So you have to be thinking about your security from day zero. And it actually gets implemented. So this is an overlapping thing. So it actually gets implemented. With all the stages, you need to make sure how you can implement the security with different cloud native tools. So this is how you will be going to a specific block of projects inside the whole massive landscape. And when you do the orchestration part, there are three major things. Obviously that you have to decide, the CRICNI and the CSI. So basically which runtime you will be using. Container D, Cryo, Docker is replicated. I mean removed in 1.24. So you can use those. And then you have storage. So what storage solution you will be using. Many of the cloud vendors will be having their own storage solutions. If you are self-hosting your Kubernetes cluster on the VMs, then you will be picking up a storage layer that whenever you create a persistent volume, automatically your volume will be provisioned. So you will be having a CSI over there. Also, without networking layer, your orchestration will not work. So you need a CNI solution for that. Flannel, Selium, Calico. So all these are the major ones. So you can choose from that. Now here, again, you always see a few projects which are there. You always see the status of the project that shows the maturity and the adoption. So that gives you the picture when you are entering the landscape, which ones are actually used in the production by many organizations. So that you don't start, like if you are planning for production, you do not start with a project that just got in. I mean, you can be their customer and drive their roadmap. But it's always like if you are navigating and you want something from the landscape, then you go by what is mentioned in the landscape. Next is the observability and analysis. So we have four observability pillars, monitoring, tracing, logging, and profiling. All of these have separate their pieces as well. Like you have Prometheus, Cortex. So basically, you'll be having Prometheus. Then if you want to go at scale, you will be looking at some of the tools. And same for tracing. You will be using some of the tracing tools. So all these comes. Now you have deployed your application. You need to have monitoring of your infrastructure and the application. And you need traces from it. You need profiling data from it. So there are profiling tools like Albus, Parker, and Pyroscope, some of the tools which are there. And same for the logging. Fluent D, Elastic, Low Key. So all these tools you can have a look at. Now again, these tools, they are also too many. Like in a specific domain also, there are like many tools. Let's say you have a particular problem in mind and you are navigating the landscape. Still, there are many tools. And there can be a way in which you can also narrow down. So we always have to follow the narrow down approach. So the next couple of bits and pieces would be GitOps. You need to have a CICD pipeline for your orchestration engine so you can use Flux, Argo, Rancher Fleet. All those projects are there. Then policies. Again, it falls under security and compliance. So there are different options for that as well. And service meshes. So when your microservices keeps on growing because your project will be scaling and maturing, so you will be looking at the service mesh options. And again, you'll be falling back to the landscape to see the state of maturity of these particular projects and which one to implement. Now, like I was saying, again, this particular piece also has many projects. How to choose a project when you stumble upon a problem in an ecosystem? So how do we kind of narrow down our search even with the small cards that we have picked out when we are navigating the landscape? So Kanal. Yeah, next one. Cool. So as I mentioned, this landscape is huge. Anyone here who is working in the cloud native field for a few years, I'm not sure. I mean, there might be a few people who know the entire landscape. But just in case anyone is here, I don't. Entire landscape, all the projects. It's pretty, pretty big, right? And the second point I would like to mention is that, like Savita mentioned, the fourth kind of projects that are archived. So it keeps on evolving. New projects keep getting added in the same categories. So you may be wondering, OK, I'm using this for logging or monitoring. Now, this new thing is out. Should I use this? How do I migrate? And all these other things. So when you stumble across a problem, let's take an example of the previous slide only, the monitoring one. So the two more important points I want to mention is match your requirements with the project's specifications. So if you talk about, like, Prometheus, what it has to offer, you're using that, and then you want to do it at scale. Then you look at something like Thanos, and, like, No Cortex, and things like that. So that's the first point. Like, match the requirements that you have for your own project with the project that are in the landscape. So that's basically how we do it. And it's not like you, what is the word I'm looking for here? So the landscape is huge, right? So you don't randomly go on looking for projects and stuff because that can get really overwhelming. So the landscape is huge. So many tools in just one particular category. And you're, like, picking up every tool. OK, this, this, this, this, this, this, this, this. Instead of doing that, match the tools that you're picking according to the requirements. Then the second point is for, like, the future proofing part. This is also very, very important because of the migration thing that I talked about. So think about scaling from the start. Create some proof of concepts, POCs, for multiple projects. So when you talk about Prometheus, like at scale, talk about, like, Thanos, and other projects, see what they have to offer, what you're trying to do. And this is important because if you don't consider this at an early stage, you're going to have trouble migrating later on. And folks do face this issue. I've seen, like, at a later point in stage when they're like, OK, we should have thought about this, how we're going to adapt to this project. So that's basically the way to go. Most of the projects are extremely active. There's a huge community support behind them, like Prometheus and, like, Kubernetes for obvious reasons. So I think it's a pretty self-explanatory in that domain. But these are the two important points that I wanted to mention about picking the right project. So not just going in a maze and checking out what every project has to offer, but focusing on the requirements that you have. That thing, that is sort of like the narrow downway of what Sayum was mentioning. And that's sort of like, according to the theme of this session as well, which is navigating the landscape. So according to your requirements, and think about scaling right from the start. Right. So I think that's a very good segue into our next one, where we are going to talk about CNCF terminology that people starting out. Because a lot of students are going to be watching this. So what are some of the CNCF terminologies that everyone should be familiar with? Because every ecosystem has its own. So Savita? So let's get started with the CNCF members. So there are companies who are CNCF members. And there are levels, like platinum, gold, and so on. And those members are the one who are actually taking advantage of this project. And they are building their project on top of it. And then there are end users. And there are about 145-ish organizations that are part of the end user community. They are like a vendor-neutral community. They are just consuming these projects. So they can provide feedback to the CNCF community. And they can also get involved in the tech radar, if you have noticed that there are CNCF tech radars, like observability radar, and so on. So moving on from that, there are two more boards. One is TOC, that is the technical oversight committee, which is responsible for overseeing the technical discussions and having a say when a project can graduate, or when a project can get into the sandbox, when a project can graduate into incubating, and so on. And then there is this governing board, which will be responsible for the business decisions. Of course, every company needs someone who is responsible for those big decisions. So that heavy thing falls on their head. Moving on, and there are tags. So these are awesome, right? Tags are like the technical advisory groups. So they are like, if you have ever contributed to Kubernetes, right? So you would have come across the special interest groups. So these are like analogous to that. Tags are like they focus on specific section of domain, like, for example, app delivery, and security, and stuff like that. So they focus on the projects that involve that particular domain, and they help the project move from the sandbox to incubator, or they even help make the technical decision or have the discussion. Make a place, they create this environment where the communities can come together and talk about that, all the discussions and share it with the world, right? So that's there. And there is a huge shout out to the glossaries. So if you have come across this or not, like the CNCF landscape is like a lot. There are a lot of abbreviations, and then there is a lot of definitions. Like I can't keep up with everything. And so if you want a quick note on a refresher, you go to the CNCF glossary website and look for the definition or the abbreviation and you get the idea of what that word means or what the abbreviation means. So that's there. And that's the basic things that you need to know before you get started. In addition to the projects and all the landscape that my fellow panelists discussed. Speaking of shout outs, when you go to the landscape website, there's also a guide that has been created that lists out all the best practices for navigating it and what it's all about and some of the best practices as well. So make sure you check that out as well. It's on the same website. So when you go to the landscape.cncf.io, so you will be having both the landscape and the guide. And the guide walks you through the different sections of the landscape. And it will give you the technical overview of that as well. And so now we have understood the cloud native. We have navigated through it. We have even picked a few projects than a POC for the particular project. We know some of the terminologies about the CNCF ecosystem, the glossary and stuff. The last thing that we would like to bring is what are the possible areas of the contribution in CNCF because that is important. So people come in. They want to use, but there are another set of people who want to contribute or they can be the same set of people who use and contribute. So what are the different areas for contributions? Divya, can you throw some light on that? Yeah, absolutely. So there are two broad buckets. And by broad buckets, I really mean they are broad because there's the code part of it and then there's the non-code part of it. So in coding, you obviously have the entire code base. And you also have the infrastructure provisioning where everything is there. I'm not saying no. But I've just divided it into these buckets for the simplicity of everyone's understanding. So you have those two broad areas to contribute. And when you speak about non-code contributions, they're as valuable to be honest. And please don't feel that any project within the CNCF or anywhere else doesn't need them because non-code contributions are as important. So one of the areas that you possibly could get started with if you're at a big node level and considering that you could possibly be intimidated by the fact that the landscape is so vast and the ecosystem is so vast is with the non-code aspects of the project. Now, what this could be in a general way would be maybe contribute to the docs of the project or maybe help with the contributor experience if you are in a larger project or help with just the overall onboarding and stuff like that. So these are very small things that you could do to take your very first steps into the ecosystem. But I really, really do need to take a small detour here and give a huge order to stuff like the LFX internships that actually provide students and people who are interested into getting in a structured way of contribution, take their very first steps into the ecosystem. Because internships are a great structured, time-framed, time box, sorry, time boxed way of getting to know the ecosystem without actually having to routinely contribute to it. And fun fact is you also get paid for it. So I mean, that's a perk. So that's one thing. And there's also a bunch of stuff other than the stuff that I've mentioned in the non-code bucket. Like you can also work on catching, triaging bugs and helping with releases. In fact, Kubernetes has a brilliant shadow program so that's something you could check out. So there are a bunch of avenues. So you really don't need to feel intimidated while taking that first big step which might look like a very big one. So that's one thing. And the last thing that I would like to mention is for all those who are starting out, there's also a brilliant certification exam. And this is not a plug. None of this is a shameless plug, yeah. But there's a brilliant certification exam, the KCNA, which was introduced last year. And it's one of those things that helps you via the way of learning to understand more about the projects in the ecosystem. So Sayum and Kunal and Savita have talked very much about how to navigate the ecosystem and its various terminologies. You can test your knowledge via that particular exam. So those are the broad ways in which you can get involved and learn more about the ecosystem. And I generally hope that you found this session helpful because these are some of the questions that we've frequently been asked as active contributors. However, I think given that we're at the end of our presentation right now, we'll be open to any questions that you might have. And yeah, so I think you'll have to go to the back or you'll have to come here to take the... While we're doing that, see one of the most questions that we get are with the overwhelming nature of the CNCF landscape. So I would say it's not a negative thing. These projects are here to solve problems, specific problems. So when you look for a definition in a dictionary, you don't go starting from the very first page and go through the entire dictionary to find the problem. The dictionary has so many words and you're looking for one particular solution and you find that relatively quickly because it's organized in such a way. So you can think of it all the words and everything in the language as the projects and the CNCF landscape as the dictionary that is organized and you're trying to navigate it with the tunnel framework that Saiyam and everyone at the panel mentioned. So the more the merrier, we have heard about that. Not always, but in some cases, but according to your use cases, you can navigate it and yeah, we're happy to take questions. Go ahead. So thank you so much for the wonderful presentation. This is a very quick question. So as you mentioned that the CNCF has a very wide landscape. And in general, if you generally talk about the technologies that the underlying technologies that are there and given it is, it does require you to have a good knowledge about computer networks and operating systems and all right. So of course, they're having a lot of initiatives like the cloud native students, especially for students to actually get into cloud native and also like you simplify. So would you mind sharing about your experiences having driven these initiatives and how this has actually helped a lot of young learners to get into the world of cloud native? Yeah. So basically, we are CNCF ambassadors and we always try to kind of help people in getting into cloud native, teaching about cloud native, creating various initiatives regarding the same and like you mentioned, Cube Simplify is one of them. So basically people are learning stuff and they get stuck and after learning, what do they do? So there are various ways like contributing to the project, heavily shapes their career, contributing to a new project which or they can start building their own project with a team, hackathons. So all these parts, they contribute to shaping up their learnings, their journey, also learning in public, like whatever you're learning, you document your journey, you create videos out of it. It's very common these days, especially in the pandemic, you write the blogs and you like ask for feedback and again, coming back to the non-code contributions, you can use those learnings from the blogs that you have written into the documentation, contribution into different projects. You can use your coding learnings, whatever you have done like Golang, Python to use that and pick up the good first issues and solve that. The maintainers need it. So if you ask anybody, like Josh you said, like if you ask anybody, we need the people to kind of contribute. So the people to contribute are less and the demand is always the more. So you need people, we need people and you should be like, you have to be in a way, I don't have to learn, I have to learn and contribute. So that is the way. And for students, there are like many initiatives that is the CNCF is always trying to run. They created the student track itself, so that shows how much overall the ecosystem is thinking about the newcomers getting into cloud native from the basics and creating an inclusive community, helping them navigating through different aspects of CNCF. Also the point you mentioned about there being so many things in the underlying project that you need to know about, students, I'm speaking as one, this thing called imposter syndrome. I think that's a, you can look at the optimistic side of it when you find yourself in a place where you don't know much about something. So that's an opportunity to learn and contribute. So it's definitely nothing to be like ashamed about. You are students, you are learning not just students, anyone who is getting started. No one was born with, you know, when Kubernetes was donated in 24, it's not a good analogy, I should have thought this through. But anyway, no one was born with an expert in K8s or whatever or anything. You all learn and everyone was a beginner once, so have an open mindset especially when contributing to open source. Thank you. So have an open mindset when contributing to open source. It's okay not to know everything, but what is required is have an open mind and learn by doing. So you don't have to be an expert. You can just, you can start today itself, you can check out various SIGs in Kubernetes, start contributing to documentation. So we can help you in that, thanks again. And that's it, yeah, next question. Yeah, this is one final question. So as we know that there are a lot of different projects within the CNC of landscape, sharing some light into, because we are seeing, right, there are a lot of companies today are building open source projects and they're giving back to the community. So if some organization wants to basically create a project that is open sourced and they want to let it inside the CNC of landscape, how, what's the process of doing that? So I can comment on the overall process, obviously not the specifics. So the way you do that is by first, you know, submitting a PR, that is the basic process, but there's a lot of stuff that goes behind the scenes for that, because it's not just about submitting that PR because in that PR also you're required to list down your, what all is the stuff that has actually gone into while, you know, making that project and what is the stuff that is actually, what is the actual problem that your project is solving in association with the cloud native ecosystem because it has to make sense in the wider, you know, in the larger sense of things, right? Because if it's not solving any problem, if it's not really, you know, filling any gap, then there is no use of a second thing. Alternatives are good, but again, how many alternatives do you really want? That is the thing. So first thing is, I think, when submitting an application or a PR, what normally gets addressed is what is the project that you are, what is the problem that you're trying to solve? What is your project doing? You have to have some, at least a basic outline of, not basic outline of, good documentation. You have to have, like, basis the levels of entry that Savita spoke about in terms of, you know, the sandbox incubating and stuff. You obviously have graded criteria. So it doesn't really start off with a large community. Like, it's not going to be Kubernetes on the very first go. So you have to, you know, sort of build your community, you have to sort of tell the people at CNCF what is the thing that you're trying to solve and put it in the context of the wider ecosystem and then, you know, tell them that, you know, whether there are any specific areas that you're trying to grow within the project, whether it's stable, whether it's not. There are a bunch of things when you submit a PR that you do. And obviously the behind the scenes work is more than just that. So yeah, that's the basic gist of what happens when you submit the PR. Thank you very much. Yeah, just to add one thing. So the sandbox incubating and graduation, they are all well documented on GitHub, checking out, you know, what all steps are there, what all things you need to do, the criteria, the adoption from the community, that has to be there for a particular project when you put against that. And also TOC is kind of changing the process of the sandbox specifically, so that it can be much more, you know, faster in the way the project gets in the sandbox stage. So always keep looking out for that. And the TOC channel is there, which with open communication that you can always look upon. Cool, thank you all for attending till the end. Nunu has one. Oh, sorry. Yeah, I see that you don't want to talk to me. So the questions will be for the three others. Thank you. No, actually, Shiva had exactly the same question as myself, so thank you for the talk. And one last thing is like, when based on your experiences and from the eyes of a student then, when do you think it's good to move from using to contributing at the stage of the knowledge, right? So to avoid maybe some frustrations, till continuing maybe learning, but when did you see maybe it was good to say like, okay, now I can contribute. Now I'm, let's say, I am easy enough or comfortable enough to be participating also in this project. You wouldn't know once you, like until you start. I think while you're learning, just go for it. So I started my contributions when I just knew like Java and I contributed to a Java Kubernetes client. So I learned on the go, started like with some basic documentation, then testing, so testing is a good area for contributions. If you're new to, you know, such bigger projects, and then you sort of like build upon that. So to answer Nuno's question, while you're learning, you can contribute. It does not matter how much your knowledge is. That's true because you can even do non-code contributions. So when I was contributing to like kids, one month I spent doing nothing, but attending the meeting calls. That's it. That was a story of so many people. Yeah, I did nothing. I spent six months attending the meeting. I was just attending meetings and after that you will get to understand, you can contribute in so many areas. So you can start with non-code if you're a beginner. You'll understand how the ecosystem works, but you don't have to be like an expert. Don't be stuck in the, it's called the tutorial hell. Like first I'll complete this entire thing, then I'll contribute. I would not recommend that one. Learn by doing, contribute while doing, while learning. Learn by doing, contribute while learning. Nice, I can tweet that. Okay. And also pace yourselves. You have the entire life and don't burn out because like there is, it's not like you have to do your coursework. I, we understand, we are being students and these things are like amazing. Open source is so awesome and great and you contribute whenever you feel comfortable, right? So it's not like, you can go about it in any way. Like for me, if I wanna learn something, I could start, I would start attending the meetings that I'm interested in and I'm like, they'll be like good first contributor issues. Like I like to learn and grow at the same time, but whatever works for me might not work for you. So there is no one solution that fits all. There are perspectives, right? Like I had a perspective, I have a perspective. So whatever works for you, right? And you can always reach out to us. Like we are all available in Slack. We have our Twitter handle and we should have put the Slack handle. So we are all available in the Kubernetes Slack and you can just find us by name and reach out to us, right? And there is a CNCF students channel in the CNCF Slack. So put your questions there. Someone or the other will always be there to respond and keep in mind that if you don't get a response in a day or two, don't be disheartened. I have been there and I know that could be first dating but also means that the maintainers are probably a little busy and they'll get back to you, right? So these things can happen when you are a student. And when you are, not even a student, when you are any level of contributor. So just like these are the little things that you can keep in mind. Sorry, Nuno, I didn't have the right answer. It's just like, overall, yeah. Please, that was it. Just concluding, it won't happen overnight. I'll take some time to be a contributor. So enjoy the journey. Thank you, everyone. Thank you.