ITIL® and DevOps - arch-enemies or complementary models?

17 Feb 2017 03:19 PM

Blog posted by: Dave Blodgett - Managing Director and CIO/CISO, HedgeServ, 17 February 2017.

I recently read a blog post titled something like "the death of ITIL". The essence of the post was the suggestion that DevOps would essentially supplant the role of ITIL in high-functioning organizations. Reading the blog post made me realize that the state of confusion around what DevOps is (and isn't) might have finally reached its apex.

At risk of gross oversimplification, DevOps is a paradigm shift toward a few key things:

• Developers are no longer cordoned off outside the circle of operational trust. With DevOps, developers and operations professionals become integrated as a single, cohesive development (Dev) and operations (Ops) team
• Well-implemented DevOps shops make heavy use of infrastructure as code (i.e. infrastructure automation via APIs (Application programming interfaces), such as with Amazon AWS or Google GCE). But to be clear, while the advent of public cloud services has made the traditional role of a subset of dedicated infrastructure operators less relevant in shops that have made the shift to operating entirely in public cloud environments (such as the engineers that have responsibility for the deployment of bare metal servers or VMs (virtual machines)), it does NOT eliminate the need for the infrastructure engineers that build and manage the underlying cloud stack behind the API curtain, or the engineers that design and manage cloud infrastructures above the metal tier
• DevOps moves us toward a single code base that encompasses software, middleware, and the underlying operating environment. It represents a move toward converging what were historically disparate systems, in terms of how they were managed, their release cycle or control model. It espouses multiple disciplines working together, in a well-integrated delivery model, to deliver value to the business
• It's all about speed/time to market - DevOps enables Continuous Integration and Continuous Delivery, and CI/CD enables speed to market. ITIL is often associated with stodgy old IT shops where the delivery model is to treat developers like second class citizens and to required that people submit a ticket and wait in line for everything - an innovation killer. But this view misses the mark entirely
• ** Point of clarity: DevOps is not "NoOps." NoOps is a mostly-dead idea that's used to describe shops that have migrated to (or were born in) a pure cloud-services model and have no dedicated operations personnel. What companies quickly learn, however, is that not having dedicated infrastructure and operations professionals (whether or not a shop hosts metal) doesn’t scale well beyond early startup – stability, regulatory compliance, operational controls, etc. are necessary regardless of the operational model a company uses. These functions require expertise, experience, and focus that is typically outside the realm and interest of developers.

Public cloud services

DevOps emerged out of necessity in startups that operated in public cloud services from inception. Developers were obviously required to create the technologies that would enable (or represent the core of) the business, and all of the precious little funding that startups typically have is directed at delivering client-facing capabilities. But what about dedicated infrastructure people? Not required in an all-public-cloud world, particularly at startup scale. (This changes with scale but, even at scale, the role is different than it historically was). Suddenly developers found themselves responsible for both creating code and managing infrastructure.

But here's the thing: nowhere in DevOps is there a license to eliminate control and transparency requirements, particularly in regulated companies. There seems to be an understanding that being a DevOps shop somehow absolves a company of the need to meet regulatory/industry-compliance standards (e.g.SOX, SOC II, PCI), or that it obviates the need to implement auditable Change management procedures, or to maintain an authoritative configuration management system, or to have a formal mechanism to track and eliminate recurring incidents (problems), or to manage assets. I could go on.

Complementary models

In reality, ITIL and DevOps are perfectly complementary. In fact, there have been provisions for DevOps since ITIL v3 - even if those provisions weren't designed explicitly for DevOps. In one of my previous positions, I led the development of a hybrid cloud. It was a big shop with thousands of developers. DevOps was adopted whole-heartedly. Within six months of the launch of the hybrid cloud, the developer community had self-serviced their way to building >20,000 VMs. What the developers knew was that they were programatically creating and tearing down operating environment capacity – the liberation of self service and on-demand operating-environment capacity. What they didn't know is that they were all operating in perfect compliance with our IT services management processes and the controls framework.

For all 20,000 VMs, there was a change record created through the IT Service Management (ITSM) suite and a Configuration Item created in the CMDB. Since the creation of a cloud VM was a "standard change," all that was required was a record of the change. No manual change review was required. And that change record was created in an automated way. The same thing with the Configuration Item -- information about the VMs was collected during the instantiation process, and fed through to the CMDB.

Need for mature processes

Why is this important? Less controlled shops cope okay in startups, when the work required to keep track of assets, relationships, etc. is manageable. The need for a more mature process (which, again, doesn't have to represent a lot of friction) emerges at scale and/or when companies become regulated, either by becoming publicly traded and falling under the purview of Sarbanes Oxley, or by being in an industry regulated by another agency or standard like the SEC or FDA.

Keep one thing in mind as you navigate toward DevOps, or as you integrate it more deeply within your organization. The functions included in ITIL will still have to be performed. You'll still need to fix things when they break (incident management); you'll still need to track down the underlying cause of recurring incidents (problem management); you'll still need to know which technologies you're running in your environment and what their relationships are (configuration management). DevOps is a great enabler, but it's a method of execution, not a replacement for an IT services management framework. ITIL is still the definitive reference for that – and it’s alive and well.

See our ITIL section for more information.