Let’s start with a brief story:
There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.
And the lawyer says, “Well, you eat, don’t you?”
And the cadet says, “Yes, sir, three times a day!”
The meals for everyone aren’t served by the book because the canteen isn’t included.
This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.
Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.
Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.
A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.
You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.
I say: That’s not what DevOps is about.
DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.
The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:
In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)
If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.
As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:
Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.
— Arie De Geus
One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.
Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.
And everyone interested is welcome to sit down and enjoy what’s served.
Seriously. Join in. You do not need a manifesto to.
P.S. It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.
You should check out, in no particular order:
- The amazing (and amazingly modest) Patrick Debois
- The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
- The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
- Damon’s five-minute video on DevOps history
- John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
- Mary Poppendeick’s lean development work
- John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
- Ben Rockwood’s (@benr) comprehensive LISA11 keynote
- The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
- Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)
And works from folks including:
- Jeff Sussna (@jeffsussna)
- James Turnbull (@kartar)
- Adam Jacob
- John Vincent (@lusis)
- Bridget Kromhout
- Adrian Cockcroft
- Gareth Rushgrove
- Kris Buytaert
- J. Paul Reed
- Ernest Mueller
- James Wickett
- Ines Sombra
- Karthik Gaekwad
I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!
Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.
These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.
Also, if you get a chance to spend time at a DevOps Days anywhere, you should.
