No I won’t tell you what DevOps is. Tell me what you want to achieve instead
blog.chef.io
blog.chef.io
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."
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.
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"?
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.
...
> Data Economy published an editorial by our own Justin Arbuckle
...
> Justin urges us all to move past buzzwords
...
> As Justin
...
> Author Justin Arbuckle
Is tzs the only one who finds writing about oneself in third person a bit odd?