Codefresh Launches GitOps 2.0 as a GitOps Working Group Takes Flight
Honeycomb is sponsoring The New Stack’s coverage of Kubecon+CloudNativeCon North America 2020.
At this year’s KubeCon+CloudNativeCon North America, Codefresh announced its vision for a new evolution of GitOps, dubbed GitOps 2.0. The pronouncement came just days before the launch of a GitOps Working Group that is attempting to nail down the basics of what, in this context, might be referred to as GitOps 1.0, which the Codefresh took to task earlier this month.
To start, Codefresh, which offers a Kubernetes-based continuous deployment and continuous integration (CI/CD) platform, is focusing on providing observability and metrics with the launch of a detailed view that lets you see everything related to a release, with controls over rollbacks and larger aggregate views to see what’s happening across multiple applications.
The working group, which was formed by Amazon, Codefresh, GitHub, Microsoft, and Weaveworks, will live under the auspices of the Cloud Native Computing Foundation (CNCF), where it will work to “provide companies and individuals with the skills, knowledge and competency to implement GitOps tooling and methodologies which simplify the operation and management of infrastructure and cloud native applications.” Currently, the group lays out five basic principles of GitOps, which are declarative configuration, version control and immutable storage, automated delivery, software agents, and a closed-loop. The group will be working towards education initiatives and certification programs, but first, it plans on creating a “GitOps Manifesto” to further expand upon these basic principles, which it says it aims to have by March 2021.
Dan Garfield, chief technology evangelist at Codefresh, explained that he sees GitOps 2.0 as upstream to the GitOps Working Group, a sandbox of sorts where Codefresh can move more aggressively and attempt to fix what it sees as the limitations of current GitOps tooling, while the Working Group will be home to more tried and true, agreed-upon methods and ideas.
“The first one that we picked was visibility, traceability, observability. If you have 500 microservices, even if you’re using GitOps, it very quickly becomes difficult to understand what’s happening on a macro level. There is a big piece of worry that stops people from adopting it at that scale, because if they can’t tell what’s going on, their deployments start to feel like a black box. If something goes wrong, you’re lost,” said Garfield, “So, what we’re really trying to do with GitOps 2.0 is bring to bear all the information that we can to make sense of the GitOps experience.”
Garfield further explained the relationship between the initiatives as one of GitOps 2.0 looking toward these problems, while the GitOps Working Group brings together different players and vendors to agree upon a common foundation.
“GitOps 2.0 is a standard that Codefresh is putting out there, and the GitOps Working Group is a cross-collaboration between companies. We imagined that there’s going to be collaboration on GitOps 2.0 as well, but right now, we’ve kind of come out and said we think that there needs to be these pieces around observability. In order for this to scale, and there’s a number of scale things that we think need to be completed in order for GitOps 2.0 to really be robust enough to come downstream,” said Garfield, “Those are things that are part of GitOp’s journey in general. If we can’t scale it, if we can’t handle 5,000 microservices, then the standard would be dead.”
The second piece that Codefresh is looking to with GitOps 2.0, explained Garfield, is further handling scale in deployment.
“There has to be some sort of logical layer where, if I’m trying to roll out software at scale to hundreds of different locations and geographies, I need a way to decide how those rollouts are going to occur,” said Garfield. “The way that GitOps works today is you have one repo for each environment you want to deploy to, so if I have 500, does that mean I have to have 500 git repos that represent the state of all my deployments? Can I have a mono repo that has each of them defined separately? Or can I define it once and then define how the state should be applied across the board?”
This logic piece was being built using Argo CD, said Garfield, and will initially provide different deployment steps for pipelines that can trigger git synchronization based on pipeline logic, allowing “more advanced flows such as deploy, open PRs onto other infrastructure repos, or rollouts across different clusters and segments as well as automated testing of deployed versions with rollbacks,” according to a statement.
Looking ahead, Garfield said that he expects the introduction of GitOps 2.0 tooling to allow customers to handle a much greater scale than so far possible, but also to potentially move on to entirely different realms.
“We always let our customers guide us. We are working to actually expose these GitOps principles to things like serverless. Codefresh is a cloud native focused platform, not just a Kubernetes focused platform, and so a lot of our customers are also using serverless, so we think there’s an opportunity for us to bring the Git ops principles and flows to that standard,” said Garfield. “We think there’s, beyond potentially even Kubernetes and serverless, yet unexplored venues that could benefit from GitOps.”
The Cloud Native Computing Foundation, Codefresh and KubeCon+CloudNativeCon are sponsors of The New Stack.
Feature image by David Clode on Unsplash.
