I agree with your overall point, but I also think there's a bit of conflation going on with the term "DevOps". It means different things to different people.
What I think is as close as we get to a canonical meaning is the meaning in which it is used by The State of DevOps reports, based on very good science and research by Nicole Forsgren et al.
They characterise "DevOps" as a transition into faster deployments, shorter feedback cycles, less warehousing of unexecuted code, and having developers have generally more insight into what's going on in the production environment.
This, of course, can (and arguably should) be done in cooperation with proper system administrators, network engineers, etc.
In other words, DevOps is not in opposition of having the right people people operate the systems.
In particular, it has nothing to do with cloudifying things. You can run a product with a DevOps approach right onto bare metal servers – in fact, there are a lot of companies doing that, for simple economical and reliability reasons.
I'm all for ranting against the cloud and the little experience people have when trying to operate systems, but blaming "DevOps" for it seems like a mischaracterisation. There's a lot of value to be had by getting more feedback from production, whether production means bare metal or virtualised environments.
As you say: DevOps means a million things to a million people. That’s why I ignored the person who tried to explain to me that I had the origin of DevOps wrong. Nobody alive or dead is qualified to make such a pronouncement, because nobody knows. It is an amorphous blob that usually manifests as a weapon for developers to beat the operations disciplines out of their company, which is why I speak about it as I do. Given the overwhelming evidence that the interpretation I’m going after is the popular one, arguing over the definition of the term is pointless.
You’re conflating my argument with cloud ranting and assuming DevOps methodology is the only method to acquire more feedback from production by stating your last paragraph like that. I’m saying there are potentially others, but we are entrenching on this way of doing things, and people picked this particular way of doing things and started talking organizations outside “SV” into it. That conversation gets harder a second, third, and fourth time. The prevalence of COBOL reqs should warn you of this, and what DevOps will look like in about a hundred years.
What I think is as close as we get to a canonical meaning is the meaning in which it is used by The State of DevOps reports, based on very good science and research by Nicole Forsgren et al.
They characterise "DevOps" as a transition into faster deployments, shorter feedback cycles, less warehousing of unexecuted code, and having developers have generally more insight into what's going on in the production environment.
This, of course, can (and arguably should) be done in cooperation with proper system administrators, network engineers, etc.
In other words, DevOps is not in opposition of having the right people people operate the systems.
In particular, it has nothing to do with cloudifying things. You can run a product with a DevOps approach right onto bare metal servers – in fact, there are a lot of companies doing that, for simple economical and reliability reasons.
I'm all for ranting against the cloud and the little experience people have when trying to operate systems, but blaming "DevOps" for it seems like a mischaracterisation. There's a lot of value to be had by getting more feedback from production, whether production means bare metal or virtualised environments.