Tales From the Branches - Why GitOps Matters For Your Business Success

Hi there, and welcome to this talk about why GitOps matters for business success.

My name is Steve George, and I'm the COO at Weaveworks, one of the companies that's been working in the cloud native space. We coined the term GitOps a few years ago from helping teams build and operate cloud native applications and platforms at scale, and that's a term that's been taken up across the industry.

My goal today is to tell you what GitOps is, why it's important from a business perspective, and then, hopefully, having convinced you that it's a great thing, how you can adopt GitOps. Let's jump right in.

The thesis for this talk is based on three things. GitOps supports the DevOps approach in a highly effective way, and specifically what this means is that GitOps brings DevOps to cloud native software operations. It's taking the principles of DevOps and then applying them in the specific cloud native sphere. And for that reason, because we know that the DevOps capabilities and principles help teams to operate more effectively, GitOps takes that mantle forward, and it can help to significantly improve the way that we operate cloud native software.

GitOps, what is it? At a central level, it's very straightforward. We're thinking about Git for configuration management and Ops, the operations of software.

Here we have our developers on the left. They're working on their code and their configuration, and they've got an application that they want to deploy into a runtime environment, a Kubernetes environment, here on the right with two applications. They could, of course, just directly apply that into the environment, but they want to take advantage of automation.

Using automation, what we think about here is the fact that on the left-hand side, we have the desired state. This is all of the configuration, everything that is needed to deploy the actual service. And then on the right-hand side is the actual state. This is the running system. And they use automation to deploy that service, that capability, that application, whatever it is.

With GitOps, one interesting aspect here is that we can take advantage of a convergence loop. What I mean by that is we can take advantage of the declarative basis for cloud native technologies, Kubernetes specifically, and we can ask the system what is the actual state. From that, we can say we have a desired state, what we want it to be. We have an actual state, what it actually is, and we can see if the two things are converging together. If they are, we know that our deployment has been successful, whatever that is. And if it isn't, then we know there's a problem, and we can react accordingly. Ultimately, that is the heart of what GitOps is, using this convergence loop to say, I want something, deploy it. Did I get it? In a continuous loop.

Another aspect that's interesting here, of course, is that we're using Git. We're bringing Git as a single interface to the operations of software. So moving it from not just an interface for development, which development teams are very familiar with, but moving it across into that operational sphere and making it the single point of collaboration and work that the teams use whenever they're deploying or operating their software.

In the CNCF, GitOps is an open working group, and we've been working on the principles of GitOps for a while as everyone has come to understand how GitOps can be used to deploy and operate software in the cloud native sphere. These principles are as follows: the entire system is described declaratively. Here we're taking advantage of Kubernetes' declarative nature and many of the other cloud native technologies, and we describe the entire system. Here what we mean by that is the Kubernetes platform itself, any services that it needs, the workloads that you're intending to run on top of it.

Then we have the canonical desired version stored in Git. This is what we want stored in that Git repository. We can then make sure that approved changes are automatically applied. We're using that automation to apply those changes. We'll talk about some cases here where we may not want to automatically apply them, but it's important that we use an agent to take advantage of increasing the speed in which we can do those deployments.

Then, because we've got this software agent which understands the actual running state within the runtime, we can check whether there has been any divergence. When there is that divergence, we can take an action. If the runtime state diverges, we can choose to remove that bad change and automatically deploy a new one. Ultimately, what we have here is a closed-loop system.

When we talk about GitOps, one of the first questions that people have is: Well, I already use my CI system to deploy applications, so are you telling me that I need to change my CI system, something I've put a lot of effort and teams understand very well? And we're not. CI remains as it was before. All we're doing is removing the CD part from it, and we're taking that into its own separate area where we do deployments with an agent, and then that's its own system. Continuous delivery now works using a GitOps system.

Because we live in a continuous world, we know that we need to continuously operate and build new versions, deploy new versions, scale our systems, deal with latest changes, new sales, whatever it is that causes the system to have to respond. The thing to bear in mind here is that we're not just talking about continuous delivery. We're also talking about continuous operations, all of the things that need to be done to operate software on a daily basis.

That's what GitOps is. But why do we want to use it? Ultimately, we want to use it because we want to get better at doing software. In the DevOps world, we understand that there are key characteristics, key performance elements in the software delivery process which, when done well, help IT teams to deliver great business value. This table is particularly famous and well known for a demonstration about how these particular metrics really apply at a business level.

Ultimately, if we can deploy software more frequently, then we can make sure that the changes are smaller, and that will mean that we can reduce the lead time of those changes, ensuring we get those changes into production as quickly as possible, making us agile and responsive to business needs. And, of course, ultimately there are changes that happen but don't go well. So thinking about how we improve our reliability by ensuring that our time to restore service is as small as possible, and that any changes that we do make, we do our level best to ensure that those changes have a very low failure rate.

