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".
The following bullet points encapsulate DevOps to me:
- Codifying infrastructure with tools such as Packer, Terraform, Ansible. The infrastructure should be just as auditable, repeatable, and transparent as the code.
- Empowering and allowing the engineers who write code to deploy it.
- Immutable servers/containers.
- A solid suite of monitoring and alerting tools that auto-heal (preferred) or at least notify when things go wrong.
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.
It's said that if you ask ten different people to define "DevOps" you will receive ten different answers. I would try to look past giving the word a formal definition.
i would not look to dictionaries as the arbiters of what is a word or not. they seem to me to be convenient references at best. they frequently leave out common technical jargon.
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.
Their definition of DevOps is encapsulated in the first two sentences of the article. In short, "Developers and IT Operations working together as a single team."
This is the original definition of DevOps, which was an outgrowth of the Agile movement. (Agile, of course, has a strong emphasis on cross-functional collaboration.)
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.
