Ideas from DevOpsSummit @ Cloud Expo NYC ‘14, Days 2 & 3

3 More Metaphors, A Broader Definition, and Important Lessons from the Past (and Present)

Incompleteness Disclaimer:
Between my meager rest after writing Day 1's post, and my perhaps resulting inability not to snark about Oracle’s keynote/sci-fi film, I failed to provide the most timely summary of the rest of DevOpsSummit. I won’t presume to have any sort of dedicated readership, but if you exist and were disappointed by that failure, I apologize.

Additionally, as a comparison of my spotty notes and the official schedule should reveal, both my attendance and attention were incomplete in these days. But since a week later, a handful of ideas still stick in my head, I’ll discuss those here. I hope it is better than nothing ☺


Further DevOps Metaphors:
Sochi, Stock, and Rock n’ Roll

In my previous posts about DevOps I have touched on the common DevOps metaphor—the (auto) manufacturing assembly line—as well as a couple promising newcomers, namely Kevin Behr’s CO2-respiration-cell-signaling metaphor (introduced around 27:30 into this recent episode of the Food Fight Show), and John Michelson’s airplane-factory-and-wind-tunnels metaphor from DevOpsSummit Day 1. Unsurprisingly, days 2 and 3 of DevOpsSummit introduced a few more. These are the 3 I remember a week later:

DevOps Lessons from the Sochi Olympics

http://www.slideshare.net/sandhillstrat/devops-summit-nyc-2014-devops-gold-what-the-olympics-teaches-us-about-agile-development-and-release

This metaphor comprised the whole of BMC Software’s Dave Roberts’s talk. To summarize at the highest level, “if the goal of DevOps is to achieve high performance in your field, it’s worth paying attention to how professional athletes achieve high performance in their fields”.

At the risk of restating that whole talk, I will nevertheless give his 10 lessons, and their Sochi olympics analogues, as I think they were very well selected (from the large number of options):

  1. “Find and articulate your motivation for wanting to ‘do’ DevOps” (olympic medals aren’t worth much “intrinsically”, but they sure as heck motivate olympic athletes to achieve)
  2. “Your tools alone will not make you successful.” (For all his talents, the Under Armour/Lockheed-Martin Mach 39 speed skating skin did not prevent Shani Davis from failing to finish first. And neither did switching back to the old one)
  3. “Make sure your fundamentals are solid” (youngest slalom champion in Olympic alpine skiing history Mikaela Shiffrin gained a world-class advantage by continuing to focus on fundamentals long after her competitors were picking up bad habit short-term optimizations in less competitive face-offs)
  4. “Practice, practice, practice” (Shiffrin stays conditioned all year long, not just in the winter. Roberts asks “When was the last time you released something you didn’t have to, just for the experience?”)
  5. “Don’t underestimate how far you can go” (Shiffrin achieved 1 gold in 2014, and by post-race interview was already dreaming about 5 in 2018)
  6. “Benchmark yourself and incorporate every best- practice you can find.” (Shiffrin, like many highest-level athletes, studies all of the tape of her top competitors’ races. She learns from their sucesses and mistakes. She can thus be the best of all of them)
  7. “Make benchmarking and best practice adoption a repeating habit.” (She does it all the time.)
  8. “Don’t be afraid to change your existing tools and processes” (The U.S. bobsled team and Michael Scully of BMW Designworks USA threw away the existing sled, went back to the drawing board, and ended a 62 year losing streak with a bronze finish)
  9. “DevOps is not just for the young, venture-funded, Web 2.0 companies.” (the most decorated Winter Olympic athlete, 40 year old Ole Einar Bjørndalen, outcompetes his much younger competitors in the intense duality of requirement that is biathlon through sheer dedication, perseverance, and smart training. )
  10. “You need a good coach” (only ever middling in international competition herself, former soviet skater Marina Zueva coaches and choreographs both of the top 2 finishing ice dancing pairs—US & Canada—in the last 2 olympics. Her outside perspective is invaluable despite never having achieved that level of success herself)

DevOps practices as “call options”