To demonstrate why GitOps is relevant from a business perspective, I want to try and demonstrate how GitOps applies and helps to support these key metrics, how it improves and ensures that we can deliver these and help businesses to support the way in which they deliver these elements.

Ultimately, what we're looking at here is dev teams or DevOps teams who need to deploy applications. What they want to do is be able to release more frequently, reduce the time to do those deployments, and then operate those applications as efficiently and as effectively as possible. What we're talking about with GitOps here is the fact that it provides both familiar tooling and enables a self-service approach.

In many enterprises and complex enterprises, of course, we have an underlying platform and often a platform team whose job it is to create a platform that the applications will work on, and they need to maintain the reliability of that system, security, compliance, and think about doing that as efficiently as possible. I want to show you that GitOps helps to enable resilience and that certain capabilities within GitOps deliver security and compliance.

First of all, I'm going to focus on the key metrics which are really developer-focused. These are the ones that are around deploying software as quickly as possible and making sure that therefore, because you're incrementally deploying those changes quickly, the lead time to getting a deployment out there is as small as possible.

The first way in which GitOps really supports these two metrics is the fact that it's familiar tooling. Development teams understand Git. They know how to use it. It's the center of their universe. What we're doing here is taking Git not just from being a development tool, but into being an operations tool.

It's not necessarily part of Git, but it is inherent in the way that we use Git now that it's an extremely collaborative process. What we're looking at here is a pull request, a way to fix something. We've got various people talking about that, figuring out what the right approach is. Git is an extremely collaborative way of working, with all of the different Git services out there these days, and we can bring that collaboration into the operational universe where we can ensure that there are many eyes working on a deployment or a particular operational change. Everybody can collaborate together using a well-known process and system and way of working.

Of course, what we want to do here is the second part: ultimately provide a self-service platform. How does GitOps enable a self-service platform where teams can deploy their applications, their services onto that platform? Now, we're not here talking about self-service infrastructure, so we're not thinking here about the underlying servers, but we are thinking about the cloud-native environment, anything that is needed to run that environment, and all of the things and services and applications that are needed on top, and any operational systems that are needed to look after those applications.

One of the things that you really notice with self-service is that, in order for platform teams to deliver that, it's something that they need to configure and set up. You'll recall that earlier on I said that one of the things that's really interesting about GitOps is that it defines the entire platform. Using a GitOps approach means that we can define a cloud native platform. We can say which version of Kubernetes is allowed, which ingress is allowed, which monitoring system is allowed, which kind of different production elements, and then we can deliver that to our development teams as a platform which they can then use in a self-service way.

The next bit about GitOps which is really important is that it enables resilience. Why this is valid, or where this is applicable, really is that we can feel confident about going faster and putting more changes into production as quickly as possible if we know that we can return to a good known state. Ultimately, it's about taking the handbrake off because we know that we can get back to a good position.

The way that we do that is ensuring that we have a resilient platform. From a platform team perspective and from the developers operating a service, they can go faster because they know that everything within the platform is defined, and they can return to that good previous known state, whether that was last Tuesday, or the week before, or a couple of hours before. They know that if the worst comes to the worst, they can get back to that good known state.

What we're talking about here is the Git semantics. Because each version is a complete representation. It has everything within the platform, everything which has been recorded, defined. Then, using the benefits of cloud native, we can deploy that and rebuild the platform or the service. And, of course, because it's within Git, it's immutable. It's got a SHA. That SHA is known. It's completely immutable, and we can use that as a record of the changes.

In practice, the way to think about this is, here's our pirate, and he's not using a configuration management approach, and he's not using GitOps. He just likes to log in and do kubectl apply directly to the production cluster. One of the things that's really interesting when you look at teams and the way that they operate production platforms is, this is very common. One of the effects that it has is that teams often think that their platforms have certain components, are running certain versions, are configured in certain ways. Then in reality, somebody has done something, and it hasn't been recorded, and therefore they don't know exactly the versions and the capabilities and the configuration that they're running.

But if you're using a GitOps approach, what happens if somebody tries to do a straight kubectl apply? There will be an immediate alert back because we have that definition of what the desired state should be, and the agent will understand that the cluster, or the application or service, has now moved away from the desired state. The actual state and the runtime of the running system is now different from what it should be. At that point, it will send an alert, and we can choose what action we would like to take, whether that's automatic. In this case, what we might do is say, right, we want that change removed, so we're going to revert back to the desired state, to that known good deployment. That will automatically happen, and so the change will be wiped out.

