 Hello everybody. Welcome to GitOpsCon North America 2021. I'm super happy to be here. I am doing a 10 minute lightning talk today on GitOps and the CD Pipeline. So it's going to be quick. And in that 10 minutes, my goal is to get you thinking about what the CD Pipeline is going to look like when we're using GitOps to do deployments and we're in a microservices environment. Things are just being disrupted by microservices. The CD Pipeline is particularly vulnerable to being disrupted because of microservices. And GitOps changes the way we do deployments. So how are we going to do it with lots of microservices? So let's start at the beginning. GitOps came from IAC, you know, infrastructure as code. That worked really well. So kind of morphed into supporting applications and that's what we call GitOps today. And when we first started doing this, we did it for containerized applications, which meant that we had pretty much one YAML file. We created a YAML file for doing our deployment of our containerized application. We created a separate environment repository to store the YAML file and the GitOps operator basically reads from it. And that takes care of the problem for us. And it's beautiful. It's audited. Everything works quite well. But that was one YAML file per containerized application, right? Easy peasy. When we did that, we had at probably maybe three, four different YAML files we had to manage through the GitOps process. You know, in a typical pipeline, we have Dev, Test, and Prod. And the way we normally do this GitOps process is we branch the environment repository for that YAML file to handle the different configurations needed for Dev, Test, and Prod. So when a new container gets a new application container got created, we grabbed the new SHA. We updated the YAML file to address any environment variable differences or key value pairs between the Dev, Test, and Prod environments. And we managed that single YAML file in those three different branches. That allowed us to create a life cycle within that GitOps model. So in some cases, you may have just one main trunk with multiple YAML files at the operator interrogates. That's another way that it could be done. But most people branch it out. So now let's add this microservices puzzle to this particular scenario. So, you know, microservices can be complicated. They shouldn't be. We're getting better at doing them. More tooling is coming out to help with it. But talking about microservices in a GitOps model means that we're going to manage a lot more files. And we're going to have to manage those additional files across the pipeline. And those files add up kind of fast. It's not, you know, we talk to people who are saying they're doing 10 microservices to 100 microservices to 500 microservices. And if we just go with 10, we're going to add up quite quickly. But in our scenario, we're only going to have a few. So let's talk about this. We're going to have more than one YAML file in this scenario, where we have a candy store cluster and a hipster store cluster. We share between those shipping, payment, and the cart service between those two websites. Now in this case, we're going to have four YAML files per state or per cluster. We're going to have the front end of the candy store or the hipster store. And we're going to have the cart service, the shipping, and the payment YAML files. Now, if we think about what that looks like going to a single one big cluster, in this particular scenario they have created namespaces for the cart, shipping, and payment service, plus the candy store and the front end, and the hipster store front end. And we have these YAML files that are going out to support those. So it gets big quick. So instead of having one YAML file to support our containerized application, we're going to have lots of YAML files. And that's what creates the complexity in microservice in many ways. Not just in this one, but in many ways. So now we're going to add the pipeline. We're going to have that environment for development. We're going to have that environment for test. And we're going to have that environment for production. So it can add up a lot faster than you realize. So in this case, we have one, two, three, four, five YAML files, including with each of their front ends. And now we have 15 YAML files that we're managing. And that's all in different repositories, because each of those are going to be managed in their own GitHub repository that represents their environment if you're doing it that way. Other ways to do it, but still you're going to have a lot of YAML files no matter how you slice it. So as I said, we're getting better at really thinking about how to manage microservices. One of those ways is the emergence of the microservice catalog. If you haven't heard of one before, they're new. You're really thinking about a service catalog, but it's a microservice service catalog. And that service catalog is a unified catalog of microservice configuration data, including things like the SHA and key value pairs and pretty important ownership. It stores and versions that information and tracks the tag for each new version of a microservice. And this information can be used to generate YAML files based on the environment key value pairs. So one of these problems is to take the human element out of the GitOps process and start doing more code generation. And a microservice catalog stores a lot of that. It hordes a lot of that information about a microservice and can be used to do that. So it can be used to generate the YAML files based on the environment. And it can be triggered. It can be a triggered event that creates a pull request in place of a deployment step, gets it into the correct environment with the correct data, the correct SHA, the correct key value information and can also automate the commit based on policies. So you might be able to define policies that says this is a good to go and you can automate the commit if the team allows it. In essence, what I'm talking about is automating the human side of DevOps all the way through the GitOps process. We've always been automating DevOps and we strive to in the continuous delivery kind of philosophy. And what we need to do now is think about how we can do that with a GitOps deployment model with lots of microservices. So this new market is starting to emerge when we talk about service catalog. This is a great article. If you don't follow Tyler Joule, I highly recommend you do. He writes some amazing, well researched articles. Recently in this article, he forecasted two trends. One, the emergence of the service catalog and two, the convergence of continuous delivery and GitOps and the new market that that will create. And actually, when you really look at the problem set, both of these markets, the service catalog market around microservices along with this convergence of GitOps and continuous delivery is what's really starting to create this new marketplace. So think about the pipeline as looking like this. You get a container registry push. So as soon as a new container has been registered to a container registry, something gets triggered to update the catalog. And when it does so, it pulls all that shaw information. The catalog then can forge that data until a deployment is triggered. At the point in time that a deployment is triggered, the YAML file is generated and a pull request is created. Once that commit is executed, we're going to push that forward and it's going to be pushed out to the end targets. Automating these steps are what will be critical to be able to achieve success in both microservices in a GitOps model. And oh yeah, meet the speaker. I didn't know if I'd have time. I am Tracy Reagan. I am the CEO of Deploy Hub. I'm a microservice evangelist, super passionate about configuration management and continuous deployments. I used to be a founding member of the Eclipse Foundation and now I am a board member of the CD Foundation who's really, really pushing these conversations. You can follow me on Twitter at TracyRagan or at my LinkedIn at TracyRagan-oms. And I encourage you to learn more about catalogs. The Linux Foundation has two open source projects. One is Artilius incubating through the CD Foundation and Backstage, which is a sandbox project through the Cloud Native Computing Foundation. Thank you so much for listening. I hope I have stimulated some thought and let's solve this problem together. Thanks.