 Hello, and welcome to this GitOps working group update. If you don't know what the GitOps working group is, don't worry, by the end of this session you will. My name is Cornelia Davis. I'm the CTO at Weaverx, and I'm joined by my colleague. Hi, I'm Chris Sanders, and I'm a program manager working on Azure Arc. Excellent. And Chris and I have been working together on both the formation of the GitOps working group and the GitOps working group itself. So we'll tell you more about that. So, before we jump into the details of the GitOps working group, I thought it would be a good idea for us to just talk about what is GitOps. And with that, for those of you who know me, I'm always drawing animations. So what I want to talk about here is you can imagine with a word like GitOps, there's an operational element. So what we're talking about here is we're talking about operating something in some runtime environment. So that's what I've depicted here on the slide as Kubernetes. Now you'll notice there, there's the remark that said Kubernetes is just one example of a runtime environment. GitOps is not restricted to only Kubernetes. You can GitOps things that are in your infrastructure, so you could be doing a variety of different infrastructure things on Azure, for example, or you could be doing GitOpsing from your LDAP system or something like that. There could be a number of different runtime environments. But we're using Kubernetes here just as an exemplar. Now the next element is that we've got a number of individuals who are operating that runtime environment. They're operating the infrastructure, the applications running on that, the roles and the roles, role-based access control, all of those types of things. And what we're talking about with GitOps gets to how do they do that? How do they operate those things in the runtime environment? And as you can imagine, because there's some white space there, there's something coming. Well, this is where the Git part comes in. Now, Git is not the only thing that you use for this part of the equation, but it is the most prevalent thing that we do in GitOps. And what we're doing there is with GitOps, those individuals who are responsible for running those applications and running the infrastructure in that runtime environment, they do so by recording the desired state of that infrastructure in a system like Git. And we'll talk a little bit more about what the characteristics are of that system like Git. And they're using an interface to that system, to that Git system, has the interface for operations. It's not that they're doing operations elsewhere and then coming back to Git to record things. It's that they are using that interface into Git, has the interface for operations. So that is really, really critical. Now, when they do commit things into Git, using PRs or whatever the case may be and then approvals, there is some automation that has to happen to make that so in the runtime environment. And the second really important element of GitOps is that that automation needs to be special. It needs to be convergent. And now you can see why it started with Kubernetes, because Kubernetes is by its very nature a convergent system. So we're kind of capitalizing on that. So GitOps is using an interface into a version of the mutable store like Git and then using convergent automation to make it so in the runtime environment. Now there's one final element which is these days modern operations is all about feedback loops. If there is any reason that something has changed in the runtime environment, we also want to automate that loop back in to the versioned mutable store that has the desired state. So if we had to do some kind of pick fix in the runtime environment, we want to automate that feedback back into the Git repository as well. So that's kind of a quick overview of GitOps. With that, I'd like to hand it over to my colleague Chris to tell you more about the GitOps working group, history, what we're doing and those types of things. So Chris, take it away. I'll flip slides for you. Cool. Thanks, Cornelia. So yeah, Cornelia, you give you a nice quick overview to what GitOps is and some of the importance of it and she's going to talk some more about it later on too. But what I'd like to talk about now is the GitOps working group. This working group was formed last November and it was announced. There was several companies who are initiators here including Codefresh and Amazon and GitHub and Weaveworks and Microsoft who initiated this working group. But as you'll find out, this is a working group that is open to all. The goal of this working group is to provide companies and individuals, you folks who are watching, with the knowledge, the skills, and the competency to be able to implement GitOps using tooling and methodologies with simplify your operation and management of the infrastructure and cloud native applications. So you can see here that one of the core reasons for the working group is to help educate you, educate companies, educate individuals on the principles of GitOps, how do you effectively use GitOps and also if you're making tooling or you're using tooling, how to create a GitOps ecosystem where interoperability is a given. Next. Yep, and I'll just really quickly before I advance the slide, re-emphasize two words on the screen here. I already said it, Chris is going to say it repeatedly, which is GitOps doesn't just apply to infrastructure, it doesn't just apply to applications, it applies to everything. Anything that you need to operate in a runtime environment, you can apply GitOps to. Cool, so where does this new working group live? Well, an obvious place for it to live is the cloud native computing foundation. And that foundation has a mission to make cloud native computing ubiquitous. So this is where the working group lives. And in the next slide, you'll see the next step down of where it lives, which is in the app delivery special interest group within the CNCF. The application delivery SIG focuses on delivering cloud native applications, which involve multiple phases, including building, deploying, managing and operating. So a GitOps working group really fits well into this special interest group. Next. So you can see this great icon we have for the GitOps working group. And the focus of the GitOps working group is again to clearly define a vendor neutral and principle-led meaning of GitOps, so that it's a very open type of process that we're using, open tooling system. And the GitOps working group will help them define and establish a foundation for the interoperability again between tooling from various vendors, conformance of systems with GitOps, and also certification of practitioners of GitOps as well. We've met several times over the past several months. And out of that, several co-chairs were elected, the initial co-chairs, and they include Dan Garfield of CodeFresh, Leo Murillo of Cloud Native Architects, and Scott Rigby of WeaveWorks. So what is this working group doing right now? Well, so far, as you're going to see, as you're watching this on Thursday of KubeCon, in the zero day, there was a GitOps con that some of you may have gone to, an all-day event where we focused on GitOps. A second area is that we're really working hard right now to establish the principles of GitOps and to make a statement there. Folks are reviewing the initial statement of principles. We're having discussions on that, and you're welcome to join into the discussion as well as we come up with a sort of a living document of what GitOps principles are, hopefully to define and set the baseline for understanding GitOps. Eventually, there will be a very rich website that will include things like samples. And you can see an example here of Podtato Head for cloud-native application delivery in various forms. The goal here is to have a site where you can go and you can see various reference implementations of how you would do GitOps in various situations. So it's a very pluggable, playable system. In the future, we're going to be looking at things like GitOps landscape, and I'm going to let you talk about this Cornelia because you stuck this in here and I don't know exactly what you mean, and also certifications for GitOps, but go ahead. Yes, so what we have in mind with the GitOps landscape is that there are several elements, even in the intro that I gave at the beginning of the presentation, you saw that there were several elements. There were elements around this versioned immutable store that I was talking about. There's also this element around automation and this element around targets. And then there's even within the automation category, there's a number of different ways that you might categorize its automation that is specifically for infrastructure, specifically for Kubernetes. And so if you think about operation, cloud native operations, you really can think of GitOps as cloud native operations. So when we talk about a GitOps landscape, we're talking about, well, there's so many things that are involved in cloud native operations. How do we start to break that down and categorize it so that we can then take things like tools and put them in categories? So if you think of the CMCF landscape as this really broad landscape, now you can think of something like cloud native operations as a smaller landscape, but within that there's still some complexity. So it kind of introduces a taxonomy. Okay, next. So out of the cloud native working group, there's going out of the GitOps working group, there's going to come some permanent artifacts that are going to be things like programs and documents and code that are going to live for you to access. And so in order to help find a place for those to live, we've created the open GitOps project within CMCF. It's currently a CMCF sandbox project. And this will be a place where the artifacts will be stored. Next. So in summary, we have the GitOps working group. And you'll hear a call for action soon that you all should join up for this. And that GitOps working group, out of the discussions that happened there, it will create and care for this open GitOps project. And I think it's back to you. Excellent. All right. Super. Thank you. And so one of the things, the very first thing we talked about it, we referred to it as GitOps principles or GitOps definition. The principles are actually only part of the definition. It's in a PR. And so when Chris was mentioning that, we invite you to participate with us on the definition of what GitOps is and the expression of these principles. And I'm going to go over those principles in just a moment. Right now, those exist in the PR. So I'll come back to that slide at the end that shows you the Git repository where the GitOps working group is doing its work. And right now, there's a PR against that repository that captures that GitOps definition. We're capturing it in three different places. One, there's a glossary. And that glossary talks about things like the desired state, the state store reconciliation. So those are terms that you already heard us use throughout this presentation. We also have a document that talks about the rationale. So what is good at GitOps good for? You hear us sometimes talking about, well, it's great for auditability. So those are the types of things that we're expressing in the rationale. And then the most significant piece in that definition is the principles are the principles themselves. And so today, as we record this, just a couple of weeks before KubeCon and right around the time that KubeCon runs, these principles, I think, are going to be pretty stable in that time. But they are still under development. So let me present to you what the principles are looking like right now in the discussion in that GitOps working group. It starts out with principle number one. And principle number one says that we, it's the principle of declarative state. So this, if you will, for those of you who are familiar with Kubernetes, oh, it's funny that I should say that, right? This is KubeCon, most of you probably are. Is that the way that you configure your Kubernetes systems? You configure it not through a bunch of REST APIs and imperative calls, but you configure it by expressing what you want in a YAML document. So that desired state is expressed declaratively. So that's principle number one. Principle number two is that that desired state that's declaratively expressed is stored in a way that supports versioning immutable, immutability of those versions, and retains that version history. So I hinted earlier that it didn't have to be Git, but there are certain semantics that we depend on for GitOps. So for example, that last part that says retains a complete version history, well, it's that version history that enables you to have an audit trail of who did what and what changes happened in your runtime environment based on what actions happened and were captured in the Git system. Immutability, that's really important because one of the benefits of GitOps that we talk about is that you can roll back, that you can easily recover the state of a system. Either you have moved forward a version and some unanticipated problems showed it's reared its ugly head way too late. Now we need to pull back, we want to roll back to the previous version or I've had some kind of a disaster and I need to quickly stand up my system in a different region, for example. Being able to do that, we have to have that immutability and that complete version history. So you can see that these principles are very specifically crafted to support some of these benefits that we realize from GitOps. Principle number three gets to that automation piece that I showed you in the earlier slide which it says, well when you have stored this desired state, which you've expressed declaratively and you've stored it appropriately in the right kind of store and there's going to be software agents that respond to that. Now you could imagine that we're just sending out web hooks and running some bash script somewhere. That's not GitOps. What we are saying here is in order to take advantage of that declarative state, we're saying that the automation has to be that convergent system, that reconciliation-based system that I talked about earlier. So those are those software agents. Now I've put a couple of icons up here to show you that those software agents fall into a couple of different categories. You see, for example, there's a Flux logo, that's the far left one and then there's the Argo CD logo which is a little octopus there. Those are both reconcilers that deal with delivering things from the Git repository over into the Kubernetes environment. Those are all reconciliation-based. Then Kubernetes itself has all sorts of reconcilers like your deployment controller and your replica set controller and then the little stacked turtle there if you're not familiar with those, that's the logo for cluster API. So cluster API is a reconciliation-based way of managing your Kubernetes clusters themselves. So that means you can declare your desired cluster state, not workload, but cluster state and you can have something like Flux or Argo deliver that and then you've got these reconcilers that will make it so and stand up and take care of the Kubernetes clusters that you want. So that's principle number three is this special nature of these software agents. And then finally, principle four says this is the only way that you're going to operate your system. You are not going to go in through the back door. Now, there are of course exceptions. You sometimes are going to have to go through the back door and you saw the feedback loop that said, well, if you go in through the back door, if you essentially SSH and do a kubectl apply, that will record that back into the Git system. But the normal mode of operation is for operations to happen via these mechanisms and then the software agents make it so. So those are the four principles that you can find currently in that pull request. If you want to participate in that, we very, very much welcome your opinions and your feedback in that pull request. So please come there. And so really the whole point here is that it's really about this convergent system and there's continuous delivery and continuous operations. So we sometimes like to say GitOps does not equal CD. It equals CD plus CO. So that's what this picture is showing. So finally, I want to reiterate Chris's invitation from earlier. Please join us. I've mentioned that the GitOps principles is a PR there. The repository, I've put it there in a larger font as well. So the repo there is in GitHub. It's gitOps-working-group. And that's the organization. And then we've got a number of repositories under there. The kind of home for the working group is there. We also meet synchronously the second Thursday of every month at 1,800 hours GMT. That occasionally moves. So keep an eye on the CNCF calendar when it does move because of holidays or those types of things. We do update the CNCF calendar. You can find all of the details. Really the only URL that you need to remember is that GitOps-working-group. And you can find everything else there. It'll take you to documents and press releases and all of that kind of stuff. So with that, Chris and I thank you for your attention. We hope that you enjoy the rest of your KubeCon. And we hope to see you soon in the GitOps-working-group. Thanks so much.