Source – infoworld.com

If you’re still puzzled about devops, allow me to make a recommendation: Read The Devops Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis. It’s a beautifully crafted, no-nonsense book that is filled with case studies and actionable advice intended to help you boost productivity by magnitudes.

The Handbook is not structured the way you might expect. Only one section is devoted to what the authors call “the technical practices of flow” from development to operations, otherwise known as continuous delivery. The other sections address gathering and incorporating feedback from application monitoring — and, more important, building continual learning and experimentation into your culture. Security and compliance get their due as well.

This accurately reflects the breadth of the devops trend. As the authors say, “Devops is transformational to how we perform technology work, just as Lean forever transformed how manufacturing work was performed in the 1980s … devops is not just a technology imperative, but an organizational imperative.” Another way of putting it is that devops is the engine of digital transformation, the catchall trend that is supposed to yield a modern, agile enterprise.

Devops in the trenches

That being said, most technical people want to hear about the details of continuous delivery, because it’s impossible to achieve devops productivity gains without automation and improved workflows. I recently spoke with Armon Dadgar, co-founder of Hashicorp, which is famous for its Vagrant software to create portable development environments. He breaks devops into seven essential elements: build, test, package, provision, secure, deploy, and monitor.

You might notice that you’d need those very same elements in the waterfall method. So how is this devops? He says, “The goal of devops is to parallelize as much of this as possible. These seven steps are necessary and sufficient, but they don’t have to be done sequentially.”

In decoupled fashion, operations handles provisioning and deployment; security pros lock down the environment(s) in which applications will run; and developers build, test, and package the applications. Dadgar also says developers should be responsible for application monitoring to fulfill a key tenet of devops — that is, developers should maintain responsibility for applications in production, rather than throwing them over the transom for ops to deal with.

In particular, Dadgar sees the provisioning element as a key sticking point, the newly complex lifecycle which is helping drive devops adoption:

When we were at our bare metal, vSphere-only world it was a relatively simple problem. You open the UI of vSphere; you click around, all of this done manually by hand in VMware. As you balloon out into this world where I have five different SaaS providers and PaaS over in the corner and hybrid IaaS and bare metal, this problem all of a sudden isn’t just vSphere’s UI.

How do you provision and manage that complexity, especially as these things interact with each other? It’s not that my web server is totally divorced from my cache and my database and my frontend load balancer. They’re all tightly related in a complex way. As you get more and more outsourced, it’s like, great, I’m going to run my web server and I’m going to use Amazon’s database and I’m going to use DynDNS and CloudFlare in front of that. Now I’m managing lifecycle across resources of totally different vendors.

To enable a parallel workflow in this new heterogeneous world, rather than recreate more complex waterfall with Jira tickets flying everywhere, Dadgar suggests that we “disintermediate all of our work with software.” Hashicorp has its own set of tools for all seven elements — Terraform handles provisioning — but they’re designed to be mixed and matched with tools customers may already have in place.

Despite the fact that he co-founded Hashicorp, Dadgar believes that “Devops is more process than it is tools. I think that’s what gets missed in the way it’s represented. There’s a fixation on tools because tools are easy. It’s hard to change organizational process.”

The realistic view

Any popular IT trend eventually becomes the subject of ridicule. Devops has already been derided for putting too much of a burden on developers, for raising unrealistic expectations about dev and ops finally getting along, and so on.

When you get down to it, devops is more philosophy than methodology. Its success depends on the organizational culture and the people involved more than tooling or step-by-step recipes. A particularly telling passage from The Devops Handbook puts it this way:

We have a dirty secret to reveal. In many of our case studies, following the achievement of the breakthrough results presented, many of the change agents were promoted — but, in some cases, there was a later change in leadership which resulted in many of the people involved leaving, accompanied by a rollback of the organizational changes they had created.

Such is the nature of IT and organizations in general. Whether it’s lean manufacturing or devops, when done right the benefits can be phenomenal. But it takes leadership and a willingness to take risks and shake things up — and a sustained commitment for those changes to persist.

As Gene Kim noted at last November’s Devops Enterprise Conference, there are roughly eight million developers and eight million ops people on the planet — and at best 2 to 5 percent of that population may be using devops principles and practices. To Kim, given the huge productivity potential of devops, that sounds like trillions of dollars of value as yet unclaimed. He may be right.