Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Gene Kim on the benefits of DevOps

Marcel Santilli SVP of Marketing , UpKeep

While DevOps is really only six or seven years old, the spirit of integration and agility that the DevOps movement is rooted in has transformed IT organizations, including Facebook, Google, Netflix, and Amazon. Supporters of the old, throw-it-over-the-wall approach to software development and deployment are fewer and farther between. So long, siloed IT teams!

Author, entrepreneur, and founder of security company Tripwire, Gene Kim believes that DevOps is the new way. But for Kim, it's more than that—it's a passion. He and his colleagues believe that DevOps benefits, including financial ones, can be quantified, and that companies large and small can move toward a DevOps style of software delivery with confidence that the effort will soon pay off.

Kim recently spoke with HP about the DevOps movement, the growing interest in it, and why DevOps is gaining traction at the practitioner level.

Why DevOps adoption?

When asked what's most exciting about the DevOps movement, Kim says, "It's really about enacting technology practices and architecture that help organizations create a very fast—or even continuous—product flow, from dev through testing through operations, all the way to deployment, while often increasing reliability, stability, and security.

"But its adoption can also enact changes in the culture of a business—for example, allowing small teams to work quickly and independently. You know, back in the bad old days, before DevOps started gaining ground within large and small enterprises, for a software company to deploy even small updates or upgrades or bug fixes, the work might involve literally hundreds of developers—and it might take weeks to get a new product out the door. Today's high-performing enterprises and DevOps adopters, on the other hand, deploy so much faster, and the products they release generally have higher rates of reliability."

The dilemma of software speed versus quality

For decades, businesses that rely on the development and deployment of software to support or supply their customer base have faced the dilemma of speed versus quality. If you get to market sooner than your competitor, you may be cutting corners in testing and quality assurance, which can spoil your debut. But if you wait until your code is perfected, you can lose the race to the next breakthrough. Kim points to new research suggesting that a DevOps approach can help resolve that dilemma, and improve the bottom line at the same time.

"Over the past three years, my researcher colleagues and I helped automation software company Puppet Labs put together the 2015 State of DevOps Report, which has collected the DevOps health and habits of more than 20,000 technology professionals. We found that high performers using DevOps exhibit more agility and reliability in their releases, and they were twice as likely as non-DevOps adopters to exceed productivity goals. For the nearly 800 organizations that provided a stock ticker symbol, we found that the high performers had nearly 50 percent higher market capitalization growth over three years—indicating that DevOps is great for IT performance, as well as organizational performance.

"It boils down to this: The way that virtually any enterprise today acquires customers, and brings value to those customers, is increasingly reliant on technology, and it's becoming more and more obvious that agility and speed are key attributes for any company that wants to win in the marketplace."

Walking the walk

As author of the highly successful novel The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, which traces a software executive's transformation toward a DevOps style of IT, Kim hasn't simply written about his ideas. He's walked the walk. He describes several moments in his career when the lightbulbs flashed.

"I've been studying high-performing technology organizations since 1999, and at that time there seemed to be something of a downward spiral in terms of organizations and their ability to deploy products quickly and reliably. Something was preventing dev, operations, and even information security from achieving their local goals, and ultimately the organization's broader goals.

"I wasn't alone in thinking that there had to be a better way for software enterprises to function, but the question was, 'What is this better way?' In my own research into that question, I had stumbled on some of the DevOps values—collaboration, automation, the empowering of small teams, etc.—in high-performing companies. But when I went to a DevOps Days conference in 2010, and before that saw John Allspaw and Paul Hammond's now-famous 2009 talk about 10 deploys per day at Flickr, the lightbulb really went on. I knew that here were people who were solving for the problems that I had seen in a lot of underperforming companies."

The birth of a movement

Kim notes that no one had a name for this new philosophy, its methods, or the (then) slowly growing community. He credits Patrick Debois—a "technology-boundary spanner"—with creating the term "DevOps."

"I also remember Patrick Debois and another visionary, Andrew Clay Shafer, brainstorming around agile engineering practices; growing the community through DevOps Days; Jez Humble and David Farley writing Continuous Delivery—all these things stand out as seminal events that formed the revolution we're seeing now. And that's certainly how many of us got exposed to the ideas and answers that we were asking for [for] more than a decade."

Stop making cost the priority

So what has the DevOps movement meant to organizations founded on older styles of IT? How have they adjusted their thinking regarding their products and services, as well as their own internal technology needs?

Kim recalls a moment from the 2014 DevOps Enterprise Summit (DOES) in San Francisco: "One of the most memorable lines of the entire three-day conference came from Courtney Kissler, who's the vice president of e-commerce and store technologies at Nordstrom. Courtney said, 'Our DevOps journey started when we stopped optimizing technology for cost and instead started optimizing for speed.'

"The backdrop for that quote was a discussion of the so-called 'killer Bs'—Borders, Blockbuster, and Barnes & Noble—and how organizations can avoid the very public and well-known pitfalls experienced by those three companies. What struck me about Courtney's observation was the emphasis on speed. Instead of focusing on how much it would cost Nordstrom to deploy new software, the question was about how quickly it could get a new product to market. How could it achieve something like the capabilities that companies like Amazon and Netflix are creating as a matter of course?

"For years and years, especially in IT operations, we tended to organize and optimize for cost, which meant not only creating functional silos for the networking people, server admins, database people and so on, but also making it easy to outsource all sorts of these functions. There are a whole bunch of very different techniques we use in order to optimize for speed, including the use of small, cross-functional teams that can independently deploy value to the customer without having to rely on hundreds, or even thousands, of other people.

"When you optimize for speed, you're willing to do all sorts of things: cultivate internal talent, pay engineers better and send them to conferences. [These are things] you would not necessarily do if you were optimizing for cost. In that sense, Courtney's quote really crystallized for me what a powerful driver for transformation the DevOps movement can be within large and hugely complex companies."

Keep learning

Read more articles about: App Dev & TestingDevOps