by Theres a popular (and, not that it matters, wholly untrue) myth that says we only ever use 10% of our brains, with the rest locked away as untapped potential. Sometimes I think Git is a bit like that.
We all know Git. Its the foundation of the modern software development workflow. But if youre merely using it as a tool to host and manage code, youre missing out on a huge opportunity to bring order and consistency to your infrastructure deployments.
GitOps unleashes that other 90%. At its core, this approach sees Git placed at the heart of how an organization manages and deploys its infrastructure footprint.
New containers and virtual servers are defined not with step-by-step instructions, but rather as lines of code within a repository, and then actioned within. While implementations vary, the core philosophical tenets are fairly constant: Git is the single source of truth, its where all changes happen, and all changes are observable within the repository.
Speed, collaboration, and consistency
Part of what makes GitOps so controversial is that it upends decades of accepted practice about how infrastructure should be managed.
It takes tasks that would historically have been performed manually by someone with a job title like systems architect or sysadmin, and atomizes them into a single shell script within a Git repo. And while those roles dont necessarily vanish, theres a legitimate question about why you should mess with something thats tried-and-tested.
In my opinion and experience there are plenty of reasons to get evangelical about GitOps.
One of the most oft-quoted arguments points out that GitOps is inherently fast. Since Git is the place where changes happen, it becomes possible to spawn or decommission elements of your infrastructure with a simple push notification. But this isnt necessarily a unique advantage to GitOps; weve had automated delivery for years now.
You need to look beyond quantitative metrics, and think about how GitOps will improve the quality of your organizations work.
GitOps requires all system infrastructure to be described declaratively. Like Plato in his cave, you know what the ideal form of a container is, and how to make it. The definition sits in a repository, surrounded by a flock of automated procedures responsible for deployment and integration. From the outset, a huge chunk of the scope for human error is excised.
But thats only part of it. Remember: GitOps is centered around a version control system, and as a result, you can take advantage of the features that made Git so popular with developers.
Make a mistake in one of your configurations? Just roll back to the last working version and redeploy. Spotted some anomalous behavior in a container? Look at the code and see what changed between the current version and the last known working version. Git gives you an audit trail so you can identify where the problem cropped up and swiftly take action.
Its also worth noting that Git is, by design, inherently collaborative. This is true on a lateral level (colleagues working together on a definition or deployment workflow), as well as on a hierarchal level, allowing senior members of the team to sanity-check and sign off on all new changes.
What GitOps isnt
Its fair to say that GitOps has its share of detractors. Part of that stems from a fundamental misunderstanding of what it actually is; which is to say that its an approach centered around a tool, but not actually a singular tool itself.
Vanilla Git will only take you so far when it comes to building a GitOps workflow. To reach the promised land, youre forced to rely on third-party tools, or tools of your own internal creation.
Take, for example, secrets management. Its rightfully considered bad practice to store passwords and private keys within your repository as anyone who has ever accidentally pushed their AWS credentials to a public repository knows. It just isnt secure.
Right now, theres no way to natively inject these secrets into a deployment from within Git. They need to be handled via a separate workflow, either as an extension to Git, or something distinct entirely. That results in extra work, but its hardly an insurmountable problem.
Another common criticism claims GitOps workflows lack any real kind of input validation; which is to say, if you put garbage in, youll get garbage out.
Thats true, but also missing the point somewhat. By relying on Git as your single source of truth, youre in a position where you can mitigate against the kind of errors that cause downtime and disruption.
New configurations can be tested in separate branches, before theyre ultimately merged into the main version. Mistakes can be rolled-back. And you can contrast different versions of the same configuration to identify where problems crop up.
Another complaint says GitOps is overly centralized. Thats a fair cop; by its nature, Git relies on decision-makers to determine what commits get merged, and what dont. This isnt a vice, but rather a virtue. If youre relying on having a single source of truth for your infrastructure, youll want someone in charge of things
Think first, code later
By its very nature, GitOps prompts teams not just to think about how their infrastructure should work in practice, but also how they plan to work going forward. Transparency gets pushed front-and-center, with all changes and deployments going through a single, central hub, where a record is stored for all perpetuity.
Practical matters follow closely behind. Eventually, you build your stack around your own needs: from deployment and auditing to secrets management. As your operations become codified around a repository and a set of well-established procedures, youll swiftly notice things become more consistent and error-tolerant.
Automation in this space is nothing new. But GitOps formalizes every level of how your infrastructure works, both on a core level (how containers and servers are conceptualized) to how theyre implemented on a technical level. And the universal familiarity of Git itself means its not hard to hit the ground running.
In short, GitOps will allow your team to work faster, and with greater precision and consistency. So, what are you waiting for?
Published January 21, 2021 — 07:00 UTC
