Multiple people in this thread have asked "what is devops pragmatically." I will both try and answer why there is no clear answer to that, and what my clear answer would be.
1. Everyone has their own definition largely because everyone takes the bits of what they've heard of devops that they think are beneficial to them. I don't even think this is necessarily a bad thing (chose right tools for the job/culture, etc) but it certainly makes it difficult to centralize on a definition, compounded by...
2. That many of the people who want it only know, as sister posts have suggested and what the OP describes, what they want it to achieve, but don't necessarily have a clear roadmap to getting there beyond "devops".
3. So from that, what is my "pragmatic" definition (e.g. my "what happens in the real world" definition); pessimistically, "devs are now responsible for ops/sysadmin work as well, including on call, infrastructure and telemetry, but without any additional training, purview, or increase in pay."
Now, to make that criticism, I should propose a better definition; and this was hinted at by sister posts as well:
"Give devs the tools, expertise, and purview to accomplish ops tasks that previously were thrown over the wall. This does not mean GETTING RID OF ops domain experts, but unifying them with your devs to remove unnecessary separation, facilitate communication and needs fitting, and share expertise and skillsets where appropriate, since there are many ops tasks that benefit from a more engineering bent, and MANY eng tasks that benefit from an ops "I need to be able to run this understand it and fix it" mindset going in, as a first class citizen, rather than as an afterthought."
I'm a big fan of DevOps; for one reason or another, I've been in this 'space,' if you will long before it was DevOps...since about 2004/2005. If you ask me what DevOps is, this is the answer that I will always give:
It empowers the developers and developer teams to get up to speed quickly when writing new software, or when they add new team members to their teams,
It streamlines and optimizes the delivery of software within the service lifecycle, and
It changes and improves the relationships between development teams and IT operations by advocating better communication and collaboration between the two business units.
When done correctly, DevOps can help developers write better code, push to production faster, and be agile in their iterations and respond to the needs of both external as well as internal customers quicker.
> If you ask me what DevOps is, this is the answer that I will always give.
Nothing in your answer says what it is. It just tells things that doing/using it will allegedly accomplish/enable. Is anything that accomplishes all of those things considered to be "DevOps"?
Great, and I still have no idea what I'll actually be doing day to day. If I didn't know anything about it id think you were just trying to pretty up a pig of a job.
Unfortunately, while the assertion is probably true to not talk about jargon, there needs to be a starting point of conversation somewhere. Here, it's probably easier to define what devops definitely isn't and cut away irrelevant things than by talking about what anyone's jargon defines it as. This is similar to the whole "cloud" definition but only even more vague than that.
Be very wary of anyone that has trouble distinguishing "devops" from system administration with modernized toolsets, especially if they aren't talking about deploying in-house software. Those are the kinds of organizations that are so far behind technology curves they'll drag you down as a vendor, contractor, or employee trying to support them if you don't hold them at arm's length. Because if you're not competent at basic system administration, I doubt spending money on any form of "devops" by any definition will be useful - think of the "you must be this tall to use microservices" concept.
The worst is if there's something about culture that's the fundamental goal, the larger the company the more clients seem interested in essentially under-market-rate management consulting by using engineers than MBAs. These also tend to be the same companies that seem to incessantly talk about "it's hard to turn around an aircraft carrier" and have probably discouraged and disengaged employees enough that any form of bottom-up culture change is hampered before it can take off.
