 Who are your guides today? We want to talk about real quick, I'm Samarit Wadhwa and as Marissa mentioned, I'm one of the senior product managers here at Harness. Prior to Harness, I've held positions at VMware and Savantec. Also joining me today is Anshul, who's the principal engineer here at Harness. And prior to Harness, Anshul was at Amazon and at Cisco. What we're going to talk about today is initially you want to get started with getting the GitOps buy-in. Our agenda will focus on also talking about evaluating your current state and then how to get set up for doing GitOps from an enterprise perspective. With regards to getting GitOps buy-in, we want to focus on how do you set the stage and how do you talk to your different teams? You might talk to your managers, you want to talk to different people in your org to see if GitOps is the right fit for your application and for the different teams that work with you. Next, we'll briefly touch upon what your current state looks like. So we want to focus primarily on the application that you deploy today. What are the kind of deployments you guys are doing? What metrics matter the most to you? And finally, we'll save how you want to get set up for doing GitOps and adopting it across the board. With that, I'm going to turn it over to Anshul so he can get us started on getting the GitOps buy-in. Thanks, Amal. So let's go ahead and get started. So not all enterprises today have a good understanding of the GitOps. They are primarily focused on DevOps and there's a need to start looking at the GitOps because of its benefits and they're getting the key stakeholders buy-in. So there are two ways of doing the software delivery. One is the progressive style and the other one is the declarative style. In case of progressive delivery, you practice the buy-in or following the practices of deploying an application in a gradual manner, allowing for minimal downtime and easy rollbacks. There are several ways of doing progressive delivery styles such as blue, green, canry, AB, and feature flags. Typically, in this style, you'll have a deployment pipeline that gets triggered on a new artifact or if there's any new manifest change. In case of declarative style, there's a set of practices that imparts developers to perform tasks that could be either classified under IT operations. It requires users to describe and observe systems with declaratives and specifications that eventually form the basis of continuous everything. The main difference between the progressive and declarative models can be summed up in one sentence. Progressive focuses on how you deploy and declarative focuses on what you want to deploy. Declared deployments can follow both push-based and pull-based approaches. In case of push-based, whenever there's a code change, the application's code is getting, you know, gets updated. The build pipeline is triggered and which, you know, updates the container images and finally updates the environment configuration in repository with this new deployment description. This update triggers the CI CD pipeline and deploy your application or service. The pull-based deployment strategy uses the same concepts as the push-based variant but differs in how the deployment works. With the pull-based deployment approach, the operator is introduced, as shown in the image on the right hand side. This operator takes the role of the pipeline by continuously comparing the desired state in the environment repository with the actual state defined in your deployed infrastructure. And whenever there are differences, notice this operator updates the infrastructure to match the environment repository. Additionally, this operator can even observe the image registry and deploy new versions based on that. So as we are all aware by now, the GitOps was coined by B-Works back in 2017 where they defined GitOps as the concept that deployment should be easy as an engineer and acting a code change, commit and merge. So GitOps upholds the principle that everything should be defined declaratively. Git is the one and the only source of truth. It requires the desired state of the system to be stored in a version control system and so that anyone can view the entire auditory of changes. All changes to this desired state of your application or service are traceable, commits associated with the committer information, commit ID and the timestamps. This means that the application and the infrastructure are now version artifacts and can be audited using the gold standards of software delivery and deployment. So following GitOps practices brings a lot of value to your enterprises. So few of them are like increased productivity. Since GitOps enables faster and more frequent deployments, teams have an easier time pushing a minimal viable change. Using GitOps best practices, teams can ship several times a day and river changes if there's a problem. High velocity deployments leads to more rapid releases and helping your teams deliver more business and customer value. Next is the improved stability. When you use GitOps to manage your application, you automatically gain a convenient audit log of all the app changes and audit level of who did what and when your application... And all this auditory can help you to ensure your application can be stable and meet the compliance criteria. GitOps also reduces significantly the risk factor because all changes to your applications are tracked through merge request and changes can be rolled back to a previous state if an iteration of the application does not work. Next is the better security. So GitOps, it helps to streamline the management of authentication and authorization requirements for infrastructure modification. Since in our infrastructure declarative defined and it's part of the CI CD pipeline, the individual developers do not need to know the credentials of the target resource. Also, there's a simplified tool chain that can reduce the attacks since everyone will be using a single tool. And if an attack does occur, teams can revert to the desired state by rolling back to the using the version control system. It helps you to reduce the downtime and outages while enabling teams to deliver software in an uncompromising environment. The next is the higher reliability with Git's capability to revert and rollback and for changes, teams gain a stable and reproducible rollbacks. Because the entire system declaratively defined in Git, we have a single source of truth from which to recover from and reducing your main time to recovery from hours to minutes. Last is the consistency and standardization. Since GitOps provides one model for making infrastructure apps and changes, so then you have a consistent end-to-end workflow across your entire organization. Not only are integration and continuous deployments, pipelines are driven by pool requests, but your operation tasks are also now fully reproducible through Git. So, the next is, how do we convince the members in our organization to start adopting the GitOps? So, sometimes it becomes a bit difficult to have the conversation with teams, how can you move to GitOps? So, however, the value provided by GitOps should itself act as a catalyst in getting them started to look at the GitOps. In order to further convince the members of your organization, one needs to research on the GitOps practices, learn more about what is GitOps, how it fits in with your organizations, use cases and application needs. We should all, the GitOps proponent should also explain what are the overheads of setup and what is the domain expertise as they plan to adopt GitOps. So, today, GitOps is mostly chaos is heavy. So, users needs to make sure that they have the right training about the activities. The GitOps advocates should start small by deploying a known business critical application using GitOps and better understand what works well and then adopt it across the entire application suite. So, next is the deployment matrix. So, publishing the stats showing the true representation of how your organization is doing the software delivery is very extremely important. Using these stats, one can show how often is code is getting shipped, how fast the road backs are happening in case of failures. So, this helps users to understand how can, they change their software deployment paradigm. The last is the GitOps case studies. So, there are multiple case studies out in the field that help to build the context of why your team or all should adopt or look at the GitOps. So, start by looking at the other enterprises or the other industries in the same domain and you'll see what is the success or the value they have attained by adopting the GitOps. Doing all of the above will convince the teams that shipping code helps the organization to move faster and builds happy customers. I'll now hand over to someone for the next slides. All right, thank you, Anshu. So, I think we have a good understanding about how do we get the GitOps buy-in? Now, we wanna focus on evaluating your current state. So, what does this basically mean? It means that how do you identify the applications for doing GitOps? So, the challenge that teams usually have is to understand which application is suitable for GitOps and which is not. For your application to be a good candidate, it should follow the GitOps principles. It's important to see if your app can be described declaratively, right? Because you wanna make sure that everything lives in Git. So, it should be stored in Git and that will give you the ability to see what revisions or versions of your app code is living over there. Next is the approved changes you make to your application config in Git. Can and should be directly applied to your cluster without any additional parameters being provided during runtime. What does this mean? This means that if you have to provide specific parameters during runtime as a part of your pipeline setup, then obviously this application is not a good fit for doing GitOps. Next is for the app that has been deployed using GitOps in the event that a cluster goes down or it dies, a pod dies. To get it back up and running, it should be as seamless as reapplying the same application configuration on new cluster. And the reason being because you already have the entire app config available in Git. All you have to do is pick it up and reapply it on a new cluster. Next, let's talk about if GitOps is only for Kubernetes. Well, this question always comes up, right? The answer to this question is no, it's not only for Kubernetes because it does not matter if the cluster runs in Kubernetes or not. All GitOps cares about is having an operator and it cares about having the sources Git and the destination on which can be any infrastructure. In this case, it could be a virtual machine. It could be a cluster of a type of PCF. It could be AWS or Kubernetes. In GitOps, all we want and care about is the whole system to be managed declaratively and it only uses convergence to make sure that whatever is in Git is being applied to the cluster and vice versa. As mentioned in the previous slide, GitOps is not just for Kubernetes. So as we see here, you have your GitOps engine that you can see. And what happens in this case is with the predefined rules and configurations that are responsible for monitoring the Git configuration and observing the current state of your cluster. You always have the ability to take an action to get your cluster to the desired state. Now, in this case, your cluster can also happen to be a virtual machine. It could also be another service, such as an AWS service or a PCF service. Centralized strategy. There's always a confusion and assumption that there is a centralized strategy just like DevOps, where we have a template that can be reused across different environments. And trust me, this is not the first time we've heard this or this is not the first time, you know, people have this confusion. The reason being because in DevOps, the whole idea is about reusability and sustainability. So people really want that aspect of reusability to be there for GitOps as well. But in the case of GitOps, what happens is that this statement does not really hold true because one, there is a mapping between your cluster and Git, which is a one-to-one mapping. And it does not really follow the paradigm of centralized strategy. What does that mean? It means that users will have to maintain and should maintain separate repositories for different environments, which is good. How would that comes with the overhead of maintenance, consistency, and also the visibility across all the different environments? Now, let's talk about, you know, what is the tech stack that GitOps currently supports? Well, as I mentioned, it is not only for Kubernetes, but with everything that is available today, it seems the most suitable to do GitOps with Kubernetes. Of course, Kubernetes sits at the heart of GitOps and so does Git because they are married together. But, you know, always there's this discussion that why is it tailored only around Kubernetes when we hear the term GitOps? Well, the recommended Kubernetes configuration mechanism is entirely declarative in nature, right? It's all YAML files. So when they lend themselves to this approach, particularly well, I don't think it's a surprise and it shouldn't be a surprise that, you know, the genesis of this approach is to help tame Kubernetes. So that's the reason why whenever we hear the term GitOps, we think of Git, but we also think only about Kubernetes. It's the whole declarative approach that Kubernetes provides. All right, now there are a lot of different tools out there in the market, right? You have Flux, you have Argo, you have Harness, you have Jenkins X, all of these different tools provide some form of integrations. Or, you know, they assume, they say that they're providing GitOps, but they're solving some part of GitOps. GitOps from an end-to-end perspective does have a lot to it. And there's not a one size fit all or a one tool that's all kind of a solution. There are some important aspects of GitOps that, you know, these tools are unable to resolve for and we should consider this. Like Harness is looking into providing more visibility as well as scaling, as well as propagating releases across environments, right? But the other tools, what happens is that they provide one or the other aspect. But when you think of a tool to adopt a tool for doing GitOps, you want to think about all the other entities as well. You want that visibility aspect, you want that scaling aspect, and you want to understand what else and where you want to be a few months from now. Okay, so that was all about learning more about the GitOps part. Now let's talk about pains. With every single positive does come some negatives. So, you know, it's not always roses. So let's see what are the pains of doing GitOps? Some of the pains that we know of, and you know, a lot of people want to address is GitOps doesn't address promotion of releases between environments. I think this is a very important pain point to call out because if you look at the GitOps charter itself, they literally say that, you know, GitOps doesn't provide a solution to propagate changes from one stage to the next one. And it is recommended to only use a single environment and avoid stage propagation altogether. Well, if you have a problem, you don't run away from it, right? You have to address it. So the most popular way of handling different environments seems to be either by using different Git branches and that solution also has, you know, a lot of disadvantages if you think about it. One, it opens the gate for people to do commit to specific branches. And, you know, that could be environment specific code that you might be writing into. Second, it makes your project coupled to very specific environments instead of it being generic in nature. Third, it requires extra effort to keep all the branches in sync at all times. So think about it when you have to do some hot fixes to specific branches, there might be a branch sprawl and you have to look into what's going on in each one of them. Last but not least is it puts the unnecessary strain on the CI system that has to always keep rebuilding, keep checking and, you know, do the unit test if necessary for each and every individual branch. Next, auditing is problematic despite having all information in Git. Absolutely. Just because you have access to the whole deployment history of the cluster in the form of commits, it doesn't mean, you know, that you can easily audit its functionality. And if you think about it, the current problem of GitOps tools are great for managing Git hashes, but when it comes to searching and understanding business value, I don't think, you know, there is much that we can do because all they provide is simple pre-text search capabilities. So it's pretty difficult to understand who did what when and where. GitOps covers only a subset of the software lifecycle. Absolutely. And, you know, this is probably one of the most important pain points that people are well aware of. Reason being that GitOps model follows a one-to-one mapping between your cluster and your Git repository. So GitOps tools are sometimes marketed as a one-size-fits-all, as I mentioned before. And this will only solve for the release problem, but it is simply not true. GitOps requires that your deployment artifacts are already there. That is true. This means that the tasks are just compiler code, running unit tests, integration tests, any of the security scanning and status analysis is something that's always a missing piece to this big puzzle. And last and least is running GitOps at scale is difficult, which is very true, right? Because if you adopt GitOps in a large company with a big number of environments and a lot of different teams, you know that your Git repositories are gonna quickly skyrocket, right? You're well aware of that problem. Now, this makes it very hard to deep track of what is going on in each and every environment and can quickly lead to configuration duplication or people making commits to specific environments where instead of using the shared configuration. For example, if you might have maybe 30 Git repositories, right? With different Kubernetes manifest and maybe you wanna make a central change to all of them. What does that look like? It entails 30 different Git commits, which is just not scalable. On the other end of the spectrum, if you think about it, you could have a single Git repository, right? And all of your environments, but all the people collaborate along with the CI CD systems. But having a single gigantic Git repository can become a bottleneck as well. Because if you think about it, something does go wrong. It introduces performance issues and think about scanning the repository for different changes should you need to go through an audit. So that, you know, puts it all together that there is some pain associated with GitOps as well. Now, next, let's talk about the setup for doing GitOps. Primarily the components or the architecture of GitOps comprises of four different entities and these are the most basic, crucial and important entities. What does that entail? Point number one, it needs to have your configuration. Now this configuration can be your infrastructure configuration and it could be your application configuration. Second is you need the most primary aspect, which is Git. Third, you have your GitOps operator, the operator that's making sure and keeping your Git in sync with your clusters. And last, not least is your Kubernetes clusters. In this case, as I mentioned, because Kubernetes is one which is the closest to GitOps, that's why all of your clusters will today be representation in Kubernetes. And now let's talk about scaling for enterprises. So obviously when people start adopting GitOps, there is a need to scale at an enterprise level because with GitOps adoption, you wanna move from an operational aspect to an architectural aspect. For an enterprise when they consider an application and from the application standpoint, what should this really matter is that where does a particular enterprise want to be with a business critical application and not about how one plans to get there? Today enterprises primarily care about the house, they are busy solving the how do we make this application better? How do I make this application do this differently? I think answering that how is not that important because all of their current processes are well established for answering that how. When they should actually be thinking about is where do they want to be not just now, but three months from now, five months from now, right? And that's where GitOps should come into the picture. When you architect your application, make sure that you think about the GitOps principles because the last thing you want that GitOps is not just a tool, it's an actual building block on which all your applications are being architected. So they scale for themselves. This also means that the people need to take the time and effort to learn the details that go with making the source code repository, the single source of truth. Today, because of all the different teams and all these different operational models, there is a segregation of duties amongst everyone. But you don't want that. You want that everybody comes to a single focal point from which all actions upon the enterprise can emanate. Next, let's talk about define everything declaratively as code. And when I say everything, everything has to be declarative in nature and in the form of code. Not everybody today has that mindset. It is going to take some time. It is going to take some effort to get this shift in the mindset as people now have to start thinking about doing everything in the form of code. Can you imagine doing infrastructure in the form of code? Well, that sounds good, right? But if you think about it, that for every single application that you have, for every single application you plan to build in the future, you have to think about doing infrastructure as code from the get go. And as I mentioned, that GitOps has to be a foundational aspect. Apart from that, obviously comes your application configuration, comes your user tests, comes your integration tests. So everything has to be thought of and has to be done in the form of code. Only when this form changes, it will be easier for folks to adjust that the applications they're building is following the GitOps principles and can scale better, not just for the teams, but for the enterprise, providing more business value. Last but not least is the teams are very used to providing inputs during runtime. When you start doing everything as code, you need to think about it from the very beginning of what inputs need to be provided, because all of the code that you're writing has to be encoded as a part of your application configuration. There is no runtime inputs that you can provide, which is a difficult shift to have, to be honest. But if it is done from the building blocks, it is pretty easy and widely adopted across the enterprise. Last, not least, I'd like to spend some time on visualization and visibility. What does this mean? Well, better insights into what version has been deployed on which infrastructure? From a developer perspective, it is easy to see the configuration. The division stored in Git, correlated to the environment. However, think about it from an executive perspective. It does not hold true for the execs, because when they wanna see or have a clear understanding of what version is running on what infrastructure, they don't need to worry about the SHA or the version or the commit ID that was presented in Git. All they need to know is that version 1.2 is running on my prod environment and version 1.3 is running in my QA environment. Next, the dashboarding capabilities for application configuration versions with custom metrics and inputs, that is really important. These custom dashboards provided toolbox for building your own visual interface around GitOps data using flexible filtering. Now, Harness has this capability of doing custom dashboarding, right? You wanna use this for GitOps as well. You wanna see how this data can be flexibly filtered. And you also wanna see that, who has done what, when, and where? So you get the aspect of tying your audit trails associated with the deployments. You get the Dora metrics, you get which development and deployment happened at what time, the velocity with which all this happened, any bottlenecks that happened around it and the rollback aspect of the mean time to restore that when a deployment went wrong. So you wanna get that details as well. Next, we're gonna talk about rollbacks. So if you don't mind me saying or asking, right? The one dream that we've heard of from multiple enterprises is democratizing deployments. This is a dream that any enterprise would like to have because they wanna reduce the dependency across different teams. Now these teams could be their development team. It could be their SRE team. It could be their DevOps team, the infrastructure team, right? This is giving more power in the hands of developers to do what they do best, right? Build and deploy. And of course, with the right guardrails. So what developers do is they build the latest and greatest features and deploy it quickly into the hands of the end users, which brings additional value and it generates more business for the enterprises. And should something go wrong, right? What happens then? Then you obviously gotta rollback. But there's a safety net in place already to rollback. In the case of GitOps, rollbacks are pretty well handled as well because it is very simple due to the declarative nature of Git. In order to rollback, all the user needs to do is it is as simple as applying the previous version of your application and you simply use the pass commit for doing this. This combination where the GitOps tool itself will sync both the previous Git hash to the cluster and auto-reverts to the Git repo in order to keep the consistency. Helps you to make sure that you've been rolled back to the right version and you're up and running within no time. Now let's talk about extending GitOps. We've spoken about how we can scale for the enterprises, how we can rollback when something goes wrong, but how do you extend GitOps a little bit further, right? You wanna think about the different aspects to consider other people in your different teams who care about security, who care about maybe having some policies. So let's talk more about that. One of the most important thing is governance when it comes to GitOps and tying them both together or marrying these concepts together. It does take some time to get to this because people are still trying to figure out how to get GitOps correct and how to get GitOps right. But once you have your GitOps set up correctly, the next thing you wanna worry about is how do you scale better for your enterprises and extend all these features of governance to tie in with GitOps and make sure that you are doing the right thing for everyone else as well in the company. So there are many reasons why developers and platform engineers would like to what we call policy as code into their current GitOps process. For one, obviously the strategy helps to accelerate the application development and deployment process because it helps solve any of the change management hurdles that can slow development pipelines. Second is that policy as code saves platform engineers and DevOps teams from having to manually review hundreds of lines of configuration code, a process that you to buy all accounts, machines can and should be doing to be honest. On the development side, policy as code also helps the app developers to learn and understand what are the company's configuration? What are the security and compliance policies? It gives them the right guardrails and how correctly to abide by them. For example, a developer may not remember or may have no reason to remember that when deploying a load balancer onto a Kubernetes and AWS is not sanctioned but policy as code solves this problem automatically for them, right? Or maybe the number of replicas that you can have on a particular part should be only set to two but by mistake did it at four. So instead of the developer worrying about it, you already have policy as code that's helping you solve for it. So the ability to run policies during GitOps deployments and adhering to those policies as a part of the deployment and upon any violations being alerted, audited and notified automatically and rolling back to the previous successful compliance state. So Git remains in sync with the cluster is GitOps with governance. Next, let's talk about GitOps plus AIOps. There is a notion that once GitOps is completed everything is looking good and it's very important to monitor the deployment state because that's where the AIOps comes into the picture. Now, think about it as a part of your GitOps. We can see that the manifest change or infrastructure change or artifact change that happened but post deployment users should have the ability to configure some hooks. And obviously these hooks will be called by the GitOps operator post the sync. Now, this hook will leverage AIOps for what? In order to understand the changes in the service help and determine the course of action by either alerting the user or reverting the last recent commit. Last not least is actions on drift detection. What's really important is that drift could be because of an event on the cluster or an application configuration update in Git. Any pod level updates such as a pod dying or a pod deteriorating should notify the user. And in the case of a PR based where there was an update to the configuration of your application but that update has not been approved by the user customers might want to revert that Git commit then and there. To conclude enterprise customers would like to be alerted whenever there is a drift in their repository. And obviously, based on that, they get to choose if they want to approve this or reject this particular drift that they've just obtained. Putting all this together will help enterprises scale and will also help users to adopt GitOps in a more seamless manner. We'll now open it up for any questions. Marisa, I'll turn it over to you. Okay, it looks like one just came into that Q and A. We got a couple are coming into the Q and A. Can we leverage GitOps on Terraform as an also equal use case? So absolutely, right? So you could leverage GitOps with Terraform. That is something that's actually happening a lot right now as we speak that people are confusing infrastructure as code or GitOps. In the case of GitOps you need a declarative style of doing a certain aspect of your code deployment. In the case of Terraform what you're doing is you're provisioning the infrastructure. So if you do have the ability for Terraform to be for the code of Terraform to be written in a declarative manner, then absolutely there are tools out there that are doing GitOps with Terraform and not only just Terraform, but other tools such as CloudFormation where infrastructure as code comes into the picture. What learning resources would you recommend for this topic? I do recommend. So one thing that's really important is that for you to understand where your application and where your team stands today, right? In order to learn more about GitOps you can obviously look at different tools available in the market but I think it's important for you to understand are you looking for scaling? Are you looking for more visibility? Are you looking for just getting the GitOps principles? So I think that is something for you to consider for sure. And you should also think about where you want to be not just six months from now but a year from now because there might be an aspect where you might have just certain applications set up today but once six months down the lane you might have some business critical applications for which GitOps will be the way to go and you want to learn more about those aspects right now because you want to invite those as you build an architect for your application. How DevOps and GitOps are bearing in their aspects? Well, with regards to DevOps, right? It's a culture that focuses on CI and CD. It doesn't really, whereas GitOps is more of a technique that you can use with Git to provision your infrastructure to do your deployment. In the case of DevOps, obviously, there is the aspect of your pipeline which comes into the picture and you have your artifacts that you build, you have your CI process and you're building for that and then you go ahead and deploy. In the case of GitOps, also you have your build process but Git is your source of truth and what it was running in Git was running in your cluster and vice versa. With the case of DevOps, one thing you want to understand is you could do an end-to-end flow such that you can start with your CI pipeline, you do your CD, you can do your verification. Like Harness has all of this and then you have all the way moving further into doing feature flag and managing your feature flags, right? In the case of GitOps, there is the focus on making sure to get your change propagated to your cluster as soon as possible and that's what you should be most caring about if you may. All right. Is there a class of use cases that GitOps is more suitable for beyond infrastructure as code? Well, absolutely. If you think about it from a use case perspective, think about your security fixes that you want to apply in your clusters as soon as possible, right? Maybe we have a retail application, something goes wrong. You want to make sure that there is a particular service that has been deployed, your login service, sign up service that has been deployed, but you want to make sure that you want to apply a change to this as soon as possible, right? So with this, you have your Yamlify that's ready. You can go ahead and you can use that and apply it to all clusters then and there. In the case of DevOps, what happens is that you really have to wait for your CI process to go through. You can bypass security scanning such as your unit tests, your integration tests and it obviously reduces the time for waiting for maybe an hour or so down to certain minutes. That's one thing. The other thing is obviously in the case of networking, at least what we've heard is when people switch over from 4G to 5G networks, they feel like GitOps is the way to go because you have the capability of edge nodes that they can use and with edge nodes and doing GitOps with the edge nodes has kind of been more helpful. So that would be another use case. Any other questions we can take? All right, Marissa, I think in that case, we'll turn it over to you. Okay, wonderful. Thank you so much, Samarth and Anshil, for your time today and thank you everyone for joining us. Just a quick reminder that this recording will be on the YouTube, Linux Foundation's YouTube page later today. Okay, thank you again. We hope you'll join us for future webinars. Have a good day. Thank you. Bye.