Discover Performance

Author and DevOps guru Gene Kim talks about DevOps and his new book, “The DevOps Cookbook.”
 

Gene Kim, the founder and former CTO of Tripwire, has worked with leading Internet companies on improving deployment flow and production rigor around their IT operational processes. His “Visible Ops Handbook” has sold more than 200,000 copies to date. One of the authors of the “The DevOps Cookbook,” being published later this year by ITRevolution, Kim sat down to give us his insights into the DevOps movement.
 

Q: What problem does DevOps solve, and at a high level, how can IT executives encourage the solution?

Christian Verstraete, HP’s chief technologist for cloud strategy, said it best: “In the old days, problems would arise when engineers designed products without assembly and manufacturing in mind. Now, we design for manufacturability, keeping the manufacturing team involved throughout the design process to ensure things can be built and assembled quickly and efficiently. In the field of software development, we’re in the exact same situation.”

Now, more than ever, we need developers who understand the IT operations environment, and IT operations staff who understand development. But having each group take the other out to lunch to get to know each other better isn’t enough. At a minimum, we need each group to help the other solve their local problems. But more importantly, both groups need to be a part of a super-tribe, working together to ensure that the organizational global goals are being met.

In short, we need to embed IT Operations expertise and resources into Development, and vice versa.

Q: We hear a lot about DevOps, but it’s hard to pin down. Is there an exact, accepted definition of DevOps practices?

What’s most striking about DevOps practitioners is their consistent, fervent and shared belief that Development and IT Operations, as well as all the other members of the IT value stream, must work together differently to achieve fast flow of features while providing stable, reliable and secure IT services.

But I would describe DevOps today as more of a cultural and philosophical movement, and not yet a precise collection of practices and procedures, whether descriptive or prescriptive (such as CMM-I, ITIL, etc.).

Ideally, we’d have a collection of DevOps processes, practices, procedures and patterns that describe precisely what Development and IT Operations must do differently to improve their daily work. The goal of the “DevOps Cookbook” project is to catalog what the “high-performing DevOps organizations” have in common that results in their extraordinary performance outcomes.

By doing this, we hope to provide prescriptive, “good to great” guidance so that organizations can replicate the results of these high performers, significantly increase the probability of DevOps initiatives succeeding, accelerate DevOps adoption and, ideally, lower the activation energy required to start and finish these types of transformational projects.

Q: Why does DevOps talk primarily about Development and IT Operations?

I think it’s primarily because Development and IT Operations is where most of the tribal warfare occurs.
 
More precisely, for so many business value streams, they’re the two departments between the business and the customer. In other words, requirements are identified by the business—product managers, business analysts, etc. —and then built in Development and transitioned into IT Operations, where value is delivered to the customer in the form of a service.
 
Often, Development and IT Operations have diametrically opposite motivations. Development is motivated to deploy more changes to respond to business needs, while IT Operations is motivated to prevent changes to preserve production stability.
 
DevOps ends that conflict by creating a “super-tribe” that is larger than either. It also includes product management, project management, QA, packaging and release management, and information security, all of whom have roles to play.
 
Working together, this super-tribe can get both fast feature flow and stability.

Q: What can IT Operations help with in Development?

Any process-improvement methodology preaches the need for “quality at the source.” Consequently, what we need most from senior IT Operations resources is to help define the nonfunctional requirements for both the code and the environment it runs in. To oversimplify, the nonfunctional requirements are everything that isn’t a feature for the end-user customers, such as requirements for scalability, manageability, durability, portability and so forth. By doing this, Development will build things in a way so it can be easily deployed and managed in production, as opposed to being “thrown over the wall.”

The resulting improvements can be large, such as helping define the capacity and production support requirements and architecture. Or they can be small, such as specifying where configuration settings should be stored, designing the deployment and packaging requirements and so forth. They all make a difference.

IT Operations can also fix another big problem that happens in too many projects: Development uses up all the time in the project schedule, leaving no time for performance testing, creating a suitable environment for it to run on, testing deployment procedures, and so forth.

We mitigate this by changing the Agile sprint policies. Instead of merely requiring shippable code at the end of each sprint interval, we also require the team to have a working environment that the code runs in, ideally created by an automated process.

By doing this, all the developers will have consistent environments, and we will have an automated process that can build both the production and preproduction environments.

The benefits are breathtaking, because in the earliest stages of the project, we’ll have standardized environments and predictable deployments, requiring much less rework throughout the entire project and life of the application.

Q: What does Development do in IT Operations?

Another goal of almost any process-improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made. One of the my favorite examples of this in IT service delivery came from Patrick Lightbody, the founder of browsermob.com, who said: “We found that when we woke up developers at 2 a.m., defects got fixed faster than ever.”

By putting Development closer to the IT service and the customer (e.g., Level 3 escalation), we create a healthy feedback loop between IT Operations and Development. As a result, problems get solved faster and as a cross-functional team. This yields far better outcomes than having both groups work in a silo, with tickets and issues bouncing around for so long that management needs to intervene.

Q: When will DevOps be just “the way everyone does things”?

As Dr. Deming said, “Survival isn’t mandatory.” As more and more business objectives rely upon IT, and thus Development and IT Operations, business competitiveness and survival depend on these groups working together effectively.
 
I believe that most of the DevOps patterns are the emergent properties that arise when you apply the techniques like Lean, the Toyota production system, Theory of Constraints and so forth to the IT value stream.
 
In manufacturing in the 1980s, organizations that didn’t adopt improvement practices lagged in the marketplace. I believe that within five years, especially with adoption of cloud computing and PaaS, organizations that don’t adopt DevOps style practices will be notable, because they’ll be the losers.

For more on what DevOps can bring to the IT enterprise, check out Kim and his co-authors’ “DevOps Cookbook.”