 And hello, everyone. I'm very excited to be here because I know that I think we can all agree that things in this industry and in CNCF in general is moving pretty fast. So we're seeing all these new projects every month. And large and old CNCF projects are continuing to grow and still get new features every month. So this is what I think makes it so really exciting to be a site reliability engineer right now. But it also comes with a lot of challenges. We have to stay up to date with everything that's going on. And it can be quite challenging for a student, like me, to get a foot into this field when you really does not know anything about it and the universities does not really seem to care that much for this field. So for the next 30 minutes, I will be telling you about my journey and some of my stories from my adventure from going from a student to a site reliability engineer at Luna. So right now, I'm a site reliability engineer at Luna. I've been at Luna for around two years. My name is Jacob. And I'm also a student at Orange University, which is located in Denmark. I'm studying for a Master of Science in Computer Engineering. And I've been studying for around four years now. So Luna is a Nordic bank with around 500,000 customers. And we are around 650 employees in Luna. And it's quite new Nordic bank. So we are trying to use technology to disrupt the Nordic banking market and challenge the old incumbent banks. To do this, we are trying to move very fast. And we are releasing on average 14 times to production every day. And we have a lot of microservices around 450 and 150 full-time tech employees. So this is basically a simplified version of the platform that we have at Luna. We are having Kubernetes, as I guess most of you are, and using it together with LinkedIn to create this multi-cluster service mesh that spans across the three large cloud providers, AWS, Microsoft Azure, and Google Cloud. And we are using this to make it possible for our internal developers to leverage the managed services in each cloud to what they need. On top of this, we are using a lot of different CNCF projects. One of those is Flux and Backstage. And we are also creating a lot of open-source tools ourselves that we mix with all these CNCF projects. So can I hear? How many of you in here are students right now? Yeah? I think we have four, five, six for the 10. I think that's 10% of the audience. Quite nice to see at least some students at CNCF in KubeCon. So as I said, as a student myself, I've been studying for four years. And this is Oldham University, quite beautiful, I think. So if we go back two years into my studying, I kind of learned how to write code. I learned C, C++, C-sharp. But I did not really learn anything outside of that. So it was kind of only code-based. So if you back then would have asked me if I knew how to build and deploy a piece of software, I would probably just have said that you push the green run button in the top of Visual Studio. So I really wanted to learn a lot about what's outside of the code itself, how you push code and release it to production and connect it to the customers. So to do this, I started at Luna as an intern in the summer of 2020. And I really want to recommend to students that if you want to kind of gain some experience with site reliability engineering, I think an internship is a good opportunity because, to my experience, it does not really get a lot of experience with this at the universities. So when I started at Luna, my colleagues and I, we were discussing, where do you start? How do I get my first foot into this field? So what we were thinking was that to be a good site reliability engineer, you have to learn and know how your customers think. And to site reliability engineers, at Luna, we perceive our customers as the internal developers. So I kind of had to know how our developers think and how they release code to production to be able to serve them well as a site reliability engineer. So my first task as an intern was to create this release manager bot, which is basically a Go service. It's an infrastructure tool, but that's not so important because what I did was I used Go, the language that our developers at Luna use, to create the service. So I knew how they felt when they were creating code. And I learned how they also was releasing software to production. So I learned some Kubernetes, like config maps, ingress objects, deployments, and so on. Even though our developers not really have to know these kind of things to release software. So the first thing that I figured out that was quite different from at the universities was that I get a lot of feedback on my pull requests. So yeah, as you can see. So at the university, you hand in an assignment and you get pass or fail. Maybe one sentence comment on your assignment. That's not really how it's like when I was at Luna or when I'm creating pull requests in OMSource. You get a lot of feedback and comment. And you have to learn to take that very nice and take it as constructive feedback. And it obviously makes a lot of sense because I had not really been writing Go before. So it makes sense that I get a lot of comments on what I'm creating. So can I see how many of you have contributed to a CNSF project before? Raise your hands. We got some, I don't know, 20% of the audience. Nice. So I really want to also hear some of your stories about your first contribution to the CNSF afterwards because I will be telling you about my first contribution to a CNSF project. And it was to Backstage. It's a fairly new project, I would say. It's, I don't know, two years, three years old. So it was in the beginning of my internship that I started contributing to Backstage. And I'll now tell you about my first contribution. So Backstage is an open platform for building developer portals, and it unifies infrastructure tooling, services, and documentation in one place so that it reduces the complexity that the developers experience. And it does this by using a centralized software catalog. So after I had created this Release Manager bot, my colleagues and I were discussing where do we go now. So a good idea, what we thought was that it was a good idea to kind of get me into this open source space so that I would get experience with open source projects so that I would be better able to adopt CNSF projects. So my colleagues thought this project was very exciting and wanted me to adopt this. My first thought about that was, how are you expecting me to do this? I do not know anything about Backstage and the language that is written in the package manager that it uses. So what I discovered was that they did not expect me to know all these things. I kind of just had to learn it. So I took on the task, and I tried to adopt Backstage, but I stumbled into a challenge. How do you import private GitHub repositories into Backstage? I could not figure this out, so I kind of had to talk and meet, not meet, but chat with some in the community in Backstage. So I had to also figure out how to connect with these people. So how do I reach them? What I figured out was that in the GitHub repository in Backstage, there is a link to a Discord chat room where the Backstage maintainers and the community are talking with each other and sharing knowledge. So what I did was, and I think this is maybe special for Backstage that it uses Discord because I have seen that a lot of other different C and CF projects are using Slack. But this was actually quite nice for me because I had experience using Discord. So it was kind of nice to use this for my first entry and interaction with the open source community. So I wrote a message to the community in Discord and asked them if they could point me in a direction where to find this kind of thing where I import GitHub repositories into Backstage. And it was not supported. So what I thought was, we're doomed. There's nothing that I can do to adopt Backstage. Of course, I was wrong because I could just create this feature myself. So that was actually what I did. I tried to hack to get some code. Written in TypeScript, I really had no experience doing that. And trying to use the React framework and things like that. So I hacked to get some code, had it actually working. And then I wrote back to the community and asked if they wanted me to contribute with it. And they did. So I polished my feature, the code, and created a PR the next morning. And I got a lot of change requests on that PR. But that's completely OK. I had learned from my internal developing the release manager bot that it's completely OK to get a lot of change requests. After all, I did not know anything really about the code and the code base in Backstage. Also, I think I forgot to remove some console.log lines. So the maintainers were very friendly to remind me of that. So they helped me improve my PR so that it could get approved. And I was very happy that I could go now and tell my colleagues that we could now finish the adoption of Backstage because I had contributed with a PR to the CNSF project Backstage so that we could adopt it. So to sum up my first contribution, I found a feature that was needed. I asked the maintainers to verify that it did not exist. And the maintainers helped me improve the PR so that it could get approved. So many would consider the previous example a textbook example of a open source contribution. But it does not have to be features and hard code like that. It can also be a lot of other things. So I want to show you by telling you some different stories from my journey how you can also contribute to open source projects. So after I had adopted Backstage, my squad and I, we were thinking about a new cool feature for Backstage. And it was this kind of squad page where our squads could go and see squad specific information, like success rate, new critical vulnerabilities, new releases to the services that they own. So it would be like a page that they go to in the morning when they had to get a cup of coffee. And then they would sit there and watch what is the vibe of the squad right now. So I created an issue in GitHub, the Backstage repository, where I described the need and proposed a solution. And I discussed this issue with the community. And they actually thought it was a good idea. So I did not create the code for this feature, actually, because there were some other things going on, other places in the community. So some people was creating a group entity which this feature would fit well into. So even though I did not contribute with any code, I shared my knowledge. And together with the community, we came up with something quite good, better than what each of us could have come up with ourselves. So I still think it's valuable to contribute with things that's not code itself. So fast forward some months at least. After my internship, I was studying for the certified Kubernetes administrator certificate. And I was reading through the Kubernetes documentation, following a guide of I think it was how to upgrade the KubeLit on a note. And I found this tiny, tiny, but annoying thing. Yeah, it's pretty much just that there was some space propended to some commands. And then when you copy these commands into your console, your console would be filled up with spaces, unnecessary spaces. So I wanted to create a very small PR that just kind of improve this documentation so that I and my fellow OMSOS people did not have to experience this. So this was probably, it's a very small PR, but it approved this very tiny, but small thing. So it just goes to show you that there are other ways that you can contribute. You can contribute to the documentation of Kubernetes and other projects. You do not have to contribute with code in your first contribution to OMSOS projects. And actually, there is a doc special interest group for these kinds of things. And that's, I think it's a very nice place to go. If you want to get your first contribution into a CNCF project, you can go and visit this friendly community of people that are maintaining the Kubernetes documentation. So fast forward to another example or another story. So we were upgrading the LinkedIn version from 2.11 to 2.10, but 2 to 2.11. And we stumbled into this issue when applying the new configuration to our Kubernetes cluster. So I initial thought that it was just a misconfiguration by us because you do make a lot of mistakes. But after doing a lot of debugging, I could not simply figure out what was wrong. So I wrote to the maintainers of LinkedIn in Slack and they replied back that they had not seen something like this before. So they wanted me to create an issue or a bug report describing this. So that's what was what I did. So I'll just describe the need and what we were seeing and maybe a solution for this. And the maintainers wrote back that they were very happy that I contributed with this because it was actually a bug that they did not know of. So now they could improve this. So again, this is another way that you can contribute to CNCF projects. You do not have to just contribute with code, you can contribute in other and a lot of different ways. Also, I think in the most ways that you are interacting with the community, that's also contributions. So after my intro chip, I had learned to adapt and to contribute to a lot of different CNCF projects. But as I told you in the beginning, there are a lot of different things happening at the same time and new projects coming up and old projects evolving. So we kind of have to continue to learn and keep learning all of these new things. So I just want to share with you some of the ways that I try to learn and try to stay on top of what's happening. So the first thing is to join conferences. I can obviously see that all of you know this or are doing it yourself. That's great. I joined conferences to hear exciting talks about, by exciting people that really are excited about projects that they are maintaining and know a lot about. So this is like a way to get a lot of deep knowledge, I think. But you cannot go to conferences all year long. At maximum, I think people are going to a conference one or two times a year. So I also join and attend local events by cloud native community groups. I think this is also a great way to network with people from your area and see how they are using CNCF projects to solve real world problems. Also, I use this to get some experience and see what they are doing and get some feedback on what I am doing and what my squad are doing. So that's a great way to network with other people and talk about CNCF projects. Also, talking at a local event is also a way that you can contribute to a project. And often, that is a way that you can start a lot of little talks about the project that you are contributing to. So I just want to share with you a map. So just to see that there are a lot of different community groups out there in the whole world. And the list on the left is, I don't know if it's clear enough, but that's the community groups in Europe. So I just want to encourage you, if you're a student and you want to become a site reliability engineer, that you try to join a community because it's a very great way to get to know and learn the processes around CNCF projects so that you are able to efficiently adopt these projects and create a platform based on them and interact with the community if you're stumble into issues when adopting these projects. Also, being a part of the community is also a great way to stay on top of what's happening. So you talk with people in the community and see what's on the roadmap and what are they thinking about the project. And you don't have to be a part of this community for a whole career. You can just do it for a couple of months or whatever you like. So before I tell you the last part of my journey, I want to share this brilliant tip with you. So if you're a student and you want to learn some Kubernetes, but there's no course at your university, this might be interesting. So there's this special kind of course called a study course. And it might be called something else at your university, but it's a elective course where you choose the curriculum yourself. So what I did and what you can do is then copy the curriculum of the CKA certification into the study course. And then you will have created like this Kubernetes course that you can study for yourself and learn Kubernetes at your university. So you don't necessarily have to take the actual CKA exam, but you can do it if you like to get the certificate that proves the new knowledge that you have gained. So the last part of my journey is obviously presenting here at KubeCon and CloudNativeCon. I think that this is also a great way that you keep learning and discovering new things that you are presenting about. So if you really want to learn something new, then submit a talk to KubeCon. And then I will probably think that you will prepare a lot for it, and then you will learn a lot about this topic. This makes you also kind of discover new things that you may have not have considered before. So to sum up my talk, if you're a student and you want to become a site-reliability engineer, I recommend that you try an internship and that you, in this internship, engage in open source and that you, of course, afterwards and in your whole life keep learning because I think the new and exciting things is what makes it so damn exciting to be a site-reliability engineer. That's all. Questions? Thanks for the talk. So about the university, did they have any course? They didn't have any courses in Kubernetes or something similar, right? But have you engaged with them to kind of see if they would be open to anything like that? Yeah, I have engaged with them. And there also was a kind of distributed systems course. But it was not really that great, and the teacher just left the university. And it's very hard to find people and teachers with these skills because they are so people in the industry really wants to give them a job. So it's hard for the universities to attract them also. So I guess the universities kind of want to it, but it's also kind of hard to have this course because it takes a lot of time for the teachers to stay updated on what they are kind of teaching. Definitely agree, kind of same experience. The thinking is if all who's had some, I don't know, magical recipe. Any questions? I guess that's it then. Yeah, thank you. Thank you.