Introduction to GitOps

[00:00:00]
>> All right, so Introduction to GitOps, what is GitOps even mean? Before I even go into it, can anyone maybe guess what GitOps means?
>> Automation of operations through version control.
>> Automation of operations through version control. Yeah, it sounds like you might have known it was. [LAUGH] Vietnam kidding, yeah, that's pretty accurate.

[00:00:22]
Again we asked another quote from AI and it said, if you don't know what you did you can't do it again, that's its description of GitOps. It's actually a pretty good description [LAUGH], and I really liked it so I just kept it. But what is GitOps again as defined by AI better?

[00:00:39]
GitOps is a paradigm or a set of practices that emphasizes using Git as a single source of truth for the declarative infrastructure and applications. All right, so as I mentioned down at the bottom, pretty much GitOps is a way to manage infrastructure and applications using Git, that's it.

[00:00:54]
So if you've ever used Git before, GitOps is commit, push, all that kind of fun stuff. So what can GitOps provide? So I'm not using GitOps right now, why should I care, right? Well, starters it gives you infrastructure as code. Does anyone here not use infrastructures code right now their companies like clicking moving things around?

[00:01:18]
Okay, yeah, okay, no worries, no worries. So I think with that kinda situation, the biggest challenge is culture, right? How do we move to this when we're so used to this, right? That is something I think is important to break, because when you have infrastructure as code It works the same way like your applications do, right?

[00:01:45]
You have a trackable history, you have the ability of approving and denying things basically just stepping into the IaC infrastructures code world, immediately standardizes how you do everything else to the way you do that, right? So you get automated deployments. Why do you get automated deployments? Because we already do automated deployments with services, right?

[00:02:08]
So it's the same principle, it's just running in a different pipeline, right? Reproducibility and rollbacks. So I'm sure quite often or sometimes you've even dealt with this where you've had to roll something back, and then you've been, boy [LAUGH], how do I do this, right? Well, with Git, you can literally just say, here's the commit, go back to that.

[00:02:31]
And that can be really helpful. How do you make it so that people care about that? Because that's the important part. If we're not using it, how do you make people care about that? Exemplify the problems that they've dealt with and show them how GitOps can solve it.

[00:02:48]
>> Do it by hand a few times
>> Sure, yeah POC it if you need to, but the main point is is like you might have to do some convincing, but if you can show people how it solves the problems it gives that more value. And then yeah enhance collaboration as well, right, when you're clicking around in a console and things like that it's just you, you know what I mean, unless somebody's sitting next to you.

[00:03:11]
It's not I can pull a co-worker over and be, can you review my clicked changes that I just did? But in a GitOps approach, you can actually say, here's the PR, here's the changes, please review them, please tell me what you think, excuse me. And a lot of software engineering is just about good collaboration, that's it.

[00:03:35]
Just really good collaboration and working together. So if you do not know what infrastructure as code is or IaC, infrastructure and application configurations are stored in a repository and versioned for complete history, this allows for changes to be tracked and reviewed, as I just mentioned. Those two words, tracking and reviewing, are crucial to scaling any enterprise organization.

[00:04:07]
If you cannot track and review every change you make, then I guarantee you there are changes being made underneath you that you do not know about. And they could also do what is the most worrying part, exploits vulnerabilities, things forgotten, right, all that kinda stuff. So trackability and reviewing is crucial when you are talking 100, 50 people, whatever, making changes, passing those changes along, and stuff like that.

[00:04:39]
So automated deployments with GitOps, this is very similar to how automated deployments work with your services. This is one of the reasons why it makes it so nice because you already know if you've already solved the problem of a pipeline and GitHub or Git, whatever, it's just the same thing, you're just using a different tool.

[00:04:56]
They're potentially different credentials and stuff like that. But it ensures that the live environment matches the repo state. Now there's a term for this and it's called reconciliation. The concept is that when you make a change, the service at some point, so it should somehow reconcile itself to that.

[00:05:16]
And do you do that? No, it's automatic, right? All you do is, again, you hit the boat, let it float out into the ocean, right? So deploying quickly and reliably is crucial to scaling. If you have an hour deployment times, you're not gonna be able to scale well, you're just not, what happens when you need to revert?

[00:05:40]
Does that mean that your revert takes an hour as well, right? These are the kind of things that GitOps can help with moving faster. With reproducibility and rollbacks, since all the changes are tracked in Git, it's easy to roll back and roll forward. You can even do tagging, where you can say, our infrastructure was tagged at this, V1, this is what it is, okay?

[00:06:00]
Now if you choose here, okay, we patched it so forth and so on. And because of this, you can revert and recreate things really quickly. And this is another crucial thing to trying to scale is if you can't save, save an outage happens or a cluster goes down or something like that.

[00:06:18]
And if you can't get that back in a reasonable amount of time you are, forced to make an announcement and a maintenance. You have to tell your audience at that point, because here's what happens, if you don't, and all of your services go down and you do not update them, everybody's gonna do the same thing that you do with every other company.

[00:06:35]
This company sucks they don't tell us anything, forget that. That's the other part of the responsibility, is if you don't have good revert and rollback, you're gonna have to set those expectations properly, otherwise, it could hurt you in other places as well. Then yeah, the enhanced collaboration part, especially if you're on a small team of five people, it's really hard to collaborate, and I get that, right?

[00:07:02]
If you are a one-man owner, I get that. And you might be like, Well, hey, why should I go through all this PR review process and stuff like that if I'm just one person because you're a person, [LAUGH] that's why because you're human. And you will probably make a mistake at some point that if you do not review your own changes you will probably miss and forget.

[00:07:22]
So whether the collaboration is for you and other people, or just you and you [LAUGH], it does help for changes to be made basically by anyone in the organization with proper permissions and being able to properly validate that. I can go into any repo I want and make a change, but it won't get merged until an approver on that repo goes in and says, okay, cool, lemme approve your PR and then it can get merged.

[00:07:49]
So empowering individuals to contribute is crucial to scaling, especially in the circumstances of fires. If somebody can hop on, even if a developer can hop in and make a quick change, it's very helpful when you've got your hands tied. Yeah, go ahead.
>> So enhance collaboration is not just like interpersonal, but also intertemporal with future and past you.

[00:08:09]
>> Absolutely, yeah, I mean it' sounds weird to say but you're just building guard so you don't hurt yourself later. And going back to that earlier one where I said I block main on my own branches that's why. Is because I could merge something without thinking about it go to bed wake up the next day and then everything's down and I'm like gosh.

[00:08:32]
So yes it's more work but is it really besides sleep that you want, [LAUGH], so that's the other part of it. So, the TLDR for GitOps is essentially with GitOps, if you wanna know the current state of your system or how it looks, you just look in the Git repo.

[00:08:49]
And the TLDR of the TLDR of that [LAUGH] is if you wanna change the system, you change the repo. That's it, that is GitOps. If you wanna change the system, you change the repo. Really nothing else outside of that.