|
This article makes me...itchy. For background, I've been running SRE/infrastructure/"devops" teams for the last couple years, hung out my shingle as an independent consultant before that, and worked at a fairly large company as what we'd have called an SRE if the term had been a thing yet. And to me, feels like a lot of missing forests for trees. Elsewhere in the thread, 'somepig notes that this sounds like what a sysadmin does. I replied there because, just as you shouldn't call yourself a programmer[0], calling yourself a sysadmin is probably similarly mindset- and career-limiting, but I kind of have a bigger beef with calling this "consulting" than I do "devops". Of course this stuff is "devops", but--"properly" applied (and I scare-quote the word because you can call damned near anything "devops", up to and including "the development team hurls a tarball over the wall at some sysadmins in the basement and flees at top speed")--it's not consulting. It's a list of hands-on work. There's only a cursory nod to the most important part of any devops-facilitating role (whether it's called an SRE, an "infrastructure engineer", a "devops engineer", whatever): alignment of technical initiatives with business needs. I don't mean to be harsh in saying this, but if you're spending most of your time in the code mines grinding at this or that, you may not be a great "devops consultant". You might be a great infrastructure developer or SRE. But in my neck of the woods at least, clients hired me to make sure they were doing the right thing and to make sure that their employees were adequately prepared for the workflows they wanted to implement, not to do last-mile CI/CD computer touchery. (Which I'd do as well, of course, when time allows--but there's more value in being a multiplier than an adder, and at the rates I charged I'd better be the biggest multiplier I could.) [0] - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... |
This blog post really reflected my background, with most of the tech used being the same. However, most of the experience is by cleaning stuff up. I see stuff being used too many times that are not performant, effective or incorrectly configured due to people not taking care of said tech. Especially in the Javascript business. It is cleaning up tech debt that might not make cash in the short term, but many companies have it as a burden in one way of another and someone willingly to clean that mess up is very valueable, imho.