What is GitOps? This is the technical introduction you've been looking for It’s not hard to form the impression that building and deploying cloud native systems is rapidly becoming a solved problem, with GitOps providing the roadmap. The approach revolves around the idea of configuration-as-code: making all configuration state declarative (e.g., specified in Helm Charts and Terraform Templates); …
Well, of course it does. Just not for you. it simplifies the red tape the supplier needs to cut through to screw you over. It certainly simplifies the negotiation process when you have terabytes of data on "their" cloud solution and they decide to up the price. Particularly when you start to add up the exit fees.
All in all the suppliers find things much simpler when you're in the cloud
Yeah, but when you want to actually talk to someone it is either a phone call[1] or you can chat online[2]. Then again, if you are the company your stats will be great. 'No, boss, no problems. We don't have many customers using our phone/chat systems, so it must be good. I suppose that means we don't need to introduce some new-fangled system like email or secure messaging. What's the point when no one complains?'
Or am I being too cynical?
[1] Your call is important to us, but because of covid you will have to wait hours to talk to Burt, the janitor, about that asynchronous socket duplication timing issue.
[2] See [1], but this time with the tiniest data entry window you could get, but you still need to wait. Oh, and if you bugger off to another tab we'll time you out.
You should see my deploy scripts. I think it took me about 2 weeks to write ALL of them. I think every generation of devops systems gets more complex and the documentation gets worse. Kubernetes requires you make packages to deploy your images you already made and configure all the inputs and outputs manually. It's great functionality, but it takes forever to set up.
This is well past ridiculous. How many more *Ops marketing terms are people going to invent for every damn thing?
I suppose I should at least take solace in the fact that somebody finally realized that developers coding applications are NOT qualified to create the deployment environment. The whole DevOps bruhaha is a security nightmare for exactly that reason.
Upvoted. I am getting ever more fed up with the way they try to spin systems administration into some funky new bullshit non term. configuration management, deployment management and all those things have always been part of our job. There are some new tools now which even make some of it easier (when used sensibly). It is still sysadmin though. We have also always had to work with the developers so that their code is deployed as it should be.
</rant>
One thing I've learned about IT over 30-40 years, the new ideas are often great, they encourage people to advance and try new things.
However the problem comes when a bunch of muppets decide to do something chapter and verse by rote. They don't understand any of the idea's subtleties they don't consider where it's being fitted, they just ram it into place and then stand back and wonder why it won't work!
Configs in repos triggering deployments, sounds fantastic! I love it! However it's not for everyone, not for every situation and certainly will not work in every project. Take the ideas, draw the best aspects, get some resonably smart people together to draw up something small and workable, adapt the ideas and you'll probably find something usable from the testing wreckage that will actually work in production.
It used to be every application was at heart a database and a GUI. Some time ago we evolved past that, to where every application is a no-sql key-value store and a web page (which only works in Chrome). But git will be so much better. With the RBAC piece solved, we can just save the data in git as well. Code, configuration, and data, all in one tidy location. (It will still only work in Chrome.)
I have to say that this hasn't helped. WTF is <i>configuration-as-code</i> ? Could you please explain more simply for bears of little brain such as I am ...
... oh no: I'm losing the will to live now .. I can feel my live forces drifting away. And you're responsible, El Reg. I hope you can live with yourselves ... aaargh!
1) DevOps was NEVER about eliminating the distinction between devs and operations. NEVER. It was about relieving the explosion of operational load that was triggered by the move from waterfall to Agile. That mostly involved a lot of education of the devs as to what actually happened after they "threw it over the wall." In particular, defining "MVP" to include a hard requirement that it not force the ops guys out of bed every other night to fix what just broke.
2) Single source of truth was NEVER about a single source of all truth, but of any particular truth. If, as this article seems to imply, the ultimate source of truth is external to your systems, that does not change anything other than the particulars about how the updates occur.
3) Access control within a repo is a solved problem--with Perforce at Google, at least. I'm pretty sure IBM had it solved decades earlier with whatever system they were using. Git doesn't directly support access control at all, but layering it is isn't really that big of a deal. Not that Github supports it.
4) The distinction between desired state and actual state isn't really as hard to get as the article implies. In order for processes to be meaningful, they need to be expressed a datapoints in the same space. In order for the processes to be successful, you need to have a clear method to conform the later to the former. There is nothing new here, but lots of folks do get this wrong, somehow.
And finally:
If you cannot reduce your entire desired state to a series of bits in some dataspace, then you don't really understand your desired state. Once so realized, it becomes natural to take those bits and manipulate them as bits rather than the things those bits represent. GitOps is nothing more and nothing less than a exploitation of these facts.
> 1) DevOps was NEVER about eliminating the distinction between devs and operations. NEVER. It was about relieving the explosion of operational load that was triggered by the move from waterfall to Agile. That mostly involved a lot of education of the devs as to what actually happened after they "threw it over the wall."
That may be the somewhat idealized version of what DevOps is.
In reality, in many companies, the "devops" idea came about as a backlash to Corp IT Dilbert-style bureaucrat (roadblock) admins, rather than "figure it out and get it done" sysadmins who can work with developers. The former is more common than the latter.
So in response management tries is make it 1 job with 1 headcount, and the person they hire might be good at one part or the other, but not both, so half the duty suffers as a result. The big wheels and beancounters love it, because they think they're getting a 2-for-1 great deal, of course.
Never underestimate the ability of corporations to take a possibly good idea and twist it into something stupid and eventually broken.
This post has been deleted by its author
> "As others have pointed out, GitOps isn’t a silver bullet. In our experience, there are at least three considerations that lead us to this conclusion. All hinge on the question of whether all state needed to operate a cloud native system can be managed entirely with a repository-based mechanism."
In other words, using Git is a hack which was available and was close enough because it has some versioning (branches) and also internet access. But what is really needed is something with more features - as described in this overview. E.g., the branches need to be layered, and the relation between the branches need more structure, and actually git might not be the best back end for that anyway.
"GitOps" then is a -terrible name- to describe what is needed. How about "AgileOps"?, since it has be be trending and memorable. Git out here with the 'Git'!
Git, however, is well suited to software development, for which is was originally created. Although sometimes it gives me a headache, it always turns out in the end that I was wrong and Git was right.
Git is the lowest rung on the ladder when it comes to version control. The fact it has become so prevalent is depressing beyond belief.
Just this morning I discovered half of one of my commits had been lost due to some weird quirk somewhere. (Obviously something I did, but the fact that I was allowed to do it in the first place speaks volumes. And, of course, I'll never know what it was I did, so it'll probably happen again at some point in the future.)
I used to admin several groups using a Git server called gitolite. The tool itself fetched its config from a repo so if you wanted to administer the thing, e.g. to add a user or create a new repo, you edited a file that you checked in and it happened like magic. Kind of cool and meant you have a change history if you ever wanted to revert something. Unfortunately Gitolite itself had some pretty gnarly rights rules which were a pain to edit in a text file but that's a different issue.
Standard working practice in most companies.
Unfortunately, new shiny tooling isn't the way to a relaxing life.
You can throw all the top-end tooling that comes along into fixing the issues, but if the underlying company process/culture isn't there..... you get the following flow to the new world....
SHIT --> REWORK --> NEW SHINY SHIT
You can't polish a turd....
It's obvious from the comments that The Register attracts the BOFH type 'administrator' rather than the modern, cloud native developer or engineer. An epic trove of cognitive and confirmation biases ahoy, "I've done this for years therefore I'm right and this is wrong!"
The market always wins and GitOps is winning the market.
We saw the same debate of DevOps. I feel sorry for anyone who's still trying to correct people on 'what DevOps is', while in the interim they could have actually been applying DevOps methods or processes or culture or whatever bow you want to tie it in. The same is now with GitOps.
Kelsey Hightower, AWS, Azure, and a large % of high performing and scalable companies have embraced GitOps. Personally speaking, it has been the silver bullet and fastest way to scale teams in a repeatable, dev experience focused way whilst ensuring automation, resilience, HA, mean time to recover and repair, has been made so easy by just doing things in an expected way. It's easy and it's powerful.
I would highly recommend that the keyboard warriors in the comments spend half a day to bring up an entire stack in both a local dev, local remote (cluster) and production state in full parity across multiple environments their way and then via GitOps ;)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
