Chapter 1. DevOps for (or Possibly Against) Developers
A note for Early Release readers
With Early Release ebooks, you get books in their earliest formthe authors raw and unedited content as they writeso you can take advantage of these technologies long before the official release of these titles.
This will be the 1st chapter of the final book. If there is a GitHub repo associated with the book, it will be made active after final publication.
If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to the editor at .
While you here do snoring lie, Open-eyed conspiracy His time doth take.If of life you keep a care, Shake off slumber, and beware: Awake, awake!
William Shakespeare, The Tempest
Some might ask if the DevOps movement is simply an Ops-inspired plot against developers? Most (if not all) whod do so wouldnt expect a serious response, not least because they intend the question as tongue-in-cheek teasing. Its also because and regardless if your origins are on the Dev or the Ops side of the equation when anyone strikes up a conversation about DevOps, it will take approximately 60 seconds before someone inquires: But what DevOps really is?
And youd think, ten years after the coining of the term (a decade within which industry professionals have spoken, debated, and shouted about it), that wed all have arrived at a standard, no-nonsense, commonly-understood definition. But this simply isnt the case. In fact, despite an exponentially-increasing corporate demand for DevOps personnel, its highly doubtful that any five DevOps-titled employees, chosen at random, could tell you precisely what DevOps is. So, dont be embarrassed if you still find yourself scratching your head when the subject comes up. Conceptually, DevOps may not be easy to grok, but its not impossible either.
But regardless of how we discuss the term or what definition(s) we might agree upon, theres one thing, above all else thats critical to bear in mind:
DevOps is an entirely invented concept, and the inventors came from the Ops side of the equation
That may be provocative, but its provable, too. Lets start with two exhibits.
Exhibit #1: The Phoenix Project
Co-written by three info-tech professionals, The Phoenix Project, A Novel About IT, DevOps, and Helping Your Business Win was released in 2013. Its not a how-to manual (not in the traditional sense, anyway). Its a novel that tells the story of a highly problematic company and its IT manager who is suddenly assigned the task of implementing a make-or-break corporate initiative thats already way over budget and months behind schedule. If you dwell in the realms of software, the rest of the books central characters will be very familiar to you. For the moment, though, lets have a look at their professional titles:
Director, IT Service Support
Director, Distributed Technology
Manager, Retail Sales
Lead Systems Administrator
Chief Information Security Officer
Chief Financial Officer
Chief Executive Officer
Notice the connective tissue between them? Theyre the protagonists of one the most important books about DevOps ever written and not one of them is a developer. Even when developers do figure into the plotline, welllets just say theyre not spoken of in particularly glowing terms. When victory comes, its the hero of the story (together with a supportive board member) who invents DevOps, pulls the projects fat out of the fire, turns his companys fortunes around, and gets rewarded with a promotion to CIO of the enterprise. And everyone lives happily if not ever after, then for at least the two or three years such successes tend to buy you in this business before its time to prove your worth all over again.
Exhibit #2: The DevOps Handbook
Its better to read The Phoenix Project before The DevOps Handbook, How to Create World-Class Agility, Reliability, & Security in Technology Organizations because the former places you within a highly believable, human scenario. Its not difficult to immerse yourself in the personality types, the professional predicaments, and the interpersonal relationships of the characters. The hows and whys of DevOps unfold as inevitable and rational responses to a set of circumstances, which could have just as easily led to business collapse. The stakes, the characters, and the choices they make all seem quite plausible. Parallels to your own experience may not be too hard to draw.
The DevOps Handbook allows you to explore the component conceptual parts of DevOps principles and practices in greater depth. As its subtitle suggests, the book goes a long way toward explaining How to Create World-Class Agility, Reliability, and Security in Technology Organizations. But shouldnt that be about development? Whether it should or shouldnt may be open to debate. Whats incontrovertible is the fact that the books authors are bright, super-talented professionals who are, arguably, the fathers of DevOps. However, Exhibit #2 isnt included here to praise them so much as to take a close look at their backgrounds.