A side effect of the fact that everything is recorded within Git and that everything is a SHA is that compliance teams really love GitOps because it's an immutable record of everything which has happened within the system.

If we think about the fact that, ultimately, in order for development teams to be able to go faster, the most important aspects here that GitOps helps to provide are the fact that it supports deployment frequency because it gives teams something where they can collaborate together using common tools. And because it's more resilient and able to recover to previous states and points in time, it means that you can take the handbrake off making those changes because you always know you can get back. That helps to ensure that the amount of work in progress that you're holding back is relatively low because you can make changes as quickly as possible. Then hopefully that helps to reduce the lead time for changes.

The other aspects here are the platform team, the resilience team, the resilience aspects: time to restore services and reducing the change failure rate. We've talked about the fact that in order to restore services, you can do that using GitOps because you've got the definition stored within Git.

But there's a couple of other ways in which you can ensure that you reduce the failure rate. I'm going to mention the fact that you can collaborate, that you can inspect the changes. Here we have our developer who's received a pull request. They're able to inspect that change and make sure that change is something they're happy with. And you can use automated guardrails. Here I'm showing some parts of the configuration have been locked, and it's been decided that those configuration elements should not be changed. So you can use automated guardrails, policy, security tooling, and all of that tooling. There's lots of tooling out there that works very well with Git pipelines, and all of that tooling can be brought into play here.

Really what you have is this control point where you can make the decision about whether you want to deploy the new version. We said at the beginning that there's many situations where you may not want to do fully automated deployments. That's not a realistic expectation for many enterprises, many situations, many particular services. There's nothing within GitOps that requires you to do full automation. You just want to automate as much as possible. In this diagram, we've got a manual approval process. Perhaps there's a manual sign-off process. Everybody's happy with the change. The guardrails say that it's all fine, and at that point, we're ready to make that deployment. Then, of course, if there is an alert, if that change doesn't go well, then we can revert.

That really gets me onto the next bit, which is really about progressive delivery. GitOps and using the cloud-native technologies is really fantastic for using progressive delivery because we can take that particular atomic change, we can deploy it into the cluster, and then see whether it deploys well, see if a certain amount of traffic goes to it well, and everybody's happy with that, or if a runtime is showing some sort of performance issues over that deployment. If we're perfectly happy with that, we can then continue with the deployment. If we're not, as I said, it's easy to revert back.

That atomic change, that unit of change, is also something for that service or system that we can then deploy into other environments. Imagine that you're running many, many clusters, many, many environments, many services, and you can deploy the same versions to different environments, or you could deploy the same service into many different environments, for example, which is a common requirement and need.

Hopefully, I've now shown you how GitOps supports all of the key DevOps metrics that we know help to improve the way in which IT can support the business: familiar tools and self-service for making sure that development teams are as effective as possible; and then a resilient platform, which is using a versioned immutable store, making it simple to understand drift and get back to that previous known good state at any point in time.

We've talked about what GitOps is, and we've talked about why we would want to have GitOps. Hopefully, I've convinced you that it's something that's worth your time and effort. And so now the question is, how can I adopt GitOps?

GitOps itself is an industry term, and I think it's really key that everybody understands what it means and how it works, and that we have different GitOps solutions out there which are all interoperable and work together. That's why the CNCF has a GitOps working group, where there are many vendors that have come together across the space who are working to understand what GitOps is, how to use it, and develop the way in which we can operate software using a GitOps approach.

That's also a community where there are many open source users and end users who are really interested to discover the ways in which to use GitOps. This community talks a lot about how we should drive or how people can adopt GitOps and use it within their environments. We've worked with teams of all shapes and sizes over the last few years, helping them to take advantage of GitOps. In our opinion, there's a simple way to do this, and you can make it as straightforward as possible.

The key prerequisites are that you obviously have to have a Kubernetes environment, and you need to have some container workloads that you want to deploy into those environments. The first step up this path is to do core GitOps, and here we recommend that people focus on deploying their applications, workloads, and services in a single team environment. So single environment, a single workload, a single team. My one sort of little reference here will be to Weave GitOps Core, which is our open source package version, which helps you to deploy applications.

Beyond that, as you get into more levels of complexity, we're then looking at enterprise GitOps, where we can build in a complete platform. Then, of course, scaled GitOps, where we go beyond this, where we're thinking about more advanced policy and security across many, many platforms.

Thank you for your time. I hope I've demonstrated to you what GitOps is, why it will have an impact for your business, and interested you enough to try it out. If you'd like to find out more about it, I'll be very interested in your questions, or check out the Weaveworks site and get started with Weave GitOps Core. Thank you.