Whenever I see articles about DevOps, I find myself wondering what exactly it is. It seems to mean different things to different people. Without any definitions in this article, I find it hard to understand what they mean by "Dev", "Ops", and "DevOps".
That's not it. Those are all things your normal (non-devops) ops teams do. Ops teams run the gamut from "I can barely install an rpm, we have dedicated people to configure postfix", to teams that write their own batch scheduling systems. At the high end, we call these teams SREs. At the low end, tier-1 helpdesk.
Devops is when those things cross over into normal developer work. The developers take on these "ops" duties themselves. It may or may not involve actual development. It always involves devs having to understand the infrastructure their code runs on.
Done right, it's a good thing. It makes devs sensitive to how their code is deployed and run in production, without being able to blame some other team for the application not performing well, not having adequate availability, etc.
I feel DevOps is similar to Agile. It defines a set of principles from which an organization can derive and implement practices that are most appropriate for them. Once enough organizations implement such practices, it leads to some industry wide best practices and some organization specific practices and that is totally fine in my opinion.
Devops is a way of organizing teams such that developers, qa, and operations involved in a particular product are all working on the same (usually fairly small) team, using the same work backlog, usually using some kind of agile methodology like scrum. You could have people specialized on the team for those tasks, but generally people on devops teams are expected to work any issues that come in so developers will be deploying servers or writing tests and operations people might add features to the app, etc.
Devops as most people use it also refers to a suite of technologies used by teams organized that way as well as engineers who specialized in that set of tools. Jenkins, aws, containers, chef, etc.
People might also use it to describe common deployment patterns that devops teams use like ci/cd and infrastructure as code.
For us (Truecar) we define it as the developers that work on our orchestration platform (Spacepods). So, we have an entire CI/CD pipleline now and our devops (developers) work on our orchestrator and networking. Our entire infrastructure is represented in code (Spacepods, terraform, docker,ECS,lambda, nginx, Postgres setup, ES setup etc) and our devops employees work on those tools.
At AWS there is rarely a distinction between dev and ops. Developers manage their service and join the oncall rotation for their own team. We also write all our own tests and manage deployments ourselves (albeit with the help of other AWS teams who maintain test frameworks and deployment tools.)
This seems a lot cleaner than the alternative. Sure the devs have greater responsibility, but there's no dev/ops disconnect here.