GitOpsCon North America 2021

Enterprises have missed the “app store moment” largely because each organization has been running their own infrastructure for the past decades. With the adoption of Containers which provides the next level of abstraction to encapsulate applications, we are closer to the app store ideal, but it's really Kubernetes that adds the security and management that will finally turn enterprise software into an asset. Companies want to use the same core platform everywhere so they can focus on "the same skillset, the same tools, the same way of thinking, but not the same data centers." GitOps delivers certain standardization for that core platform – so the most important asset, people, can now focus on the delivery of applications. 

Broadly speaking, GitOps is a way of declaring the desired state of a system. But more than that, it's a way of capturing complexity in a way that the human brain can conceptualize. This talk focuses on the importance of tech developing ways of obfuscating convolution while not exaggerating simplicity.

The great values of GitOps such as commit history for change audit and code reviews / approvals are underpinned by declarative configurations. Both Argo CD and Flux support not just simple Kubernetes YAML definitions, but also Helm Charts and Kustomize. They allow templating and some basic computation for generating manifests, but how declarative are they "to humans"? Any changes to a Git repository can have a significant impact on GitOps platform setup, and code reviews play a significant role for ensuring correctness. Even if changes are carefully made and reviewed, you can still end up with unwanted changes when templates such as Helm and/or Kustomize are used. They are great at managing large and complex configurations, but can be confusing or unclear to humans. This talk takes a closer look at the common pitfalls of using Helm and Kustomize with GitOps, how to tackle them using additional tools, and a potential alternative approach using a new tool called "Importer".

In this talk, you will learn about how Intuit is extending the support for GitOps to manage Cloud Resources. You will learn about Argo CloudOps, the open source project we developed to integrate Terraform and CDK using Argo Workflows to provide GitOps automation to manage our cloud resources. We discuss how this has provided greater security, automation and allowed us to extend Git as the source of truth for our cloud resource configuration.

While GitOps is solving some big problems for continuous deployments, does the operations by pull request model fit into a continuous delivery pipeline? In this session we will explore the ‘front end’ of GitOps and how the CD pipeline will need to shift to embrace a GitOps approach, particularly around independently deployed microservices. The question to answer is how will the CD Pipeline automate the GitOps steps that are currently done by a human, such as updating .yaml files, submitting pull requests and approving commits. With potentially thousands of .yaml files, automation of these steps will be critical.

The Fidelity platform team supports internal users on different Kubernetes versions and gives cluster admins from different business units permissions across EKS, AKS, and on-prem (with Rancher). Their OSS Kraan project helps create this seamless experience in a highly regulated industry by using Kubernetes and CNCF Flux.    This talk covers Fidelity’s enterprise use case and how users can use Kraan to provide modular and reusable components across different Kubernetes clusters. Platform teams can spin up K8s clusters and install application “layers” using Kraan. Eg. an “IoT layer” comes with Prometheus, Grafana and InfluxDB for storing data from IoT sensors. Cluster admins don’t have to deal with complex deployment/upgrade logic because the kraan-controller, helm-controller and source-controller take care of that. Kraan also has a versioned layer dependency system that simplifies dependency management between addons. Add-ons can be certified and mapped to different Kubernetes versions.    Other possible Titles:  - GitOps in a Highly Regulated Industry - How To Solve Complex Apps Dependencies on Kubernetes - Kraan - The systemd for Kubernetes - How To Make GitOps Work for You - Layering Addons on Top of Kubernetes 

GitOps is typically seen as a practice to get your things in order for infrastructure changes and infrastructure configuration management. However, there is another interesting use case for GitOps where it is used to chaos test the large scale deployments when changes happen to the application. Complete reliability as such is a complex subject and it requires carefully designed chaos engineering practices and SRE focus. In large scale systems where Chaos Engineering is scaled up, the chaos scenarios also become big enough to be maintained and applied. One solution is to maintain them and apply them through GitOps.  In this lightning talk, I discuss a case study of how GitOps is used in a large customer environment to automate Chaos Engineering using LitmusChaos and FluxCD. The challenge of managing chaos experiments is presented when there are multiple team members and teams are involved. Then I discuss the schematic representation of how GitOps was structured between the application change and chaos experiments. Finally I discuss and summarise the GitOps best practices used to overcome these challenges.