ITIL and DevOps - Archenemies or Complementary Models?

Dave Blodgett, Managing Director, CIO & CISO, HedgeServ

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, such as with Amazon AWS, Google GCE, etc.). 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), 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

Less controlled shops work okay in startups, when the ratio of scale and velocity to the people required to keep mental track of assets, relationships, etc. is pretty low

• 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, control model, etc. 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 require 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.” The latter 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 a necessary “thing” 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

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 (that changes with scale, but even at scale, the role is different than what it was historically). 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, etc.), 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, etc. I could go on.

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 well adopted. 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 programmatically creating and tearing down operating environment capacity—the liberation of self service and on-demand operating-environment capacity. What they didn’t know was 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 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 required. And that change record was created in an automated way. The same thing with the Configuration Item—information about the VM(s) was (were) collected during the instantiation process, and fed through to the CMDB.

Why is this important? Less controlled shops work okay in startups, when the ratio of scale and velocity to the people required to keep mental track of assets, relationships, etc. is pretty low. 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, the FDA, etc.

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), etc. 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— alive and well.