What I Do as a DevOps Consultant

certainly won't disagree that it can be limiting to folks of some perspectives, but as someone who publicly has applied the sysadmin label for the duration of their career (starting in the early 00's), I've yet to see a downside.

I've been obscenely compensated for working on interesting projects for much of my career. then again, part of it may be due to the confidence that comes with focusing on my work instead of fluffing my title.

One DevOps please.

"DevOps" used to be a methodology where a Dev and an Ops share a same goal of delivering value into production, at least, that's in the book I have read.

A sort of extension of the Lean System where workers from different areas share a common goal of delivering value to the final customer (in production), the same card may require a backend dev, frontend dev, and an ops to share the goal to take this card from idea to production, and then monitoring how it behaves in production.

For people who have not read the same books, "DevOps" mean things like "applying dev method in the operation field" ie. with ansible and the likes, coding the infra. After all, that's what that word seems to mean at first glance.

This reminds me of the term full-stack, some people consider it's just about being good at both frontend and backend, in my opinion a good full-stack is also a good networking engineer as well as good at customer acquisition.

For best ROI:

- integration must be automated and continuous

- delivery must be automated and continuous

- tech debt includes untested code and being late in dependency versions

- the above should be treated as impediments

The purpose of "DevOps" being to deliver faster from idea to production, it does necessarily include a toolchain of CI/CD/IaaS & monitoring tools. From this "DevOps toolchain", taylorists opened positions for developers that can maintain it around a software, they called that position "DevOps", which explains how we got there on having different meanings for the same word.

I highly recommend "Continuous Delivery & DevOps: QuickStart" by Paul Swartout for a first quick read on the matter.

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...

You also, candidly, may be experienced enough and have enough time-served to get away with it. ;) There's definitely an effect--I kinda want to call it a thermocline?--above which your actual achievements can speak for themselves, particularly if you've built a solid network.

Today, if I had a notion to, I could probably call myself a "sysadmin" and not have trouble finding well-compensated work. But when I was freelancing, as well as when I was earlier in my career, I can tell you a lot of doors would have slammed right shut had I used the term regardless of my capacity. I do not particularly love the term "devops", but at this point its umbrella at least encompasses what we (like, you and I, not the general we) think about when we're doing this stuff, and it has a certain amount of loaned--or stolen--credibility.

As I said in a top-level comment, I'm more twitchy at this description of being a consultant than I am at the devops part.