http://res.sys-con.com/session/2271/Rajat_Bhargava.pdf , slide 17

It is no secret that I personally have little appreciation for the workings of the professional trading industry. But as many CEO & CFOs from whom an enterprise ops guy may want to seek “buy in” likely do, there may well be an important saliency to JumpCloud CEO Rajat Bhargava’s (or rather, by citation, Don Reinertsen’s) formulation of the value of DevOps (/lean) practices as call options.

A call option is an optionally executable instrument allowing the purchase of a commodity or security at a later date at a pre-agreed upon strike price. I am not the best person to explain the analogy, but I believe essentially the claim is that with these practices, rapid prototyping, quick turnaround to market, and insight from ongoing experimentation allow you to gather significant amount of information about the potential payoff of a {project, initiative, etc} before committing to it fully. Thus, using these practices is like having a call option, whereas more traditional non-optimized-for-cycle-time approaches are like having to buy outright.

(extra apologies if I screwed that up. I thought it was worth trying at least)

The 80s Music Analogy: When Rock Met Rap

https://www.youtube.com/watch?v=4B_UYYPb-Gk&

Roberts may have been the one talking about the olympics, but it was Nathen Harvey’s day 2 8am talk that wins the prize for the most viscerally entertaining DevOps analogy I have yet heard. And yet it is certainly not without a certain elegance.

In short, the (metaphorical) story of DevOps is captured in (a segment of) Episode 5 of National Geographic’s mini-series “The 80s: The Decade that Made Us”. That episode is titled, as DevOps in general perhaps could be, “Tear Down these Walls”.

While the episode dealt also with perhaps more geopolitically important walls as well, the one Nathan told us about was this one:

copyright-agnostic OC I spent way too much time on ☺

In (my backwards reception of) Nathen’s metaphor:

  • Your expert ops department is award-winning rock band Aerosmith
  • Your expert dev department is award-winning and pioneering hip hop group Run—D.M.C.
  • DevOps is like the incredibly successful 1986 collaboration track that no one saw coming

It’s a pretty good metaphor, I think (even, as presented below, after my 8am-brain switched it around, likely adding some pro-dev cognitive bias).

When Run—D.M.C. was introduced to Aerosmith’s work by their manager they called it “hillbilly gibberish”, a descriptor a seasoned developer might make of sysadmin Bob’s perl scripts; When Aerosmith first heard Run—D.M.C.’s demo cover they said “WHAT ARE THEY DOING TO OUR POOR SONG?”, a feeling possibly familiar to an ops person made to watch in horror as the new release destroys their carefully crafted infrastructure. But despite initial misgivings, when they came together in the studio and got going “It was crazy good”.

An important captured aspect here is what didn’t happen: no one made Steven Tyler rap, and no one made Jam Master Jay try to play guitar. If they had taken that approach, it wouldn’t probably have gone well.

But what did happen was the song was the first hip hop song to reach the Billboard Hot 100's top 5, Run—D.M.C. was catapulted into mainstream popularity and a somewhat floundering Aerosmith had their career revitalized while also gaining substantial numbers of new fans.

Nathen also spoke to the idea of changing norms. Today no one is surprised by a song that fuses rap and rock, indeed pop hits almost have to do that. But in 1986 it was a different story. Today (1986 in the metaphor) the idea of well-collaborating dev and ops departments remains a novelty that can get you ahead, but in the future, in probably much less than 28 years, it will be more-often-than-not an outright requirement for success.

(Nathen also talked to good effect about DevOps as adoption of humane systems practices in the dimensions of supporting the safety, contentment, knowledge, and freedom of both the developers and users of the system. I imagine you will hear more of this in the future—indeed I may write on it — but for now try checking out Chef-founder Adam Jacob’s ChefConf keynote or Riot Games’s Jeff Hackert’s ChefConf talk on the subject)


A Yet Broader Definition of DevOps

As I’ve covered at length, the definition of DevOps is disputed. When I talked about it before, I always dealt, to at least some degree, with specific organizational prescriptions—whether that was as specific as “use Chef or Puppet” or as broad as “figure out how to align departmental incentives” or “institutionalize empathy”. In Days 2 and 3 of DevOpsSummit, however, I at least twice heard a possibly broader definition that can basically be paraphrased as:

Be willing to do and to understand whatever is necessary to get problems solved, make people happy, and realize value for your business (or mission).

I remember hearing this formulation first explicitly in Bhargava’s talk, where a slide defined “the devops equation” as

DevOps = ↑ P (product/market fit)

But it was described more approachably, and, to me, more elegantly—if perhaps more frustratedly—in Jez Humble’s talk (the last of the summit), quoting John E. Vincent writing over a year ago:

Here’s the secret. I’ll tell you EXACTLY what devops means.
Devops means giving a shit about your job enough to not pass the buck. Devops means giving a shit about your job enough to want to learn all the parts and not just your little world.
Developers need to understand infrastructure. Operations people need to understand code. People need to fucking work with each other and not just occupy space next to each other.

And that captured exactly a claim I heard dancing around the edges of many talks but rarely put so directly: that devops is ultimately all about:

a) giving a shit about “getting it done” and
b) not giving a shit about whether or not it “is [your] job”

and perhaps to a lesser but important degree

c) not giving a shit about whether or not it has been done before this way, follows established patterns/”best practices”, or is yet generally known or thought to work. If its maybe a good idea, its probably worth exploring.


Important Lessons from the Past and Present

There were other good talks that I shall fail to address entirely. Alas. Probably the most information-dense, thought-provoking, and therefore by some measure “best” talks were the day 2 closer, Kevin Behr’s “Don’t Go Chasing Unicorns!: Science, Engineering, and Synthetic Thinking: How to Use Three Different Viewpoints to Make Devops Work for Your Mission!”, and the day 3 closer, Jez Humble’s “Stop hiring devops experts (and start growing them)”.

I don’t think I can do either complete justice here, so I am not going to try. (But feel free to check out my outlines for the less-than-all I managed to write down during; and also consider going after the videos of Behr’s recent DevOpsDay Pittsburgh keynote and Humble’s ChefConf closing remarks and January talk given under this same title. I doubt they cover exactly the same things, but they are probably somewhat close).

Though I shan’t try to tackle them, I will extract three particularly interesting nuggets and bring them to the surface, if only mostly in “further reading” link form:

  1. Behr spoke of historical and personality biases in the technology industry and how they are our ongoing undoing. Though he does not share Jez’s apposite surname, he delivered a humbling reminder that not only was “all this stuff” figured out and implemented to good effect in Japanese car companies, so too was it done in English coal mines in the 1940s. For this I will point, again (but this time non-parenthetically) to his DevOpsDay Pittsburgh keynote for more
  2. Humble brought us back to the auto manufacturing line and Toyota’s success. He cautioned of case studies broadly and spoke upon the importance of understanding the difference between copying the a method of problem solving (that will help you) and copying the solutions (which may or may not help you, depending on if you actually have the same problem).
    Notwithstanding that advice, he spoke highly of the positive case study of the plant of New United Motor Manufacturing Inc. as an example of changing a culture to solve problems. He pointed to two further resources about that case study: this Sloan Review article, and this episode of This American Life.
  3. Humble (like Roberts) also called on us to learn from the present! Both Behr and Humble reminded us of the difference between scientific data and anecdote. And to both ends, Humble pointed us to the results of the recently completed Puppet Labs (in association with IT Revolution Press and ThoughtWorks) 2014 State of DevOps Report. Dig in.

As I stated above, I can’t do either talk (nor the impromptu discussion after Behr’s) justice in this article and I shan’t really try beyond these 3 references. But one parting thought I will highlight is that both Behr and Humble spoke, at least briefly, of the complex adaptive system: of the important and difficult realization that in reality a system is usually (or perhaps always) more than the sum of its parts, of the biases we must acknowledge in ourselves when we try to understand these systems, and the systematic ways of thinking (scientific method especially) we must use if we hope to figure it out. And there, probably more than all the metaphors and definitions one can care to throw out, lies the real wisdom.