It’s more or less a logical following of infrastructure as code, because it’s the developers who write and push those files.
Devops is/was a professional movement to get developers and operations folks to communicate with one another, create a shared value system and culture, drive continuous learning, enhance automation, visibility/metrics, so we can all build software faster safely and sustainably.
Infrastructure as code was one small aspect of this. Continuous delivery, microservices, cloud native platforms, a sharing/collaborative culture, lean product development, modern alerting/monitoring, all were part of this.
But it seems tech pop culture cliche's win out over best intentions again and again, as they did with 'agile', 'cloud', 'structured programming', 'object oriented programming', 'reactive', and 'REST'
a) The term is misappropriated to refer to some something rather different from what it was originally meant to refer to. I may be guilty of doing that.
b) The concept was too fluffy to begin with and sparked a cottage industry for consultants without helping anyone else.
c) The original ideas were flawed and have so many unintended consequences in practice that people rightly start associating the term with those negative outcomes instead of the well meaning goals.
Perhaps a bit of all the above is what's causing the dissonance here.
b) Consultants (good and bad) always sprout up in any area, and have throughout history (see: Sophists vs. Charlatans).
But, what is "fluffy" (ill-defined, nebulous, uncertain, difficult) to one person is a deep area of research for another.
Put another way, people tend to dismiss what they don't understand or can't see as unimportant. This is the "looking for your lost keys under the street lamp" syndrome. Most often people can only understand the future in terms of the past, and if they don't have past exposure to a topic, they're not going to see its relevance unless they put extraordinary effort in to pay attention.
For example (not necessarily directed at you), Devops folks really put a lot of emphasis on Lean concepts that come out of the Toyota production system. But if I think "wtf do I care about making cars?", I might think ideas like "Continuous Flow" or "Cost of Delay" as being fuzzy and irrelevant to my work as a developer. But they have huge impact over how work is organized and made productive, and literally billions of dollars have been spent developing and honing these ideas in the product manufacturing industries... that just might have broader relevance to the dysfunction of how traditional enterprises run their IT shops vs. how Amazon does.
As for c), all ideas are flawed and have unintended consequences :) , focusing too deeply on the negative is a cynical reaction that often gets back to (b).
And I don't see DevOps becoming obsolete at all; just the other day I spend deploying apps with an ops guy, where neither of us could do it all on his own: the ops guy lacked understanding of the code bases, the endpoints to configure, and integration test procedures, me not having permissions to redeploy and view logs.
Yes, that means infrastructure as code, including code reviews, frequent deployments, etc.
No, it doesn't require that the developers working on the devops code are the same ones who work on the app code. At a small company (e.g., three devs) they will be, but at a large company, you have a dedicated "devops team" who exclusively works on infrastructure (as code).
Sincerely,
DevOps guy formerly known as SysEngineer formerly known as SysAdmin for 15+ years.
Sincerly,
Platform Engineer former DevOps guy, former SysEngineer, former SysAdmin for the past 24 years.