Ideas from DevOpsSummit @ Cloud Expo NYC 2014, Day 1
Speed, Service, Empathy, Airplanes, & the Power of Pull
Whilst off in San Francisco, the second day of the inaugural DockerCon brought down the house—complete with Solomon Hykes’s major-refactor announcing keynote and the headline grabbing Google App Engine support announcement— back here in New York, there was another DevOps conference opening its first sessions.
Today marked the first day of the first U.S.-based DevOpsSummit [as far as I can tell, unrelated to its European namesake] enclaved—or one might drolly suggest “siloed”—within the 14th International Cloud Computing Expo. This summit actually only came to my attention, via Twitter, yesterday, but as surprisingly one could find valid 100% off coupon codes on its registration page yesterday (and as my full-time, daily employment remains a work in progress), I figured I’d check it out.
I think I originally intended to give a full rundown of the proceedings (and you can find all my scarcely-edited field-notes here), but as I didn’t get to all the talks, and I imagine slides are forthcoming, I wish only to lay out some of the memes (in the Dawkinsian sense) which I heard oft repeated or found particularly resonant. In truth, it could perhaps better be several articles, but alas I shall march on with it all here.
Claimed Origins of the Need for DevOps
Though, in truth, I think this conference-in-a-conference foreseeably suffered some degree of confusion regarding what DevOps is, there seemed to nevertheless be a general consensus amongst speakers that it need soon be adopted!
This wisdom was prescribed with special emphasis for “the enterprise.” This case stemmed perhaps partially from the number of consultants making it, but it seemed also to possibly rely on the assumption—dubious to me— that “webscale startups” have all already done so.
This view, while perhaps not entirely accurate, was supported with some interesting evidential claims I heard from a few different sources:
0. “Software is Eating the World”
It’s been almost 3 years now since Marc Andreessen first popularized the phrase, but today I heard it repeated again and again. Often it was quoted directly, but even when it was not, the point was hammered home.
John Michelson of CA Technologies came right out of the gate in his solid keynote with a number of solid examples of how software is becoming instrumental and pervasive in industries that used not to (need) worry themselves:
- Cable companies compete not on what programming they can deliver but the features of their DVRs
- Nest (recently acquired by Google) disrupted the HVAC industry [ed note. and to such an extent and so unexpectedly that some suggest Honeywll had to resort to sueing them for being round, and is only now starting to play catch up]
- Tesla Motors, not content with trying to drive home the electric car, has been delivering over the air software updates to rapidly address user complaints about such important issues as brake behavior on steep grades.
- State Farm is simplifying auto claims by allowing customer to simply provide detailed accident reports from their smartphones, from the scene of the accident
- CVS is offering customers an integrated way to check the correctness and potential interactions of their prescriptions.
- Dennis McGuire of Automic added the example of mobile check deposit in banking, which he supported with an analysis from one analyst to have cost one bank, in a few months, something like $7.5 billion in deposits taken to competitors already offering the feature.
As Michelson went on to rephrase, as the CA marketing (left) would have him, “Business [is being] rewritten by software”. And everyone (including me) seems to agree he has a point. (“The geeks were right!”)
1. Smartphones have created a “need for speed”
There is no question that in the last few years smartphones have taken off with a vengeance. (It is still always weird to reflect that was largely sci-fi in 2006 is now so commonplace as to be assumed.)
A side-effect of this revolution that was harped on a few times today was that consumers, as a rule, have less patience. The image was alluded to of “out of the pocket, and done” — I think of the current cycle of Wells Fargo ads (ironically highlighting their SMS capabilities). It seems to make sense, though I’ll note, at least in a cursory search, I could not readily find rigorous verification of this trend.
And while smartphones are supposed to have been a driver, they have not been the only technology affected — Michelson also quoted (and cited, but slides not up yet) a figure that it takes 25% of users only 3 seconds of load time before they abandon a web page. He followed this with a anecdote about his son’s 16th birthday enthusiasm for a Dodge Ram gone in those 3 seconds when the customizer was slower than Ford’s.
(Certainly end-user performance is not DevOps, but so too is it not not related)
2. The need for speed extends to the speed of change & “the startups” are meeting it!
There was something of a boogieman in play on this point, but I don’t doubt it comes from somewhere.
This was ultimately the cloud expo and the cloud was heavily referenced. One particular claim repeated by ActiveState’s Bernard Golden was that the cloud has provided a “forcing function” of speed that puts “the enterprise” at a strategic disadvantage. This claim was not expounded on too deeply, but I think it amounts to something like this:
- In years past, established enterprises had a competitive advantage by virtue of their much greater access to resources
- The elastic availability of computing resources put into the world (first) by Amazon destroyed that advantage
- Startups proliferate and want your market. They are free in ways you are not. (The explicit example cited was “SEC compliance”, but I suspect a better one is mere lack of bureaucratic or historical organization overhead)
- Startups will move with more agility, and they will eat your lunch.
- In conclusion, if you don’t want to lose to PiedPiper, get DevOpsing!
Though other formulations were not so cautionary, it was a common theme nevertheless. I think in at least 3 talks I heard some variation of “what used to take weeks, now takes minutes” (and each time I heard this, I thought of Adrian Cockcroft’s pretty solid Keynote at FlowCon).
“Speed wins!” is not a new idea, but is one that seems to be growing in importance. New bubble or no, the liklihood that a startup will try to outcompete you on shiny feature time-to-market is near an all time high. “The Cloud” certainly has something to do with that. “DevOps” may well too.
Service, Empathy, and DevOps as IT-as-Design
Probably my favorite talk of the day, and honestly perhaps largely because I had low expectations for it based on title alone, was Jeff Sussna’s “The Essence of DevOps” (on the schedule as “Are We Doing DevOps Right?”).
If I articulated 3 separate views of DevOps the other day, then he provided an artful and cogent fourth. (which is to say I do think his is captured somewhere in my 2nd and 3rd, but also I don’t think those are truly distinct. His were not new ideas to me, but it was an excellent reminder of some thoughts I really left out.) The slides and presentation were all around excellent, I will try to mirror it here closely but succinctly.
The Need
(This is the part I’m most skeptical about but I’m definitely still mulling it over.) Jeff touched on some of the “Software Eating the World” ideas but from there he quickly and definitively generalized. In short:
- We are entering an age where products are being supplanted by services (at the very least in software, but it was presented as “generally”)
- The way that services are valued is fundamentally different than how products are valued:
- Products are instilled with value by what we do to create them — in working on a product, we create a realized manifestation of the value.
- In creating a service, we do not fully realize value: we create merely the potential for value
- In the end, value is co-created in the actual interaction between the customer and the service
This may seem like some nice near-metaphysical philosophy, but it has some deep and immediate implications that explain why the industry needs to change
- Functionality and operability are inseparable
- Systems of record and systems engaged with customers aren’t distinct
- UX is the product
- End-to-end thinking, end-to-end realization is necessary. Anything short is intolerable waste
The Way
He briefly laid out what is often tried in error, and cannot (alone) work: new tools, new titles, re-orgs, and recruiting the mythical master full-stack engineer.
These things may help but only when they lead to one deeper ideal:
empathy.
Here he was careful to undefine and (re)define his term to its root:
empathy is not understanding someone else’s needs;
empathy is having the ability to see from another’s perspective
In particular, to see yourself from their perspective
To this end new tools and new paradigms can be deeply helpful, but only if they are shared.
Feelings are nice and do determine how things work, but obviously people like specific suggestions. He had a few good ones and I won’t remember all of them, but at least he recommended the following:
- The use of T-shaped people
- Practice intentional use of ethnography — understand without judging before you seek to belittle or change
- There is no “they” in your organization, there is only “we”
- The goal is never only to get a task off your desk. The goal is to get the issue resolved. (mission thinking)
He had some words on legacy transformation that I unfortunately did not understand as well. He summarized with another strong conceptualization:
Practice DevOps as It-as-design (Anticipation + Ethnography + Creativity + …)
tied back around by a beautiful quote from Irene Au:
Design is empathy made tangible
Overall I found it a strangely moving and effective conceptualization. It closed with an equally elegant warning:
This is hard. To do this ultimately you have to ask people to change their thinking and behavior. People are reluctant to that.
Other speakers spoke of the importance of “aligning your workers with the business goals”. I myself mentioned it in my attempt to describe what needs to be done. The language of empathy is not business-like, not so nicely formal — but I think its a powerfully correct claim.
The Airplane Metaphor
In discussing DevOps (in the broader Phoenix Project sense), it is common to use the metaphor of the factory floor. This follows naturally from the source of the research in logistics and lean manufacturing. Factory floors are what Deming and Goldratt dealt with and their lessons are being decently applied.
In listening to the Food Fight Show of June 3rd this morning I was also impressed with the metaphor of cellular signaling and respiration.
But soon after that I was presented a third solid metaphor that strikes to the heart of an issue many companies truly need to address:
John Michelson reminded us that too many software teams make software like this:
When they could me making software like this:
With a lot of this:
If a picture is not indeed worth a thousand words, let me briefly summarize:
- Modularity and parallel development are possible (and more efficient than working without) when interfaces are focused on
- Component Testing: Boeing wouldn’t put a wing on a plane without testing it (and alternatives) in a wind tunnel.
- Virtual Services and predictive analysis: There’s a reason we build wind tunnels. We need them. There’s a reason that (QA) engineer is paid to design and build wind tunnels rather than blow really hard on the model wing.
And finally (if you don’t count the Top Gun “need for speed” connection), there was one more good piece of the airplane metaphor that my couple pictures didn’t get:
- Monitoring. We wouldn’t accept a plane flying without an informative black box (flight recorder). It is unacceptable for your production service to not provide enough data examinable in a post-mortem
I think its a good enough metaphor for the areas of potential improvement to be added to the standard DevOps stable ☺.
The Power of Pull
This piece is getting super long and I need to get to bed if I’m going to make Day 2 (let alone Nathen Harvey’s talk at 8am), but I simply cannot claim to have addressed today’s take aways without touching on this.
John Willis gave another edition of his talk on how DevOps logic shall soon be coming to network equipment near you. It was a good talk for many reasons, touching on many of the mentioned themes, but one slide more than any other (I noticed) lit the twittersphere atwitter:
Now at first I did not completely get the idea of the “power of pull” (and I may still not). It is to do with the proliferation of git and the pull request workflow and the generalizations upon it.
Honestly, I think it might be more approachably stated as so:
The power of DevOps (and github, etc.) lies in one simple, well-known fact:
It’s easier to ask for forgiveness than permission.
I state it thus with some amount of tounge-in-cheek, but I do think it correctly states an important idea, not only found in the ideas of a proper DevOps-ed (even by “recruiter definition”) environment, but indeed a central idea of Github, a central idea of Continuous Integration, and probably other examples I can’t think of:
When you can easily duplicate and branch {code, an environment, a server, etc.} without needing to be explicitly granted permission first (e.g. get push access to a shared repo), you have freedom to experiment without a) fearing breaking the only or shared copy, or b) worrying about it necessarily needing to lead (immediately) anywhere productive and stable.
By virtue of the pull request you can suggest without demanding, competing ideas can be presented and evaluated in parallel.
The processes of collaboration and review decide what moves forward. And what goes live.
(Automated) acceptance testing makes sure you didn’t break things, if you didn’t it more-than-happily “forgives” your experimentation.
And yeah, that’s kind of continuous delivery in a nutshell.
Anyway, its 2am now. So, See some of y’all back at the conference in a few hours ☺
