{"id":2441,"date":"2021-01-21T07:00:35","date_gmt":"2021-01-21T07:00:35","guid":{"rendered":"https:\/\/thenextweb.com\/?p=1334796"},"modified":"2021-01-21T07:00:35","modified_gmt":"2021-01-21T07:00:35","slug":"gitops-has-been-controversial-but-the-truth-is-your-organization-needs-it","status":"publish","type":"post","link":"https:\/\/www.londonchiropracter.com\/?p=2441","title":{"rendered":"GitOps has been \u2018controversial\u2019 \u2014 but the truth is your organization needs it"},"content":{"rendered":"\n
<\/div>\n

There\u2019s 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. <\/span><\/p>\n

We all know Git. It\u2019s the foundation of the modern software development workflow. But if you\u2019re merely using it as a tool to host and manage code, you\u2019re missing out on a huge opportunity to bring order and consistency to your infrastructure deployments. <\/span><\/p>\n

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. <\/span><\/p>\n

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\u2019s where all changes happen, and all changes are observable within the repository. <\/span><\/p>\n

Speed, collaboration, and consistency<\/span><\/h2>\n

Part of what makes GitOps so controversial is that it upends decades of accepted practice about how infrastructure should be managed. <\/span><\/p>\n

It takes tasks that would historically have been performed manually by someone with a job title like \u201csystems architect\u201d or \u201csysadmin,\u201d and atomizes them into a single shell script within a Git repo. And while those roles don\u2019t necessarily vanish, there\u2019s a legitimate question about why you should mess with something that\u2019s tried-and-tested. <\/span><\/p>\n

In my opinion \u2014 and experience \u2014 there are plenty<\/em> of reasons to get evangelical about GitOps. <\/span><\/p>\n

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\u2019t necessarily a unique advantage to GitOps; we\u2019ve had automated delivery for years now. <\/span><\/p>\n

You need to look beyond quantitative metrics, and think about how GitOps will improve the quality of your organization\u2019s work.<\/span><\/p>\n

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.<\/span><\/p>\n

But that\u2019s 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. <\/span><\/p>\n

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. <\/span><\/p>\n

It\u2019s 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. <\/span><\/p>\n

What GitOps isn\u2019t <\/span><\/h2>\n

It\u2019s 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\u2019s an approach centered around a tool, but not actually a singular tool itself. <\/span><\/p>\n

Vanilla Git will only take you so far when it comes to building a GitOps workflow. To reach the promised land, you\u2019re forced to rely on third-party tools, or tools of your own internal creation. <\/span><\/p>\n

Take, for example, secrets management. It\u2019s rightfully considered bad practice to store passwords and private keys within your repository \u2014 as anyone who has ever accidentally pushed their AWS credentials to a public repository knows. It just isn\u2019t secure. <\/span><\/p>\n

Right now, there\u2019s 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\u2019s hardly an insurmountable problem. <\/span><\/p>\n

Another common criticism claims GitOps workflows lack any real kind of input validation; which is to say, if you put garbage in, you\u2019ll get garbage out. <\/span><\/p>\n

That\u2019s true, but also missing the point somewhat. By relying on Git as your \u201csingle source of truth,\u201d you\u2019re in a position where you can mitigate against the kind of errors that cause downtime and disruption. <\/span><\/p>\n

New configurations can be tested in separate branches, before they\u2019re 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. <\/span><\/p>\n

Another complaint says GitOps is overly centralized. That\u2019s a fair cop; by its nature, Git relies on decision-makers to determine what commits get merged, and what don\u2019t. This isn\u2019t a vice, but rather a virtue. If you\u2019re relying on having a \u201csingle source of truth\u201d for your infrastructure, you\u2019ll want someone in charge of things <\/span><\/p>\n

Think first, code later<\/span><\/h2>\n

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. <\/span><\/p>\n

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\u2019ll swiftly notice things become more consistent and error-tolerant. <\/span><\/p>\n

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\u2019re implemented on a technical level. And the universal familiarity of Git itself means it\u2019s not hard to hit the ground running.<\/span><\/p>\n

In short, GitOps will allow your team to work faster, and with greater precision and consistency. So, what are you waiting for? <\/span><\/p>\n

Published January 21, 2021 \u2014 07:00 UTC <\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

There\u2019s 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…<\/p>\n","protected":false},"author":1,"featured_media":2442,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/2441"}],"collection":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2441"}],"version-history":[{"count":0,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/2441\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/media\/2442"}],"wp:attachment":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2441"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2441"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2441"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}