Why Environments-as-a-Service is GitOps 2.0

It was around 10 years back in my interview with John Furrier at SiliconAngle, I mentioned the git effect. John appreciated the idea immediately and in fact, asked about it with another tech leader in a subsequent interview. None of us knew the massive scale of our foresight.

When Git was adopted by enterprises, it had some modifications to the purist vision of peer-2-peer network of trust which Linus Torvalds used to build Git upon. The biggest modification was the introduction of a central main repo. Since Git was all about decentralization and let the most trusted commit elevate, it initially sounded counterintuitive.

In open-source with developers donating their time, the cost of rejected commits was not significant. In an enterprise, every developer hour costs a lot of money so some process is needed to make sure there is no duplicate effort. There needed to be the most trusted repository which was pristine enough to be used for production deployments. In Linux, all the best changes made it to Linus’s repo which everyone else cloned. What could be done in an enterprise git to enable the same.

The era of Pull Request

While an enterprise does not have an unlimited supply of developers like in open-source, there needs to be a mechanism to vote on a change or commit. This is where the concept of Pull Request comes in.

A developer forks the main repository and commits appropriate changes. Now developer opens a pull request. Other developers look at the change from their own lens and if there are no objections, the pull request gets merged to the main repository.

GitOps

There are various definitions of GitOps depending upon where you look. The easiest place to look is within the term itself which is a portmanteau of Git and Operations. In other words, using the power of Git to help operations.

Operations start with setting up infrastructure which traditionally has been created manually and custom scripts like ansible/chef/puppet. There has also not been versioning associated with these infrastructure scripts. GitOps changes it by storing infrasctructure creation scripts in git.

Making the infrastructure operational is much more than storing it in a source code control system. According to GitLabs, GitOps consists of 3 parts:

1. Infrastructure as Code
2. Merge Requests (Pull Requests)
3. CI/CD

Wait! Am I dealing with source code or infrastructure code and where is Ops?

There are multiple moving parts here. The first question is what is actually going into a repository. we are going to cover all these parts in part 2 of this blog. coming soon….

This post was created with Typeshare