DevOps: from Unicorns to Horses

Gene Kim is an award winning CTO, researcher and author. He was founder and CTO of Tripwire, a pioneering internet security company, and has written three books, including “The Visible Ops Handbook” and “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.”

Gene has worked with some of the world’s top Internet companies on improving deployment flow and increasing rigor around IT operational processes.

In 2007, ComputerWorld added Gene to the “40 Innovative IT People Under The Age Of 40” list, and was given the Outstanding Alumnus Award by the Department of Computer Sciences at Purdue University for achievement and leadership in the profession.

Walk us through your background to start.

I’ve had the privilege of being able to study high performing technology organizations since 1999. This journey started when I was the founder of Tripwire, Inc. where I served as the CTO for thirteen years. I had written the original version of Tripwire as an undergraduate study at Purdue University–an independent study with Dr. Gene Spafford.  And before that, I worked as a system administrator and a file system QA engineer at Sun Microsystems.

It was amazing to see that in high performance organizations, IT Operations and Infosec worked together to achieve common objectives, helping each other — as opposed to the more common reality where they worked against each other’s interests, with neither achieving their goal.

Around 2006, we started to see an even bigger problem, which was the chronic struggle between Dev and Ops. The result was an ever-worsening downward spiral:  deployments taking longer and longer, delays in getting features to market, more fragile code in production, more Sev 1 outages, etc. The end result was that Ops started drowning in unplanned work, making it impossible to pay down technical debt.

Technical debt is frequently created when Dev is pressured to cut corners in order to “make the date.” This results in ever-worsening conditions for everyone in the value stream, making it difficult (if not impossible) for the organization to win.

When people started talking about “DevOps” in 2009, I got so excited because I immediately saw DevOps as the solution to this “downward spiral.” In fact, I think DevOps will solve some of the most urgent and important business problems of our generation. I think it’s akin to the transformation manufacturing underwent through the application of Lean principles.

In short, DevOps is exciting!

You made the switch from a security operator to a DevOps writer, evangelist and thinker. How did that come about?

I’ve been asked (I hope in jest) whether I still cared about information security, since I seem to be spending so much time in the DevOps community.

The answer is, of course I still care about infosec!  But like so many information security practitioners, I grew disenchanted that we could positively influence security outcomes with traditional SDLC processes. (In fact, I still love hanging out with my favorite people in infosec, including Josh Corman, the CTO of Sonatype, and of course, Dwayne Melancon, the CTO at Tripwire, Inc.)

The reason DevOps is so exciting to me is that when we are able to contribute to the quality of work upstream in Dev, we can radically change the downstream outcomes. We can create continuous deployment pipelines, which shorten the time required to go from from “code committed by Dev” to “successfully running in production,” we can increase change success rates when we push code into production, and we can significantly decrease MTTR.

When we do this, it’s great for Dev, Test, Ops, and even Infosec.  And more importantly, for the organizations we serve and our customers.

To fully articulate my thoughts around the importance of DevOps, my co-authors and I wrote “The Phoenix Project.” It’s a little unusual in that it’s in the form of a novel, but I think storytelling is a very powerful way to convey a point of view. The book itself is modeled after one of my favorite books, “The Goal: A Process of Ongoing Improvement” by Dr. Eliyahu Goldratt, which is credited with changing how a generation of managers thought about plant operations, and is integrated into most mainstream MBA curriculums.

How do you define what’s been broadly termed DevOps? How would you characterize this trend?

The term “DevOps” typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e., high deploy rates, short lead times), while simultaneously increasing the reliability, stability, resilience and security of the production environment (i.e., high change success rates, fast MTTR).

These techniques were pioneered by the Internet companies (what some people term “the unicorns,” such as Flickr, Etsy, Google, Amazon, Netflix, etc.), who have been the innovators and early adopters, to borrow a phrase from Geoffrey Moore. Increasingly, however, DevOps is witnessing adoption by the so-called early majority, which includes more traditional enterprise IT shops.

You spend a lot of time with these DevOps “early adopters” in the enterprise. Can you describe that world as it relates to DevOps?

Studying how enterprises are adopting DevOps is my current area of passion.  After all, the unicorns are doing just fine — it’s studying the rise of the “horses” that is so exciting to me.  I believe the vast majority of the value of DevOps will be created by improving the state of the practice where vast majority of the technology work is happening–with the organizations that can be collectively termed “horses.”

This is the reason I’m hosting the DevOps Enterprise Summit, a three-day conference where fifty leaders are sharing their stories of DevOps transformation in large, complex organizations.

Our goal is to show that DevOps is for horses, and not just for unicorns.  We have announced speakers from GE Energy, Macy’s, Disney, Blackboard, Ticketmaster/LiveNation, US Department of Homeland Security, UK.gov, Nordstrom, Capital One, Raytheon and others in the same vein.

I continue to be amazed by the courageousness of these leaders, who are creating pockets of innovation, often in organizations with decades (and in some cases, even centuries) of low-trust, command-and-control bureaucracies.

[Editor’s note: The conference will be held in San Francisco on Oct 21-23. You can register at http://devopsenterprise.io. Gene was kind enough to let us share a discount code! Please use code “AMPLIFY20” for a 20% discount, which expires October 10th].

How should a young company in this space go about working with such organizations? How do the buyers in these large enterprises think of less mature vendors, especially in this space?

My belief is that the engineers (whether we’re in Dev, Test and Ops) implementing DevOps in large, traditional IT organizations will eventually become indistinguishable from the engineers working at the leading companies around Silicon Valley.  Regardless of the company we work for, we are always trying to create a fast flow of work from Dev to Ops, and a fast flow of feedback from Ops to Dev.

Regardless of where we work, once we’ve seen that there’s a better way to do things, we don’t want to go back to the old, crappy way of doing things — and that’s true when we’re working at a company on the cutting edge of technology or in a large Fortune 500 organization.

My advice to someone in a smart software startup solving problems for large, complex organizations that are adopting DevOps?  Don’t make the mistake of thinking these buyers any less sophisticated or savvy than someone who works at Netflix or Google.  Chances are, they’re going to the same conferences as we are, watching the same speakers and reading the same books.  And they’re solving complex and exciting problems, just like the unicorns are.

I’ve observed some people dismiss “enterprise IT” — suggesting that the operators and developers in more traditional organizations constitute some sort of technology underclass, who will never (or don’t deserve) to adopt DevOps.

Anyone who wants their fellow developer or operations professionals to be unburdened from hair-on-fire work hours and a chaotic operations environment, should encourage everyone to adopt DevOps.  Nathan Shimek, an engineering manager at New Context told me a couple of weeks ago,  “As a lifelong Ops practitioner, I know we need DevOps to make our work humane.  In the past, I’ve worked every holiday, on my birthday, my spouse’s birthday, and even on the day my son was born.”

And that’s why I think everyone needs DevOps now.

  • Share this post: