DevOps is a culture, not a role

DevOps, is a developer, that do admin stuff, because the development environment became more complex with the introduction of virtualization , cloud technologies and big data

Admins who do Dev work should be called OpsDev ...

A DevOps, is a Developer , someone who started as a developer and now do extra admin and systems work

Not the other way around ..

My official title is DevOps, but my coworkers know that I'm just the most cloud-oriented developer on the team. In that regard I also regularly push code into our products, with an insistence that I am not simply the guy that does AWS/Jenkins/Ansible work.

So, in one respect I entirely agree that DevOps is just another developer, at least the way I practice it. That being said, it's naive to think that DevOps isn't a specialization, or that everyone writing your code is going to be equally knowledgable on a product landscape as complex as AWS.

Ultimately where you fall on the spectrum of developer and ops is company specific, even project specific, and to try and make some generalizable dogma on the issue is a waste of time.

That is NoOps, but somewhat depends. You could have a developer who has a dedicated job of managing the infrastructure, but still doing some development work. Also don't forget the build engineer part for automating deploys. But if the responsibility is spread across the team, that is NoOps. It also tends to lead to a tragedy of the commons situation, because no one steps up to do the things that aren't fun.

I am a DevOps Engineer by trade and title.

Here is my take on this:

It is a role - not something that can be done by OPS or DEV or SEC or what have you.

Allow me to explain my 2 cents worth:

- With the amounts of tooling (CI/CD pipeline, infrastructure monitoring, infra. provisioning, config. management, etc.), you do not want your DEVs or your full-time admins focusing on this bit at-all. It is good if they have some know-how (or even if they do the initial groundwork) but if your DEVs or sys admins are focusing on what 'entails' as DevOps -- then Houston, we got a problem. Because this means that DEV or sys admin or what have you is not focusing 100% on their role.

- Why is 'DevOps' getting so much flak?? How about titles/roles such as 'scrum master' or 'Agile Practitioner' or 'Product Owner'?

- I am not a noob by any means (~10 yr IT experience) and I am past the stage of getting excited by a job title. However, the 'DevOps' title given to a 'DevOps' guy is a correct move. AND, believe-it-or-not, it is a IT specialization -- just like 'cloud' is. Just because everything is a code doesn't mean you don't need a dedicated person who will not only preach DevOps -- but will also 'implement' DevOps -- and that fella should be called 'DevOps' -- just like 'Agile Coach' ;-)

Agreed, it seems like a lot of people think about devops as a way to make dev's lives better without actively harming ops. The article does have a section on getting Ops on board with devops, but it's much weaker than the previous section on getting Dev on board. Devops done right should really improve both sides, as it explicitly recognizes the tradeoffs involved with the added automation / processes / policies. I've been reading Google's Site Reliability Engineering book ([1], free online, highly recommend so far) and it lays out pretty clearly how to do devops in a more balanced way. Key points are:

- Define service level indicators (SLIs), metrics you can track to see how you're doing on the things your users care about: uptime, latency, security, etc. For instance, measure uptime as successful responses / total requests.

- Define service level objectives (SLOs) based on your SLIs, e.g. 99.9% successful responses / total requests (aka 99.9% uptime)

- Establish an error budget which controls your deployments. Based on your SLOs you can accept a certain number of errors (failed requests, outages, slow response times, etc) for a given period. If you spend your entire error budget, no new code can be deployed. The deployment shutoff has to be agreed upon in advance and it has to be a hard and fast rule, so it's not ops' fault that dev can't deploy code.

- If you reach your error budget, devs need to work on things to reduce error rate going forward instead of developing new features. It can be tests, monitoring and alerting, rollback process, or pretty much anything, but devs should know that they're doing it so they can deploy more code faster in the future.

I think this makes a lot of sense and helps to align dev and ops on uptime goals. Specifically, dev's ability to push code is now directly tied to service level, and ops is not shooting for 100% reliability. Dev can choose how to spend the error budget, so ops isn't dictating how they do things; and ops knows and expects a certain number of problems, so they don't resent dev every time they push buggy code.

[1] https://landing.google.com/sre/book.html