Fri Apr 17, 2015
I had heard the word DevOps mentioned over the last several years, but I never gave it much thought. Perhaps I’m dense; my official job title is DevOps Engineer, however, I’ve since been “promoted” to Hip-Hoperations Engineer.
Since attending ChefConf 2015 I’ve learned that having DevOps in your job title may or may not be “good”, depending on whom you ask. Has my ignorance resulted in a DevOps faux pas? So I set out to understand what DevOps is, and I don’t mean in the philosophical sense; I want to know where this term came from and why we all care so dearly about its existence.
My learning style is best described as “ground up”, and learning about DevOps meant I had about half a decade of material to cover. I spent a few weeks watching talks, reading blog posts, and listening to podcasts. I was determined to uncover “the true meaning of DevOps” (like an old Christmas special), and it didn’t take too long before I encountered the “echo chamber” - iterations on the same idea, all arguing about definitions. Some people insisted DevOps was represented by ideas such as empathy, not passing the buck, or collaboration, while others insisted DevOps revolved around tools. DevOps sure means a lot of different things, I thought; however, the deeper I dug, the less opaque the term DevOps became. This is the brief history of DevOps, and if I didn’t get things quite right, it’s probably fine.
In the eternal words of Dr. Emmett Brown, “We have to go back!” We need to travel back to around 2009 where a few passionate developers and system administrators, who were already familiar with agile methodologies, wanted a methodology better tailored to their environment and experiences. In a talk by Andrew Clay Shafer at the AgileRoots conference in 2009, he remarked that agile was “developer centric” while “thar be dragons!” for system administrators. Clearly, this stated that agile was not inclusive to system administrators; perhaps it was time to try something new?
Andrew’s AgileRoots 2009 talk was entertaining and laid some of the ground work for what we consider DevOps today; of course, his ideas were tied to Agile at the time. I found this talk particularly enlightening because a lot of what Andrew said was foreshadowing things to come. At the time he was working at a small startup called Reductive Labs who later changed its name to PuppetLabs. Interestingly, “infrastructure as code” had already been coined as a term, which is still widely used today with automation tools such as Puppet and Chef.
Andrew’s talk contains interesting parallels to DevOps as it’s discussed today such as “the wall of confusion”, an obstacle separating developers and operations, ultimately preventing them from collaborating. In reference to meeting requirements, Andrew writes in his slides it “requires collaboration between Dev and Ops”. The proposed solution to the problem of “the wall of confusion” is based on a paper by Brian Marick, titled Boundary Objects.
A boundary object is something that allows two groups of people (referred to as “a community of interest”) to communicate effectively. Therefore, if development and operations shared a boundary object, it would lead to collaboration. The boundary object Andrew recommends is a product built by the startup he worked for, called Puppet. This is perhaps an unsurprising recommendation by today’s standards, given that both Chef and Puppet are competing in the DevOps space; judging by the questions asked at the end of Andrew’s talk, configuration management as we know it today was not commonplace.
The above image is from another interesting talk at Velocity 2009, which also seemed to herald the rise of the DevOps movement; given by John Allspaw and Paul Hammond, it is titled 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr. This talk outlines some of the “tenets” (if we call them that) of DevOps that people still discuss with passion today, such as respect, fast delivery, automating everything, and version control, to name a few. In fact, this talk is so similar to modern DevOps talks, I had to make sure the word “DevOps” wasn’t slipped into a slide somewhere.
It should be fairly clear by now that people were thinking about DevOps before the term was coined, and that DevOps was born from Agile.
Enter Agile System Administration
There were numerous folks thinking about how systems administrators and IT professionals fit into the Agile paradigm, but it was Patrick Debois who started a Google Group titled Agile System Administration, with a description of “Talking about agile values, principles, and best practices in system administration”. Patrick is also credited with coining the term “DevOps” when in 2009 he created and organized the first DevOpsDays conference, in Ghent, Belgium. In a recent interview with Patrick, he remarked that the term DevOps was used because “Agile System Administration Conference” was not an accurate name, and also not inclusive enough (potentially excluding developers).
From an article authored by Patrick Debois titled DevOps from a Sysadmin’s Perspective in December 2011:
Historically, two drivers have propelled DevOps: Agile Development, which led in many companies to many more deployments than operations was used to, and cloud and large-scale Web operations, where the scale required a much closer collaboration between development and operations.
Software is not a solved problem, and one of the smartest approaches we can adopt as a community to make software better is iteration. DevOps is an iteration from Agile. A quote I really enjoy is from my friend and co-worker Bridget Kromhout.
There is a perception of risk from moving too fast, but there is also risk from standing still.
This struck me as having really deep meaning. There is always a tendency to stand still when you’re comfortable, because it’s safe. In researching a bit of the history of DevOps, it shows the value of not standing still and not accepting the current “status quo” as acceptable. Today there exists a very real cultural and professional movement around DevOps, and while we may not all agree on which definition of DevOps is our favorite I think we can all agree the goal is to make things better together.