I think this is why DevOps is becoming so popular. It's less about methodology.
There's no certificate, role, set of tools or prescriptive process. There's no specification, it's not a product, or job title. There's no one true voice on what DevOps is or isn't. It's about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It's a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It's a conversation. It's about taking the best experiences and sharing those with others.
The company I work at did this. The CTO and I even joked about it being "DevOps in name only". It's gotten better, but they're really still an ops team.
I mentioned to some people at my company that "devops" was meant to be more of a philosophy than a separate team and they were bewildered. But I guess I'm happier with ops being a separate team anyway.
Right? Ops, but an ops team you'd trust touching the code.
I feel like devops to most just means "ops but closer to the code now that there are so many code/release management tools and someone has to manage it all".
I've never met an ops guy that does anything resembling development other than ones that officially split duties as a developer and an ops guy. So I have no idea still ever devops actually is.
There's what it is, and what's practiced. DevOps is a culture change where operations and development work more closely with each other. There's more to it, but tying it to something practical: A shop that embraces the concept of DevOps is shortening the time between implementation, testing, and deployment and working towards the ideal of continuous deployment.
Consider Waterfall where development happens, then it's tossed over the wall to testing. Almost everyone acknowledges that this is a bad idea and so testing and development happens concurrently now, but not necessarily by the same people (can still have testers and developers). I guess DevTest doesn't have a good buzzword sound to it, but it's what we do.
DevOps sees the same issue with how developers finish the work, it gets tested, then it's tossed over to ops who don't really understand what the code does (not their fault, they didn't build it). DevOps brings the two groups closer together so ops still does ops, dev still does dev, but as a group they shorten the cycle so that dev can deal with the real issues faced by the operators instead of always lagging months and years behind. It's not necessarily an organizational change, the critical part is opening communication between the two groups.
In a way, it's an extension of agile (little-a, because I don't mean the shit the coaches sell), where the operators become the customer and development gets feedback from them. It's one of those "obvious" things that for some reason isn't very commonly practiced.
Now, that said, in practice it has issues. Management sees it like your comment and tries to make dev do ops or ops do dev, or mash them into one team (which may or may not work). More likely they try to make the devs do ops work and it's a disaster. It may run well, but features are added slowly. Or features are added, but the operations story is a nightmare. They end up understaffing the group (1 devop = 1 op + 1 dev, right?) and creating problems.
The original agile manifesto didn't have a certificate or set of tools either. There is plenty DevOps tooling, andI've little doubt that management types will hijack DevOps for their own gain and offer certifications. It'll probably be easy for them, since there is no single 'DevOps', everyone has their own idea of what it means to them.
In my experience devops more often than not is a codeword for lower prestige (and compensation) grunt work no one really wants to do but essential nonetheless. It is a good environment for camaraderie to develop.
ITIL is not really known outside of specifically IT at large, bureaucratic companies that look at operations as a cost center (even in tech companies, there’s some basic internal humdrum IT after all) and it’s probably where I’ve had my lowest professional compensation historically as an engineer that does infrastructure and operations at scale. A lot of these same places are basically going to fail at any interpretation of the term devops because change is so unbearably slow and because most of these organizations are in crisis mode as a business spending money to stay relevant as technology-first companies eat their lunch.
There's no certificate, role, set of tools or prescriptive process. There's no specification, it's not a product, or job title. There's no one true voice on what DevOps is or isn't. It's about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It's a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It's a conversation. It's about taking the best experiences and sharing those with others.