There’s 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. It’s the foundation of the modern software development workflow. But if you’re merely using it as a tool to host and manage code, you’re 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, it’s where all changes happen, and all changes are observable within the repository.
Speed, collaboration, and consistency
The 💜 of EU tech
The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!
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 don’t necessarily vanish, there’s a legitimate question about why you should mess with something that’s 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 isn’t necessarily a unique advantage to GitOps; we’ve had automated delivery for years now.
You need to look beyond quantitative metrics, and think about how GitOps will improve the quality of your organization’s 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 that’s 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.
It’s 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 isn’t
It’s 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 it’s 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, you’re forced to rely on third-party tools, or tools of your own internal creation.
Take, for example, secrets management. It’s 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 isn’t secure.
Right now, there’s 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 it’s 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, you’ll get garbage out.
That’s true, but also missing the point somewhat. By relying on Git as your “single source of truth,” you’re 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 they’re 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. That’s a fair cop; by its nature, Git relies on decision-makers to determine what commits get merged, and what don’t. This isn’t a vice, but rather a virtue. If you’re relying on having a “single source of truth” for your infrastructure, you’ll 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, you’ll 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 they’re implemented on a technical level. And the universal familiarity of Git itself means it’s 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?
Get the TNW newsletter
Get the most important tech news in your inbox each week.