 But I think one of the things that was really important too is we've gone through the history, what's going on in the community right now. We've heard from an end user using it in production and gotten on board with the path. But what is next in GitOps? And we do a lot of work at Red Hat out in the open and stuff, but there's a bunch of stuff going on too internally. So I thought we'd round out today with a talk by CMAC and let him talk a little bit about how we're making it happen here at OpenShift in the Red Hat world. So CMAC, introduce yourself and let it rip here. Sure thing. Thanks, Leon. Just checking first, does everyone hear me? Am I audible? You're really great. Thanks. I've seen myself at Campfire, I've been in Red Hat for quite a long time, beyond 10 years. And I'm part of the product management team at Red Hat within the OpenShift and Hybrid Cloud Group. And I want to talk to you about a little bit more of what's next within the GitOps space and on OpenShift as a platform specifically. And before that, I want to cover a little bit of why GitOps in general. I know that you heard about this a little bit from Christian and Cornelia as well. But I want to look at it from a different perspective that we see as a recurring pattern with a lot of our customers. And talk a little bit also about why specifically now, why is now a GitOps common co-located event and common decision today. And there are many, many conferences and events are happening around GitOps. What's the significance of time here? And then focus more on what's next, what area we'll be pursuing and what we see happening in the community. So let's start with why GitOps. And Cornelia laid out really well stories of how GitOps is born out of the DevOps movement and the values and principles of there. And I'm not going to get too much into that conversation. What I want to point out is that adopting GitOps is difficult and challenging. A lot of organizations are on a journey to adopt GitOps. Like the numbers that you hear from analysts are around 60%, 70% of organization and the interview are on that journey. However, one aspect of that difficulty comes from obviously the cultural perspective and dealing with people and shift the mindset. The other aspect which is expected to be more straightforward, but in practice has proven to be quite challenging is to make sense of all of the principles and practices that exist in DevOps. What happens is that most teams, most organizations start with continuous integration which is kind of a low hanging fruit to automate and building the application and releasing applications, some of the aspect of building and delivering application. And from that point on, it becomes quite difficult to navigate this space and figure out what should be done next, where else they need to go. And this is an area that we see some of the teams, a lot of the teams start to stagnate. They couldn't get stuck beyond that. It's not clear how to proceed from there. An observation of the situation is also when you look at 100 different teams adopting DevOps practices, even though the practices are the same, the values are the same, you probably see about 100 different ways that DevOps is implemented. So that brings a lot of flexibility to the teams to find their own path, but also puts a lot of responsibility on those teams to find their own path. A lot of teams are much more, they would have much more success if there's a prescription to start with and find their path beyond that point when maturity increases. So that's one aspect of DevOps that has been challenging for a lot of the practitioners. And another aspect is that we see a shift of focus from continuous integration to continuous delivery. So like I mentioned, CI is what a lot of teams start with as the first step of the DevOps journey and go hanging through. But as that is tackled in that spectrum of continuous delivery that we defined with all the stages that involve from a change going all the way to the production, whatever production means for that change or application, a shift of focus is happening to the darker blue side of the spectrum on deployment really. How do I actually deliver these things that I have built to those environments with simpler advanced scenarios? And as a consequence of that, there is a change also on how people speak about these concepts within DevOps space. CD is really referring to that entirety of the process, regardless of human continuous, delivery or continuous deployment. In practice, a lot more over the last year, we see CDs used very often to refer just to that deployment to the actual delivery of the things, of the software, not to that entire different processes. As a consequence of this, a lot of the solutions out there, a lot of projects within the open source or commercial solutions coming out when you hear CD, they often mean that that last model that Cornelia was also talking about, they don't mean that they are an entirety of the platform that cover every stages that are involved in application delivery. So with that in mind, with difficulties of navigating the DevOps space because of the high level of abstraction that DevOps talks about, these principles and values and the shift that is happening among the practitioners that are looking more how to address the deployment part and delivery part of this application delivery process and workflows, that has sparked the interest of many teams, many organizations to look for a solution or something that gives them a lot more prescription than DevOps as a movement has provided. And that really brings up a lot of these teams to land on GitOps as a practice. We have already defined what GitOps is. I'm not going to get too much into that, but it is truly a blueprint, a concrete way of proceeding with DevOps adoption, with implementing some of the practices that are already familiar for many organizations, really build on the infrastructure as code principle and having version control for all the artifacts and conflicts and everything that is involved in application delivery. So a lot of those aspects are known. They're just not put together in this particular composition that GitOps is proposing. And the value, the advantage of people and the benefit that are immediately getting from reaching to looking into the GitOps workflow is that in those 100 teams that I talked about, if they adopt GitOps workflow, all 100s of them are essentially, the workflow looks pretty similar to each other, as Dan also walked us through the open GitOps initiative and the principles that are coming as it are extremely prescriptive in the way that you need to proceed and how you should organize your application delivery to adhere to the GitOps principles and be able to get the benefits that GitOps provides. So we see GitOps as really one particular blueprint of how DevOps implementation, specifically from the process and technology perspective looks like. It doesn't do much, unfortunately, for the cultural aspect. It is a change of mindset, but those challenges of DevOps still remain. So that's really how a lot of organizations have landed on GitOps and looking for really how to get out of that stagnation that they have experienced within DevOps. But it's a valid question that why all of this is happening now. Why am I talking about GitOps to you today and all these events are happening this year? Because if you think about it, GitOps is, even as the phrasing of GitOps is nothing new, V-Work takes all the credit, obviously, for coning the war and making and evangelizing the concept of GitOps and the Git workflow around it. However, this happened about five years ago. So what is the deal that you're hearing about this now? And we haven't had so many things happening around GitOps since then. It's only the last 12 months, really, that we see a huge update and huge interest from the community and the customer base and teams around the GitOps workflow. So where that comes from, Cornelia talked about this a little bit. Containers had to do a lot of it. And more than that, it's really Kubernetes that has changed the type of infrastructure that teams and organizations deal with. And a lot of that is attributed to Kubernetes, but from a certain and particular aspect. So if you look at the latest stats that are coming out, what you're seeing on the slide is coming from the CNCS survey that was conducted 2020. So it's already quite old and stale, but it does make a point that they want to highlight here is that 83% of organizations that were surveyed at that point were running Kubernetes in production. The number that had Kubernetes in house was close to 93% or 95% if I recall correctly. These are the ones that are running it in production. And this number, more than 50%, around 50% had more than five clusters. So what they recognize in that survey about two years ago is that the number of teams, organizations that are running two to five clusters in house is decreasing year over year. And number that are running above six clusters and 10 clusters and 50 clusters, that's increasing. And what does that have to do with anything? Why is that correlated to get up? So the reason for that is really the more clusters customers are dealing with teams or organizations are dealing with, there is more complexity in doing pretty much anything that has to do with operations. The operations of the platforms becomes more difficult Kubernetes itself. If you're dealing with 50 clusters, you're an IT ops team or platform ops team dealing with 100 clusters, how do you make sure that the network policies across all these clusters are consistent or authentication configuration is consistent or a lot of other aspects of the cluster itself? If you are an SRA engineer, DevOps engineer or application developer delivering an application to a subset of those clusters, 20 of those clusters because your application is distributed geographically, how do you guarantee that the configurations are in seeing the deployments and are done in a predictable manner and guarantee the deployment succeeds? So if you compare this to that traditional way of CI that I mentioned as a low hanging fruit, people put that in their CI, you have a look in that CI deployed to 20 clusters, then something goes wrong and you're left on your own. The CI is not really doing anything for you when something is failing after a successful deployment. So with increasing the number of clusters, there are a lot of complexity that comes with running a lot of operation. There are a lot of simplicity coming along the way as well because managing smaller clusters are much easier than managing larger clusters. So there is a reason that organizations are going toward adopting and having a large number of clusters. One aspect that it has to do with the maturity of Kubernetes adoption organizations that are adopting Kubernetes. So they're spreading within the organization more and more teams are on more than this platform, more and more applications are on more than Kubernetes platforms. On the other hand, it's easier for them to, if you want to, for example, upgrade the nodes of Kubernetes is much easier if that cluster has 10 nodes instead of 200 nodes. So there are benefits of having large number of small clusters, but there are complexities that get increased in how you manage those clusters from a configuration perspective and how you deliver applications to it. So that's something that we see as one of the really main drivers that is pushing a lot of interest toward GitOps as a workflow, especially to start with as a workflow for managing cluster configuration itself. And after that for deployment of application, application delivery. So this is actually something that perhaps sometimes comes as counter-intuitive because GitOps, because piggybacking on Git workflows, and that's something that is really absorbed and internalized within the application teams. Dev teams sometimes are perceived as something that is only limited to applications and delivering applications. What we are seeing in reality is that most organizations are first and primarily interested in it as a means of configuration management of clusters and delivering changes to those clusters, then applications and workflows being only one of the aspects of what they are managing on those clusters. So that's really what we attribute the huge growth of interest in GitOps. And both in the community, more projects coming along, more people getting involved in the existing projects are the CDM flocks as the main GitOps-related projects in CNCF are mentioned. A lot of contributions and interests are coming toward these projects because of this only like recently and a lot of interest and inquiries we get at Red Hat, and I know that within the community it reflects the same level of interest. So what is next now for GitOps? With that in mind, that level of interest that exists, where are we going beyond that simple concept? So everything is declarative, you put stuff in Git repo, they are delivered and synced to a number of clusters and reconciled to bring those clusters to the state that you have, that's quite like the starting step really, but where does it go beyond that? So I have included Tape Town here as well, OpenShift Pipeline, OpenShift GitOps, our name of the product offerings at Red Hat, you can replace them in my talk with Tape Town and Argos CD based on Tape Town and Argos CD. And Tape Town and Argos CD is a CI core of CI CD solution that we see across many organizations being adopted and what they enable across all these organizations is for most configuration management, primarily the configuration management for both applications and the clusters, how you can declaratively roll out changes to these clusters, to this infrastructure that they have that relates to Kubernetes. And I do point out Kubernetes a lot here because like it came up on chat, GitOps does exist outside the Kubernetes sphere as well. However, being declarative is a requirement for being able to run GitOps processes, otherwise you will be shoehorning a lot of the principles that GitOps has. And Kubernetes is the platform that brings that to a lot of type of infrastructure that customers want and teams it up. So because of it, we very often talk about it within the context of Kubernetes, but it's absolutely not limited to that. Application delivery is another aspect, obviously. We heard a lot of stories today about that, how you have your application as a home charger, use customize and have a GitOps engine like Argo CD to deliver that across the cluster that is run with very granular control of what should happen across these clusters with deltas depending on the role of the cluster and so on. And infrastructure as code is really where all these GitOps principles come from. So any type of infrastructure that can be described as code, then Argo CD is able to apply those and enable those use cases for a GitOps practitioner team that adopts GitOps through Argo CD. But where does it go from there? What we're seeing is that a lot of other use cases, I mean, customers reach to this level of maturity, there are a lot of other use cases that becomes within site for these customers. And I have added a bunch of other products from specifically from Red Hat that I'm familiar with, like Red Hat Advanced Cluster Security, Red Hat Advanced Cluster Management and Anestheville. But what I mean here is most of the capability that these products provide and any other product or project that have similar capability, they can fulfill the same role within the GitOps workflow. For example, fleet management is as teams and organizations have more and more clusters, it's not just about how I configure this cluster or how I make sure that the network policy that all this cluster having seen is also about how I can declaratively provision new clusters. I need 10 new clusters with this spec. How can I have that declared in a Git repo and provision those clusters from that Git repo? It's a use case that a combination of Argo CD with a fleet management solution or project at Red Hat that is ACM Advanced Cluster Management that does this can enable GitOps workflows for fleet management. When we look at edge cases that is related to IoT, telco and edge, then we have use cases that is like similar to fleet management, but that's really large scale because you have age devices that are really tiny, very small compute and they need to have the ability to bring themselves up to a certain baseline of configuration and workflows when they have connectivity. So that becomes within the reach of GitOps workflows combined with some of the tools that I mentioned. Supply and security is extremely hot topic this year. You will hear a lot about it across the various journals and conferences. It's about really bringing more and more aspects of provenance and security control and making sure what's being coming out of application delivery workflow. It is what it was supposed to do and there are evidence that it is not tampered. And CI and CD is really the heart of what enables supply and security, bringing integration integrating security tools such as advanced cluster security or any of the other security scanning tools or vulnerability scanning tools that are available within the community or commercial side into the CI, CD workflow inside of GitOps workflows specifically to enable GitOps for supply and security. MLOps is another aspect. It's not too different really for how GitOps is approached for a regular application but there is huge use cases. We see it's growing a lot of our customers for some of the MLOps offering that Redhead has. Infrastructure as code we talked about but another aspect that this is expanding to and we see we get questions a lot about and expanded on is policy as code and compliance as code. So the same way that configuration and infrastructure should be declared as code, we see a desire, a very strong desire from customers to be able to describe their policies, how this platform should look like. Not just from a configuration perspective but also from a prevention and remediation perspective. What is not about to be done on these platforms by the developers or by their project admins and to be able to describe those also declaratively in a syntax that is that can go into Git repos and deliver to those clusters, control and apply to those clusters through the GitOps workflow using RGC. So we see GitOps and RGCV or other GitOps like engines really an enabler at the core of a lot of other use cases that are coming in the site for an organization that start this journey and start with the GitOps workflow and get beyond those primary use cases that initially seen as the value of GitOps. So what is specifically next for OpenShift GitOps? I talked about a space I wanted to mention a little bit of what's next in OpenShift GitOps and Argo CD by extension. Like I mentioned, OpenShift GitOps is based on Argo CD. Argo CD is the core of it. We are heavily invested in the Argo CD community. All our engineers work within the Argo CD community and drive the use cases that we see in the enterprise within that community. Multitenancy and self-service is an important area for us. This is something that we hear from a lot of our customers that are really after providing internal platform for the application teams enabling application developers teams to through self-service mechanism be able to implement the GitOps workflow for delivering their application. This is something that you can see in different type of DevOps related reports that come out. What comes to my mind is the famous state of DevOps report from Puppet and I think it was last year in 2021 that was one of the aspects and one of the trends that they picked up as well. One of the ingredients of success in DevOps adoption was the platform approach within the organization. The platform approach is not something that you go by. We talk about OpenShift platform a lot at Red Hat. It's not the platform that you go purchase, but rather you build a platform that can expose the services that you allow application teams developers to consume in the organization in a self-service manner without having to open a ticket or talk to an admin. This is an extremely important aspect for adopting GitOps workflow as well. To have the ability of an application team to decide on their own provision the required infrastructure and be able to consume or adopt GitOps workflow for delivering the application. What happens right now with Argo CD is that this is essentially that platform owner giving an instance of Argo CD to the application teams. The consequence of that is that the platform team has to manage hundreds of instances of Argo CD control plane for for deaf teams. What we want to go toward is a multi-tenancy model that is much closer to Kubernetes and teams can share control plane for using GitOps workflow with a high degree of isolation between the teams without exposing any attack surface or any privileges that Argo CD shouldn't. We will be working a lot on that aspect and bringing that to what a lot of our customers are asking to be able to provide Argo CD and GitOps as a service to their deaf teams with much lower maintenance and operation overhead that they're experiencing today. Application dependencies in other aspects so as we see more and more teams are adopting GitOps they come in more and more complex use cases. We are really so from James and the great example of how the microservices was laid out with different hill charts and often in the microservices where when you want to deploy an application that is built of many applications many smaller services then ordering becomes an issue. You want the deployment to happen in a certain order to make sense for that application and this is something that the GitOps workflow needs to be aware of and be able to apply them. This is something that is already possible and highly used within Argo CD in order to control when you're looking at a Git repo in what order those resources or those manifests should be applied to the clusters that are being applied. Application dependency talks at one level higher than that how in which order different Git repos should be applied to the cluster to respect the dependency that those components might have between each other. Advanced hill use cases in another area hill is an important component of application packaging. A lot of Argo CD user base use hill for deploying their application. There are improvements within the GitOps workflow that will like to exist. Example of that for example is the separation of a hill chart from the values that should be applied to that chart before deployment to cluster to be able to have versioned and life-cycled separately in different Git repositories. There are other aspects of hill that we are looking into making that experience much better than it is today. Last but not least is progressive delivery that relates mostly to OpenShift GitOps already exists within the Argo community as Argo rollout. Progressive delivery points out enabling more advanced deployment scenarios that you perhaps when you want to roll out a deployment from a Git tree go to a cluster or to your fleet of clusters you want to perhaps only roll it up to five percent of your fleet and monitor a certain matrix as the success factor of this deployment. If that matrix is higher a certain value pointing out this was a good deployment application is working well we can roll it out to 20 percent of our fleet and expand it from there. If it wasn't a good one perhaps roll out to the previous revision of this Q3 pool so that we can get the previous version up. So enabling more advanced workflows within GitOps that's really the target of progressive delivery that we'll be looking at of OpenShift GitOps all of these areas as you might notice they're all related to more advanced scenarios when teams adopt GitOps so this is something that we expect that to get questioned and asked about more and more as we go throughout the year. And with that I will stop right there.