Devops is one of those volatile topics that mixes human behavior patterns with technology, often yielding dramatic increases in productive output -- that is, more high-quality software at a much faster pace. It's a fascinating area. But is devops fascinating enough for a novel?
Gene Kim guessed that it was. His book, “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win,” written with Kevin Behr, actually became a best-seller, with Tim O’Reilly and Red Hat CEO Jim Whitehurst calling it a must-read and legendary cloud architect Adrian Cockcroft dubbing it “the IT swamp-draining manual for anyone who is neck deep in alligators.”
Before his novel, Kim was best known as the founder and CTO of Tripwire, a creator of security and compliance automation software that was sold to Belden early last year. Over the past five years, he's built himself into one of the industry's foremost experts on devops, working with Jez Humble, Dr. Nicole Forsgren, and the team at Puppet Labs to produce the annual, influential State of DevOps Report.
I caught up with Kim when he spoke at last week's Merge 2016 conference held by Perforce, which provides secure version control software to developers. What follows is an edited version of the interview, including the surprising revelation that one practice above all ensures greater devops productivity than any other:
InfoWorld: Why write a novel about devops, of all things?
Kim: The short answer is that I read this amazing book called "The Goal." It's a famous book written in the 1980s by Dr. Eliyahu Goldratt [and Jeff Cox], and it's integrated into just about every MBA curriculum. When I read it 17 years ago, it blew my mind. For a decade we wanted to write "The Goal," but for our context. In 2010 I left Tripwire and was able to work on it full time for three years.
It's been so fun. The thing that delights me most is when people say, "I read the book and it sounds like you were taking about us."
InfoWorld: What are some of the specific issues in devops that led you to believe that fiction would be a good way of addressing them?
Kim: One of the design goals of the book was to be able to say that whether you're in dev, test, operations, or infosec, this affects you. The inability of those functional groups to work together and reach common goals led to horrendous outcomes for each one of those stakeholders and ultimately the organization.
What I love is that in many organizations the book is actually required reading for the executive staff.
InfoWorld: At first, devops was about dev and ops getting along. But dev and ops can never really get along -- there's too much of a cultural difference, don't you think?
Kim: Here would be my counterexample. My area of passion is studying how devops is being adopted, not by the unicorns or Facebook or Etsy or Netflix or whatever, but really large, complex organizations -- the Raytheons, Macy's, Nordstrom, the U.S. Department of Homeland Security.
Disney's [Director of Systems Engineering] Jason Cox talked about how over the years he has a large team of ops engineers that he embeds into the lines of business and dev teams. ... What he's doing is elevating their productivity so that they're as productive as they would be at a Facebook or a Google. And so the appreciation they articulate to Jason is just incredible. They appreciate the contribution, they understand how ops can help developers be productive, they get better outcomes, the business is saying thank you ...
InfoWorld: In the delivery pipeline, what sort of bottlenecks are being broken to yield these better outcomes?
Kim: One aspect is it takes too long to test. We do months of testing, yet we still find errors when we deploy to production. Even the act of deploying is often a bottleneck; it can take six weeks or six months. The same type of a practices that you see at Facebook, Amazon, or Google are now being applied to the large, complex enterprises. So what you're seeing is now [both dev and ops] engineers becoming much more productive, up to 200 times more productive according to our research.
InfoWorld: How much of that can be attributed to enabling self-service?
Kim: I think the definition of reducing the bottleneck, whether it's deploying or testing, means that it happens automatically every time the developer checks in code. For the last four years now we've benchmarked 20,000 organizations to really understand what predicts high performance. And the top predictor of performance is almost absurd: Does ops use version control?
We actually found that ops using version control is a higher predictor of performance than whether dev uses version control. My conjecture is that when you think about where more things can go wrong -- is it in the code or in the environment? -- there are probably a hundred or a thousand times more configurable settings in the environment: OS, database, storage, networking, and so on. If one thing goes wrong, the site is down. So you put ops and dev in the same version control repo where everything is reproducible. It sounds like such a practical, trivial thing, but it's one of those foundational practices that underpin everything else.
InfoWorld: How big a role does monitoring play in terms of tying metrics to specific versions and being able to provide that feedback to developers?
Kim: The No. 1 thing is version control used by ops. No. 2 is continuous build/continuous integration -- merging and testing all the time. Third was a high-trust culture. Fourth was production monitoring.
InfoWorld: Part of the idea of devops is for developers to take ongoing responsibility for code that's already in production, that they're already "done" with. Do developers actually like that?
Kim: I was hanging out with a guy named Tim Tischler, who for many years led the devops operation at Nike, and he said: "As a developer, there's never been a more satisfying point in my career than when I got to write the code, push the code into production, see the happy faces of customers when it worked, be told by angry customers when it didn't work -- and then fix it myself." Devops really doesn't enable just learning, but also joy.