 Hi, welcome to my webinar on understanding Github use cases, Github's use cases. I'm Awabuka Siddique-Angu and I'm a developer and manager at Github. Github is the newest of the cool things happening in the cloud-intensive ecosystem and everyone is talking about it. We now even have the Github's working group and also a conference centered around Github itself. Now, one thing we do very much as a community from the beginning is get caught up in the buzzwords and all the discussions around how cool the technology is without really spending much time into all the different use cases that are possible and some of the caveat, especially for some regulated industries. I'll be talking about a few of those in this webinar. First, in a bit about myself, I'm a developer of Angelizine Program Manager at Github. Yeah, that's a long time to go. Basically, I do program management for the developer team at Github, the developer of Angelizine theme at Github. Now, based in the Hague Netherlands and my interest are in communities, Github's, DevSecOps and CICD. You can always find me on Twitter at Cirque 247. But first, what is Github's basically? Now, according to the Github's working group, it's simply a set of principles around how the whole systems we use for our infrastructure is managed. And these principles that have been stated by the Github's working group are declarative desired state, version of immutable state, continuous reconciliation by pulling automatically, and also operations through reconciliation. But the key things I want us to take from all these principles is definitely you need to declare how infrastructure should look like. We already have infrastructure as code where you can use tools like Terraform or any other to our communities if you're using HALM to describe, okay, this is how I want my communities cluster to be. This is the number of nodes. This is the number of pods. This is how applications should be scaled and so on. Now, the same thing with almost any type of infrastructure as code strategy that you have. Everything needs to be declared. Everything needs to be documented. In such a way that everyone looking at it understands what needs to be achieved, what kind of resources need to be deployed. But versioning it using tools that we are all familiar with like Git ensures that you maintain a safe document in history of how your infrastructure has been changing or how your cluster has been changing. And makes sure that the deployed state is always exactly as what you have in your Git repository. So that things don't just drift and there will now be some conflict in the future. Now, and we are able to achieve this by ensuring that there is some form of mechanism that automatically checks between the desired state which is stored in your repository. And the actual state that is running in production so that if there's any drift or there's any issues or there's any conflict between these two states, it automatically pulls from the desired state that is stored in Git, or that has been declared to a registry and it conserves both of them. So this way you are able to securely ensure that your infrastructure, your systems, your application are always up to date running the latest code and everything works as they should. What's the difference between DevOps and GitOps? What exactly is the difference? DevOps is a culture. It's how you do things and how you ensure that your application moves from development to production and back. Once it gets to production, you need to be track it, you need to do your tracing and go back and recommendations go back to the development team to maintain the cycle. Number four, GitOps mainly focused on ensuring that your infrastructure is deployed and is maintained as you require and the way your application moves to your production environment is also maintained efficiently. That is the goal of GitOps. You've written how your application should be and how your infrastructure should look like and how your application should be deployed to that infrastructure. Then all the process of testing, of version control, building images and so on down to deploying them mostly to Kubernetes cluster is what GitOps is about. Now also someone would ask what's basically the difference between GitOps and infrastructure as code because it feels like it's just some new way of doing infrastructure as code. You might say that, but the difference here is let's put it this way. GitOps is like when infrastructure as code meets much request or pull request. That means people can collaborate, literally make changes to your application, probably your developers discovered they need more resources to run certain applications or they need to request for more server resources. They create a pull request or imagine request and CICD runs all your necessary policy checks and all your testing against the submissions they've made before the application gets deployed. Now, the difference here is between GitOps and infrastructure as code, of course you can use version control for your existing infrastructure as code. But GitOps takes it for that in the sense that infrastructure as code requires you to have declared the way your infrastructure will look like. Then push it to the Kubernetes cluster or your infrastructure for it to be deployed and for new changes to be deployed. Now, before GitOps, the infrastructure as code that you've created, once it has been accepted by your policies and push to probably a production branch or some branch system that you have or your workflow you have, or probably to some image repository somewhere, you have your on your Kubernetes cluster infrastructure, you have an agent that will constantly be pulling and be checking that production branch that you've specified for where your disaster to be to constantly see if there are new changes it pulls them or to be checking an image repository where the image of your application has been stored and anytime there's a new change it pulls it and applies them to your infrastructure. And it also ensures regularly automatically to check which is where operations via continuous reconciliation comes in to check the desired state against the actual state. Are there changes, have things improved or are there new updates or is there an issue that's happened on the cluster that's making, that has now made the two environments to be different. Then it will automatically reconcile, pull the most recent or the most updated code from your repository or your production branch and apply them. For infrastructure as code, new change has to be introduced before it is pushed to production. Now one way get us those days is by using what we call a pull strategy. For normal infrastructure as code, a push strategy happens where once you've written make changes to your infrastructure as code manifest, you need to push it to your Kubernetes cluster infrastructure for it to be deployed. Now, in the pull strategy, the agent, there's an agent in your Kubernetes cluster that will constantly look out for new changes and pull those changes to your cluster to be applied to your cluster. Now, one advantage of this is your secrets and some other critical things that are necessary for your cluster to run are stored on the cluster. You don't need to find a way to store your secret or to store some credentials on your repository for things to work, but for infrastructure as code, you will need to have configured your repository or your project to have the necessary credentials to deploy to your cluster. While for pull strategy, the agent is already living in the same cluster as where your applications will be deployed, so it only needs to communicate with the repository to confirm if there are new changes and pulls them. Now, let's see a picture representation of what a pull to premise will look like. This image was taken from the github.tech website. Now, we see here that you have your code or your application repository. When changes are done, it triggers a pipeline and that pipeline runs all the necessary jobs or all the necessary things that you've already done, jobs that you need to confirm if everything is okay or to build images. Then it pushes the images to your image repository, the cry registry or github.tech image registry and also maintains updates to your environmental repository. While in your environment, which most often is your Kubernetes cluster, the agent you have in this case, which in the case of this image you're calling an operator will constantly check your image registry or your environmental repository to confirm. Are there new changes? Are there new updates? If there are, it then pulls those changes and applies them. Now, it also observes your deployment, but as you can see in the image to see what are the new, has there been any change or any drift or any issues happening on your deployment? If there are, it reconciles them and makes sure that the actual state is the same as the desired state. So basically github allows for collaboration because your development team used tools that they are already familiar with, github to write codes. Almost everyone can see what has been written. People can apply for more resources or can make changes to resources. The top level management can be able to review changes that are happening and they can be able to approve or make recommendations to requested changes. And the SREs or infrastructure engineers who have access to actually let this team get deployed can also see all the things that have been done and approve before it goes forward. Now, this also allows everyone to be knowledgeable about what infrastructure looks like, how things have been deployed and be able to contribute new knowledge to the rest of the team. Now, one key advantage, another key advantage of using github as defined by the github's working group is your secrets are now secure because you don't need to maintain your secrets in different places like, okay, you need to set up. For example, if you're using github, you need to set up some secrets or you need to integrate github with your community cluster or you need to do a lot of things to make sure your project or your repository can communicate your github project, can communicate with the cluster to make any deployments necessary. But in the case of github, if you are using a Kubernetes agent, you only need to put your secrets in the repository, sorry, in your Kubernetes cluster. So all the only communication, the only credentials that needs to be configured with github is whatever credential is necessary for the Kubernetes agent or operator to pull or communicate with your project to see for changes that have happened and deploy them. Now, lastly, because there is new, because you already have a mechanism that pulls for changes, it's easier for developments to move fast and deployments to happen at almost any time because constantly you don't necessarily need to go and trigger deployments to production. There's an agent that constantly pulls and sees what new changes are there to be deployed. Now, after we've seen, now that we've seen what github is and why use github, the next thing is what exactly can you use github for, which is the main part of this presentation. The use cases. The first and the most obvious one is definitely infrastructure optimization. Now, you have your Kubernetes cluster. How do you maintain it? How do you manage it? Kubernetes has been created in such a way that you can easily create a declarative state of what your Kubernetes cluster should look like, what your deployment on Kubernetes should look like. You can create your Kubernetes manifest file to define the number of parts you want to deploy, how you want your applications to communicate to the services, your storage classes, your persistent volumes, etc. You can define them in a manifest and you can even use things like Helm to define, to use a more descriptive language to define how your application should look like, or use HelmChats to define, okay, this is a values.yaml5 isn't HelmChats. To now say, okay, these are the things I need for my HelmChats and to automatically deploy it. Now, also, this makes it easier since we already have these tools to ensure to deploy applications to our Kubernetes cluster, to now use github to fashion control easily. And once we do that, our cluster stays up to date. Even if you are not using Kubernetes, if you have some form of other infrastructure, because definitely not everyone uses Kubernetes, you can use the same principles of github to make sure you have a declarative state of your whole infrastructure. You have a mechanism in which your application is pulled securely, the manifest are pulled into your environment and deployed in your environment. And also, you ensure that there's reconciliation between what is running your infrastructure and what you've defined. Now, the next thing is drift management. This is a major issue when it comes to maintaining your infrastructure. Yeah, you have your Kubernetes cluster. In certain situations, there are people that decide to deploy some changes to your cluster and decide why you have a versioned git repository hosting probably your manifest. It can be a huge mess when sometimes you need to deploy things and there are some conflicts in how applications or the cluster has been deployed, applications have been deployed to the cluster. With github, you can ensure that there are no drifts. At any time there are drifts, it should automatically be consigned. Because you've already defined how your cluster should look like and how your application should be deployed to your cluster, the Kubernetes agent you have or operator you have in your cluster will ensure that the two, the disaster state and the actual state are the same. This is where you avoid drift management completely. Now, policy enforcement. One of the concerns a lot of people will will come up with, especially in regulated environments. Okay, if we are making changes to our airport and people are collaboratively working on the airport, how do we ensure things don't escalate unnecessarily or things don't get applied and create problems or probably take down infrastructure. Now, you need to, since github itself iset of policies, it not depends on what tools you use to ensure that for every change that I've made, the necessary checks are done, the necessary security scanning are done, the necessary, everything necessary is done and there are levels of approval. Okay, you might have code owners set within your project where anytime certain changes are made to certain parts of the git repository that is maintaining your infrastructure application, certain people must approve or certain people will be notified to review and approve. And mostly because when you use a magic quest, you create a magic quest or pull request you create a magic quest. As soon as you submit your magic quest, there are certain people that will be notified to approve maybe quality assurance. They are probably audits, probably trying to spin up more instances that might cost the company a lot of money. And as soon as you review and ensure that, okay, we are not going beyond or we are not using dependencies that might cost the company. And as soon as that's done, at the last stage, might be the SREs who do the final, okay, let's merge this and as soon as it's merged to your production branch or infra branch, or it's compiled as an image and hosted in your repository. Everything is done. It's now left for the Kubernetes agent to pull those new strategies out of it. And enforcing this policy, this policy means that anything that gets to that final stage of either hitting, getting merged into the production branch or being built as an image and kept in the image or position has been satisfied to be okay and ready for production. Now, security scanning is nothing is 100% secure and part of your ensuring that you attain a very secure tooling for all of your infrastructure is ensuring that all the necessary security tools or security tools are security checks that need to be done. For example, maybe a security detection so that none of your application is actually in the Kubernetes circuit and show a static application testing, the dynamic security testing, license compliance. Sometimes we add license, people might mistakenly add licenses. That add dependencies that have licenses that your organization don't support, or in certain scenarios, there are certain dependencies that probably these security reasons or due to some other regulatory requirements, you are not supposed to use them. And your developers missed it or they used a dependency that for one reason or another includes some of those security challenges, some of the things that have the security challenges that you are trying to fight against. So all the security checks ensures that nothing gets passed to your production branch without you detecting. And this and having a security dashboard ensures this happened because it gives your quality assurance of security team. An interface where they can monitor how how many security challenges or security vulnerabilities are happening without having to necessarily even touch the code. And they will have been able to see, okay, this is these are the things that happen or if they need to improve the scanning or add more scanning tools or more things will majorly to ensure that whatever gets to your production branch has been fully tested and reliable. And the next thing is governance and compliance. Now this is especially for environment like in FinTech or banking industry where there's a lot of regulation. And we all know that yeah in the startup world or not but it's easy to it's easy to jump on it later starting new things. Yeah, we are in, yeah, we are in, yeah, we are in, yeah, we are in when regulated environments like banking, we have a lot of regulation. There needs to be cautious approach to adopting anything. So that is where ensuring that yes adequate governance that is happening within an organization. Okay, now if we are using GitOps, do we have auditory? Where are audits maintained? Where do we track changes that have been introduced? And since we are using Git as the main version of control for for GitOps, it's easy to have a history, a version of history of how an infrastructure has changed, who introduced what, when was introduced, and so on. And when in your continuous integration pipeline, you also have tools that are ensuring there are no issues in your supply chain. You are using the right dependencies that you're supposed to use. You are following some certain compliance to ensure you are using the right licenses. You are using the right, every necessary checks and every requirement that are needed are done. Down to you having your changes pushed production. This is important because in a related environment, every trace of activity happening is extremely important and is needed. Now, within your cluster, ensuring that there is no way in which a compromise can happen or secrets can be leaked, is extremely important. That is where GitOps shines because most times your secrets live in the Kubernetes cluster. So you have little or no need at all to add your secrets or to expose your secrets within your project. So governance and compliance is a huge way in which you can use GitOps to ensure that your applications are securely deployed and your infrastructure is securely maintained and operated. Now, the next thing is, yeah, not everyone is using Kubernetes and not everyone is using the latest shiny things around the cloud native ecosystem, but it comes to use the principles of GitOps. Now, because basically what is GitOps, it's basically you having a declarative state of infrastructure, you ensuring that your manifest or your declarative state is pulled continuously to your cluster and also ensuring that the two states of your cluster, the desired and actual state are continuously maintained and operated. So now, these can apply to anything outside of Kubernetes. As long as you can use things like Terraform to define how your application will look like, also have something like Ansible to define how your configuration would be. Then you can have some form of maybe CI mechanism to ensure that continuously, maybe after some interval, some CI jobs or some script runs to pull, to check your production branch or whichever branch you are using and computes your infrastructure to check if there's any drift as having changes in your deployed states, has there been new updates that have been introduced, then it applies to them. Now, the main thing is about the principles using and living by the principles are not necessarily the specific tooling. Though GitOps has been built around Kubernetes itself, but we use quite a lot of things in our infrastructure, in our environments, and following these principles is what is most important. Now, this is the end of my talk and I hope we've learned quite a number of things around the use cases of GitOps. If you want to learn more about GitOps and other things around it, these are a few links, especially GitOps. That's where, if you are new completely to GitOps, you can learn more information about it. You can also check the open GitOps working group GitHub page. That's where you can see more documents around the principles of GitOps and some of the awesome work that they've done on GitOps. GitLab also has a number of resources that you can use to learn more about the different use cases of GitOps. Thank you very much for joining me and see you online.