 Hi, I'm Lofors Polter. I'm a DevOps engineer at SecureThings, an instructor and mentor at Ops School, an urban sketcher. So you'll see my illustrations on the following slides and a cancer survivor. And you can follow this QR code to learn more about me on LinkedIn. So a few words about SecureThings in Ops School before I start. SecureThings is a startup focused on helping organizations manage and secure their physical devices at scale. And you can learn more about us following this QR code to the SecureThings site. And Ops School is a nonprofit school run by volunteer DevOps engineers like me, but aims to diversify the Ops community. We run a six months intense training course that takes students from various technical backgrounds and transforms them into DevOps engineers. And again, the QR code will let you check us out on our site. So you build a get off system. Why do you care about teaching get off? It's not your job, is it? It's your job to build a system, not teach about it. Well, if you don't teach it, people will find ways not to use it. They already have a CI CD system that they know and like. And if you're going to replace it and not make sure that everybody feels comfortable with using your new system, what's going to happen is that they're going to find a way to not use your system. So basically, teaching is advocating for your new system. Your get off system is not a self contained, self maintained island. You will need help from other people, whether it's help with the move to the new system or whether it's help with maintaining and setting up the new system or whether it's helping themselves take care of their own deployment when they fail or if they need to roll back or if they need to perhaps even set up their own applications. So if you want to spread the work around, you're going to have to teach people about your new system and about get ups in general. And basically it's just good manners. So we're going to have a little quick refresher about what push get ups versus pull get ups is because I'm going to mention it a few times in the following slides. So push get ups is your basic CI CD pipelines. They push changes to your environment based on some sort of commit or merge via webhook. This is basically Jenkins. Pull get ups is an agent running in your cluster that continuously pulls your get repo or container registry changes or detect mismatch between what's currently running in your cluster and what is found in the get ups repo or the container registry. It pulls the change into the cluster. So this is basically our go CD and friends. I'm going to talk about teaching get ups through four case studies. Each one describes a certain kind of audience. If you don't find your audience in one of these four case studies, that's okay. In the end, I'm going to talk about the general tips that apply to all kinds of audiences so you can get some help there. Case one, teaching get ups to a group of DevOps newcomers. This is basically the obstacle students that we teach and the inspiration for this talk. And they are also the inspiration for this illustration. Yes, this is based on a true story. Oh, no, your audience. These people have some background in tech, QA, IT development, but no experience with CI CD as a concept or with the tooling. They have little to no experience with it. They have little to no experience with Kubernetes or Docker. They have some knowledge of the scripting language, basic cloud knowledge, basic Linux knowledge. How would you introduce get ups to them? Some things we found that worked. You want to start with a solid grasp of get Docker and Kubernetes, which means that you're going to have to close those knowledge gaps first before you build up on them and start teaching get ups concepts, et cetera. We found that Docker as VMs are a several starting point in Kubernetes, much simpler to understand and to get up and running. And for that reason, Jenkins on Docker, our VM provides an easier starting point under these circumstances, which means we start with push get ups and not pull get ups, even though pull get ups is all the new hotness. What we do is explain the building blocks and stick to principles over tools, because then you can switch the tools. And we all work in a field that has constantly changing tools. And then I mean, next month, something can come out that will turn our go CD and flux into something that nobody wants to use. Which is why we stick to principles of get ups and not the specific tool that we are using. Hands on is as valuable, which is why our students build their own sort of sandbox system and write their own code, which they then have to deploy to that system and and change and continually deploy. So they get to learn and they get to make mistakes in a space that's safe and with code that they know. So it's an easier place to start in and they get the better feeling for both the flow that they're creating, and also actually how to apply the knowledge that we're teaching them case study to teaching get ups DevOps supplies, if you're introducing get ups to an existing DevOps team. And your audience, these are experienced DevOps engineers, they have good grasp of git Docker and Docker compose. They may have some knowledge gaps when it comes to Kubernetes, which is usually the case if we're talking about introducing get ups to an existing team. They will have experience with CI CD tools, whether it's Jenkins, Ansible, puppet, et cetera. They will have good scripting skills, good cloud provider knowledge and good Linux knowledge. And they will have no experience with code get pull based get ups tools. So how would you introduce get ups to them? And things to apply. First of all, just like in the first group that we discussed, you need to close any knowledge gaps before you can continue. In this case, it's in Kubernetes. You can't talk about get up system without having those basics. Set up first. Introduce the proposed tools and start with a simple setup possible. I've asked for application sets, for example, use resources offered by get up tools providers. They oftentimes offer courses, certifications, workshops, meet ups, a lot of them are free. And they're usually very, very good. They aren't good for complete, complete beginners, which is why we don't use them in op school. But for experienced DevOps engineers, they provide an excellent tool for learning. Again, hands on is the best for learning just like in the first group that we discussed. You want to give people a chance to install, to set up to mess parameters, to try to get some apps working in some sort of a local cluster or sandbox environment. The biggest hurdle will be to get set up and get flow changes that come with these tools. And this is something that you will want to have with the discussion and not as you dictating how something should work in the get ups world. And it's usually something that will require several rounds of trial and error and will require an open discussion on equal terms between you and whoever it is that's currently managing the CI CD and the get set up. So that the transition is as easy and as smooth as possible. Okay, study three, teaching get ups to developers. It's pretty self explanatory. Know your audience. These are experienced developers. They're used to working with existing pipelines, they have created string and their own pipelines and whole workflows around the existing CI CD set up, they've invested in it a lot. They likely have also known Kubernetes knowledge. If you're introducing get ups to them, you're like you may be the first one that's also introducing Kubernetes to them. And they usually have a robust set up of git, especially where it breaks. So how would you introduce get ups to them? Some things to apply. Again, just like in the first two groups, you want to close any knowledge gaps first. In this case, it's usually going to be Kubernetes. It might be some dark and sketchy corners and git, but it's usually going to be Kubernetes. Find a champion or two to help you spread the word. This is crucial with this group. Developers usually invest a lot in CI CD setups. So you are going to take something that they know, and that they have learned to use, and that they have invested in, and you're going to change it and into something new that they don't know, and that will require work from them. And that will not be as easy for them to use that first will always be some sort of gap and some sort of learning curve. So what you want is somebody who is a developer that will champion your new setup that will help you spread the good word and say, Oh, man, this is so great. This is much better than the current system. Look how it's improving my life. Look how it's making things so much simpler. Look how I can do all these cool new things that I could not do before. And in the same vein, you want to emphasize the developer from the aspects of the new setup, whether it's the UI, it's the new deployment patterns, it's how easy it is to deploy things or to roll back things, or to see where things are. This is important. I'm looking to get a feel for the GitOps agent to use in a sandbox or local environment. This is just like in the two groups that we talked before something that's crucial. But in this case, it's very important for them to get the feel for the system so that they can build confidence in it and feel more comfortable with it in order to trust it. Because it may look like magic from the outside, but they have to trust the system. Talk to them about the new Gitflow, any repo changes and what a GitOps commit looks like. Any new chosen setup. This is important because this is something that they will constantly work with. And you need to be open to have a discussion about it. You might not immediately get them to go all the way with exactly your proposed change. And they might have some insights that you don't have about the system that they use currently, because usually you don't have the whole view of how the CICD works, because they oftentimes add things to it that you aren't even aware that they added. So you want to have this part as an open discussion again, not dictating, but have a discussion be willing to listen and not just stand and lecture. And you'll probably get the best results that way. Case 34, teaching GitOps to managers. Know your audience. Unlike the first three audiences we talked about, these people will not have to work hands on with the tools or with the underlying technology. They will, however, have to prioritize the move to GitOps. And so they need to learn about these tools. They're focused on business value and costs, and you need to understand that. You need to accept that. And they may be familiar with some GitOps tools, but they're usually familiar with them at the buzzword level only. So how would you teach GitOps to them? Some things to apply. Focus on the principle of GitOps more than the tooling, declaratively described systems, version and Git automatically applied and monitored by various agents. Not this is how our OCD works or this is how flexible. Emphasize business value. This is crucial and it's something that's going to be the basis of all your discussions with management on your new tools. Because GitOps comes with a lot of business value. Whether it's compliance or whether it's the fact that GitOps allows for faster and safer deployments with their fallbacks, with their recovery, that it helps developers and DevOps teams be more efficient and productive. And that allows you to more easily grow and scale. These are all things that have business value. And these are all things that help with business costs. And you want to emphasize them. And you want to compare your new system to the current CICD system, you want to put them side by side, so that managers will have some sort of reference point as to the changes that you're going to make and exactly where the improvements come in. So let's say in your old system, you could deploy maybe three times a week. In the new system, you can deploy several times a day. In the old system, it took an hour to deploy. In the new system, deployment takes seconds, etc., etc. Some general tips to end on. Identify your audience, identify their interests, and try to speak to those interests. So a developer might not really be interested in the cost benefits of moving to the new GitOps system, but they will be interested more likely in the debugging options that it now offers them or the cool new UI that allows them to see where things exactly are in the cluster in a very visual and simple way. And also, tailor teaching to honest in terms of how you teach some people like YouTube videos more, some people connect more with in person teaching. Some people like to just read things. So you want to tailor your material materials also to your audience and not just your content. Don't be afraid to learn public. That's something that Kelsey Hightower taught us and it has a lot of value. If you're learning something new, invite others to join you on the journey and bring yourself into the process. Make it personal. Talk about where you struggled with the new system and what you think that's really cool and awesome about about the new GitOps system that you're building. It helps people connect. And metaphors and stories are also very useful as teaching devices. So don't be afraid to add a little flair to it. It makes things much easier to understand and to remember. And it helps break down really complex ideas and notions into something that's more simpler and more digestible to your audience. And come to it with the right attitude. I want us to share to learn together. Patience and remember, every day someone is born was never heard of the Simpsons. So don't be afraid to say, I don't know, but I can learn. Thank you.