Top 5 IAST Tools for 2022
The trouble with allowing developers to deploy code directly to production is that security threats are often overlooked in the process. These vulnerabilities only show up
You’ve heard of DevOps. You’ve heard of ITIL. And you’ve likely wondered: Which of these two concepts should guide your approach to IT operations and software delivery change management?
After all, DevOps and ITIL can feel mutually exclusive in many ways. That’s especially true when it comes to the vital issue of IT change management. Whereas DevOps encourages “continuous everything” and lacks a specific strategy for managing change, ITIL establishes particular processes for handling changes in a structured, incremental way.
That doesn’t mean, however, that DevOps and ITIL are mutually incompatible. You can apply both concepts to the work you perform in IT. But what are the similarities and differences between DevOps and ITIL, particularly when it comes to change management?
The IT Infrastructure Library, or ITIL, is an industry-standard set of best practices that IT organizations can use to structure their operations. The framework was developed by AXELOS, a British government initiative whose goal is to establish best practices within various industries and domains. The ITIL summarizes AXELOS’s recommended best practices for organizations in the IT industry.
Because the ITIL is simply a set of recommendations rather than a law or regulatory compliance framework, no one has to follow it. However, businesses commonly turn to the ITIL recommendations as guidelines for managing their IT processes.
The ITIL devotes considerable coverage to change management. It lays out a specific set of procedures that IT organizations should follow when changing systems, processes, teams, or other resources.
However, it’s important to note that different versions of the ITIL address change management in different ways. ITIL 3, which appeared in 2007, took a rigid approach to change management. Most notably, it recommended that changes be approved by a Change Advisory Board (CAB) before implementation.
ITIL 4, released in 2019, is much more flexible when it comes to change management. Its approach is embodied in its “change enablement” instead of “change management.” The shift toward a language of “change enablement” positions change as a natural and desirable part of IT operations instead of a challenge that organizations have to manage.
The ITIL also mostly does away with the idea of requiring CAB approval for changes. It suggests a CAB review for significant changes. But it recommends that teams make minor changes without an extensive review process.
ITIL 4 also recognizes that not all changes are of equal complexity or priority. It recommends simpler and faster implementation of minor modifications and modifications necessitated by an emergency.
In these ways, the most recent version of the ITIL reflects some of the thinking at the core of DevOps (which we discuss in more detail below). DevOps aims to make change seamless and continuous. ITIL 4 doesn’t go that far, but it does enable faster, more efficient changes than earlier ITIL versions.
Nonetheless, even in ITIL 4, change management is a structured affair — which is one of the critical differences between ITIL and DevOps concerning change management. According to the ITIL, organizations are supposed to approach change management deliberately and follow specific procedures.
Alongside ITIL, DevOps is another popular point of reference that businesses use to guide IT operations today.
The idea at the core of DevOps is that IT processes are more efficient and reliable when developers and IT operations teams closely coordinate their activities. The main goal of DevOps is to ensure that developers design and build applications that support the needs of the IT engineers who have to maintain and deploy the applications. At the same time, DevOps encourages IT engineers to communicate continuously with developers to ensure that developers understand which challenges IT engineers face when managing applications.
Unlike ITIL, DevOps is not a formal framework. Indeed, although there are many resources devoted to DevOps, there is no specific text or set of rules that define what DevOps entails. Nonetheless, DevOps has become a widely influential concept for shaping IT operations today.
Because DevOps is a philosophy rather than a formal framework, it makes no formal recommendations regarding change management.
Still, DevOps encourages specific approaches to change management by promoting continuous, automated processes. If you take a DevOps-based approach to software delivery and IT operations, you aim to release new application builds quickly and repeatedly. Your environment constantly changes as a natural part of the DevOps lifecycle. Although testing and validation are essential within DevOps delivery chains, DevOps teams also embrace concepts like “failing fast”. That means that if you break something because of a change, you make a new change to fix it.
Given the fast-paced, highly dynamic mindset at the core of DevOps, the rigid, slow change management process that the ITIL promotes can feel foreign to organizations that adopt a DevOps approach. When you’re shooting to automate everything and make changes as rapidly as possible, you don’t have time to consult CABs. That’s true even in the case of relatively significant changes, like adding nodes to a cluster or deploying a new monitoring tool.
A direct comparison between ITIL and DevOps from the perspective of change management is difficult, given that DevOps doesn’t make any explicit recommendations about change management. Indeed, since DevOps is a philosophy (and an ambiguously defined one at that), not a framework or set of best practices, may seem like comparing DevOps and ITIL change management is like comparing servers to toasters: They’re different sorts of things.
Nonetheless, it’s possible to identify a little common ground between ITIL and DevOps regarding change management. Both recognize that change is essential.
In the case of DevOps, change is at the very heart of what DevOps is all about. DevOps focuses on achieving speed and agility to implement rapid change.
Change plays a different role in ITIL, where it’s a process that IT organizations have to manage rather than a core focus. But it’s still an essential element of the framework.
You could also argue that DevOps and ITIL are similar in that they both recognize that change needs to be managed somehow. DevOps is not very specific about what change management should look like. Still, if you look at some of the core practices associated with DevOps — like tracking versions in source code, preparing for rollbacks, and using auto-scaling policies to manage scale changes — it’s clear that DevOps offers many tools to assist with change management, even if engineers don’t typically think of these tools as change management solutions per se. And in ITIL, as we’ve noted, change management is formally structured through specific practices.
Finally, it’s worth noting that DevOps and the ITIL share an understanding that change management should involve all stakeholders. The primary purpose of DevOps is to promote collaboration between developers and IT operations teams to achieve better business outcomes. ITIL is more IT-focused, and it doesn’t really address development operations, but it nonetheless suggests that more-than-minor changes need to be planned and approved by multiple people or teams, never just one engineer.
ITIL | DevOps | |
Formal recommendations on change management | Yes | No |
Provides specific steps to follow when managing changes | Yes | No |
Changes require Change Advisory Board approval | Sometimes | No |
Promotes continuous, rapid change | No | Yes |
Encourages involvement of all stakeholders in change management | Yes | Yes |
Degree of safeguards against undesirable changes | High | Medium |
Encourages “fail forward” approach to change | No | Yes |
So, which concept should guide your approach to IT — ITIL or DevOps?
For most organizations today, the best answer to that question is “both.” You can draw on DevOps and ITIL to build a change management process as agile as possible.
While DevOps is great for helping teams to move quickly and innovate rapidly, the structure and deliberation that ITIL recommends can serve as safeguards to prevent DevOps processes from overheating. CABs are overkill for most changes, but maybe they’re worth consulting when you need to make a massive change to your environment or processes, like migrating from VMs to containers.
So, instead of thinking of it as ITIL vs. DevOps, treat both as a way to guide and optimize your team’s approach to IT operations and software development. Both concepts have important lessons to offer, even if they take markedly different approaches.
The trouble with allowing developers to deploy code directly to production is that security threats are often overlooked in the process. These vulnerabilities only show up
In 2022, the adoption of infrastructure as code (IaC) soared, with IaC domain specific languages like HCL, Shell and GoLang gaining popularity and momentum across the
If you use the Azure cloud, Azure security groups should be on your radar because they’re a fundamental component of securing your resources. As we move