- [Jeremy] Okay, welcome back! GitOps is a term first coined by the team at WeaveWorks who formalized several of their own daily patterns and processes that they were using successfully to empower high velocity cloud native application deployments into their own Kubernetes clusters. Therefore GitOps, from day one, had Kubernetes in mind but that's not to say GitOps only works with Kubernetes. GitOps indeed can be equally applicable in other environments and with other technologies. Having said that, for the remainder of this course, I'll explain and review GitOps in the context of working with Kubernetes. 

By the way Kubernetes, for those unfamiliar with, is an open-source container-orchestration system considered now by many as the de facto go to platform for hosting cloud native containerized applications. One of its most important qualities is its ability to converge on a described running state declared and stored often in file form. You, as a developer, simply codify your desired state into manifest files. These files are then sent to the cluster. The cluster is then responsible for converging on the desired state. Okay, keep this quick explanation in mind as I now return to the GitOps story. 

As the name suggests, GitOps puts Git at the very center of your developer and operational workflows. Since your desired Kubernetes cluster state can be and should be described declaratively, then by storing all of this within Git, Git becomes the system of truth for the Kubernetes cluster for any point in time. GitOps has its roots in DevOps, Infrastructure as code, Configuration Management, and Site Reliability Engineer, and builds upon the successes of each process, pattern, or practice. With Git being at the center of the GitOps workflow it empowers two important capabilities. 

Firstly, the developer experience is enhanced. Developers can now create, edit, and upload their required cluster resources in the form of manifest files into Git. When they do so, a typical and standard Continuous Integration Cycle is triggered performing tasks such as linting and/or perhaps other security related tests, etcetera. If everything passes, the code can then be merged into master. 

Now at this stage the cluster can be configured to pull in and redeploy these changes automatically. Therefore, the only access the developer ever needed to get his or her application into the cluster was write access into the Git repo. This experience is familiar to the developer, they already know how to use Git and they don't need to learn the intricacies of kubectl for deployments. Secondly, Kubernetes can be configured to periodically look inward into Git and have the cluster continually converge on the declared state held within Git. Any detected divergence or configuration drift can be addressed and repaired. Sounds great but how does this actually work? When it comes to GitOps and Kubernetes, GitOps utilizes an operator which is deployed into the cluster itself. In the Kubernetes world and way of things, an operator is simply a component that takes on the role of automating something that a human administrator would potentially perform manually within the cluster. In this case, the operator in question is the Flux Operator which was built and open sourced by the team at WeaveWorks. 

The Flux Operator is configured to periodically poll a particular Git repository, your system of truth, where all of your declared cluster state lives looking for any applied changes. Flux then ensures that the cluster state is synchronized back with the currently declared state held within the Git repository. So now that we know the basics of the GitOps workflow, what are it's real and tangible benefits? Let's cover these off now. Enhanced developer productivity. With GitOps, developers only need access to Git. If a developer knows how to use Git, then he or she can indirectly start deploying new features to Kubernetes. 

This saves time and keeps developers focused on implementing new business features and not being distracted by having to manage Kubernetes clusters. Enhanced operations. Less hands-on from operations since the cluster through the Flux Operator can self manage and self heal maintaining and synchronizing state with what's stored in the system of truth, Git. Better security all around. Since the Flux Operator is deployed inside the cluster there is no longer any need to manage and maintain a set of credentials externally to the cluster itself. Thinking of the alternative, a CICD system that pushes changes into the cluster would require some form of cluster credential. 

Managing this credential outside of the cluster requires care and concern for its protection. Better compliance and auditing capabilities. Since all of the cluster state is declared and stored within Git, then its very simple to audit and report on the known cluster state. Additionally, Git commits can be cryptographically signed ensuring that you can irrefutably prove who authored the code in question. Faster restoration. In the rare event of a cluster failure you can confidently restore or rebuild your cluster to a known state very quickly. Simplified rollbacks. Rolling back to a previous version of the cluster state is both simple and quick since all cluster state has been versioned and stored within Git. 

Okay, that concludes this lecture. Go ahead and close it and we'll see you shortly in the next one where we examine simple GitOps workflow architectures.