A DevOps Manifesto
Motivation
Recently I have accomplished a training of Agile Software Development. One thing I really like is the Agile Manifesto. It use four short but powerful paired terms to express the value it promote concisely. Each paired term consists of a left value and a right value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
An idea just popped into my head: could I write a “DevOps Manifesto” in a similar way? That is, use paired terms to summarise the value DevOps promote.
I searched in Internet and found DevOps Manifesto by Jez Humble, a famous thought leader of the DevOps community. But the the subtitle of that page indicate it is still a note:
DevOps Manifesto
Notes on the open space session (no conclusions!)
(…)
Indeed, it already extracted the core value of DevOps. I believe only a few modifications to the language are needed to create a short and powerful DevOps Manifesto.
So I come up with this, in the hope of throwing out a minnow to catch a whale. It could also considered as an answer to a million dollar question: what is DevOps?
If you have any comments or suggestions, consider raise an issue in the GitHub repo I have created for this: https://github.com/hughluo/A-DevOps-Manifesto
DevOps want to break silos between Dev and Ops. Let us break silos between thought leaders and participants!
A DevOps Manifesto
We are uncovering better ways of developing and operating software by doing it and helping others do it. Through this work we have come to value:
- Cross-functional collaboration over organizational siloization
- Neutral measurements over anecdote-driven decision
- Gradual change over batched release
- Speeding recovery over preventing accidents
- Ruthless automation over comprehensive documentation
That is, while there is value in the items on the right, we value the items on the left more.
Origin
Cross-functional collaboration over organizational siloization
This paired value is directly from DevOps Manifesto from Jez Humble.
Neutral measurements over anecdote-driven decision
Measurement is also clearly a value should be in the manifesto.
I describe measurement with adjective “neutral”, inspired by Site Reliability Engineering from Google:
Our practice is then as follows:
(…)
The actual uptime is measured by a neutral third party: our monitoring system.
To find a proper right value is quite hard. I believe neutral measurements indicate data-driven decision making. So I searched “antonym data-driven” in Google and found this:
anecdote-driven
some organizations mindfully gather data and use it to make decisions. we often call these organizations “data-driven.” what about those that do not? what do we call them? if not with data, how do they make decisions? in my experience, they use anecdotes. managers make decisions based on discussions with or comments from 2–3 individuals. i call this “anecdote-driven,” and intend it as an antonym to “data-driven.”
I believe it is a good candidate for the right value. Since I don’t have other word in mind, I choose to use anecdote-driven decision as the right value.
Gradual change over batched release
The term “gradual change” comes from a subtitle in chapter How SRE Relates to DevOps in Site Reliability Engineering:
Change Should Be Gradual
The third key idea is that change is best when it is small and frequent.
(…)
— Site Reliability Engineering: Chapter 1- How SRE Relates to DevOps
Speeding recovery over preventing accidents
This comes directly from Site Reliability Engineering from Google:
(…) it is more profitable to focus on speeding recovery than preventing accidents.
— Site Reliability Engineering: Chapter 1- How SRE Relates to DevOps
Ruthless automation over comprehensive documentation
Automation should definitely has its place in the manifesto. Again, in DevOps Manifesto from Jez Humble I find a proper right value, documentation.
When I trying to find an adjective for automation, the name of a book Python for DevOps: Learn Ruthlessly Effective Automation come to my mind.
Reference
The Agile Manifesto, a short but powerful expression of the value of Agile, https://agilemanifesto.org/
DevOps Manifesto by Jez Humble, I burrowed almost all values there, https://sites.google.com/a/jezhumble.net/devops-manifesto/
Google SRE Books, another main source of paired values, https://sre.google/books/
DevOps Culture and Mindset, a course let me know more about DevOps, available in Coursera: https://www.coursera.org/learn/devops-culture-and-mindset
Agile Software Developer Nanodegree, a three month training I took for Agile, covering both theory and practice, available in Udacity: https://www.udacity.com/course/agile-software-development-nanodegree--nd144
