People seem to have a hard time deciding what DevOps even is, much less how (or whether) it compares to a highly structured methodology like ITIL. To answer the big questions up front: no, you don’t have to choose between DevOps and ITIL; no, DevOps is not replacing ITIL or vice versa; no, DevOps will not solve all the problems of an ITIL environment, and no, DevOps will not be perfected by implementing ITIL. While DevOps is essentially a philosophy, a perspective on how to address the problems faced by development and operations teams (not) working together, ITIL is a codified system of information technology service management (ITSM) designed to better integrate IT with business needs and strategies. So while there is some overlap, these two systems address different core issues. The best way to approach them is through whatever problem(s) you are trying to solve. Before you can implement either, you have to take stock of what you have and spend some time thinking about what you need. We’ll look at a few common scenarios that bring people to ITIL and/or DevOps and how each system can help. Before we compare them, let’s first define DevOps and ITIL in and of themselves.
DevOps began in a software development environment and as such many of its methodologies and tools focus on improving software deployment. Continuous Integration (CI) and continuous delivery (CD) transformed the deployment process, while continuous monitoring provides near real time visibility into the entire infrastructure. But DevOps is about more than Agile software development.
The hybridization of developer and operator duties spilled over into all aspects of IT, simply because sharing information and working together towards business goals is more productive and creates a better work environment than traditional knowledge siloing. Part of the reason DevOps is commonly described as a philosophy is that transforming an organization with its ideas requires taking a step back and reassessing some of the most basic assumptions of IT work.
Rather than specialized individuals handling a discrete piece of the overall system and assuming (or not worrying about whether) it all works together, DevOps teams try to view the IT process holistically and modify their individual work to best suit business needs. This means coders learning systems, ops people learning to code, everyone learning security and project management/collaboration. But this is more than traditional cross-training, because DevOps is about changing core practices with cross-disciplinary ideas, such as infrastructure as code, where fragile snowflake servers are replaced by repeatable, scalable deployment processes that can be matched to development, test, QA and production environments.
Unlike DevOps, ITIL is a highly structured methodology designed to increase efficiency and provide statistics for IT operations. ITIL is a type of ITSM and as such focuses primarily on protocols for implementing, managing and improving IT services to the business and/or customers.
Because ITIL is so highly structured, there are many specific terms and concepts that must be learned in order to utilize it effectively. Since 2013, ITIL has been the intellectual property of AXELOS, who license ITIL materials, offer certifications and update the ITIL framework. This means ITIL is a proprietary system governed by a private, for-profit company, rather than the amorphous, ownerless philosophy of DevOps.
The complexity and rigor of ITIL creates some overhead for IT shops, as ITIL will only operate as well as it is implemented. This means a significant investment of both time and money into creating an ITIL team. ITIL preceded DevOps, so obviously there are some areas where ITIL still wasn’t meeting the needs of some organizations. Let’s look a few common scenarios and how DevOps and ITIL can assist with them.
“The software delivery process needs an overhaul.”
Problem: The high demand on software requires much quicker turnaround of fixes and updates, as well at the integration of testing and QA into the development process. The traditional methods of deployment aren’t letting us keep up with the market.
DevOps: Software delivery is DevOps’ bread and butter. From the toolchain to the philosophy, DevOps centers on this process specifically, although it has expanded beyond that into general IT. The powerful automation of a tool like Puppet or Chef, along with a configuration monitoring and testing tool like UpGuard will help create and maintain standardized environments between development and production.
ITIL: ITIL has a very specific framework for delivering software and focuses more on integrating the delivery process into other business processes by defining stakeholders and establishing protocols. This complements the DevOps side well, because while DevOps has general principles, ITIL has detailed guidelines to follow.
Solution: DevOps is crucial to this process, whereas ITIL can fit, but isn’t required. ITIL by itself, however would miss many of the innovations DevOps brings.
“IT is a ‘blackbox’ to the rest of the business.”
Problem: The business lacks visibility into its own IT processes. A lack of concise, objective metrics prevents IT and management from seeing eye to eye on everything from budget to strategy. IT people feel unappreciated and isolated, while managers and executives feel distrustful of IT or like it is a necessary (and costly) evil.
DevOps: DevOps does help IT better align with business, but this is mostly a side-effect of other efficiencies. Gaining visibility into the technology environment is the first step toward integrating IT into the business, and DevOps practices result in high visibility, especially with tools like ours, which provides a comprehensive view of configurations, as well as a visualized executive summary.
ITIL: One of the main thrusts of ITIL was making IT explicable to other parts of the business and providing structured methods and objective metrics for IT performance. ITIL resembles other basic business process models, so non-IT people will have an easier time following along with otherwise arcane details. By providing data by which to judge ticket resolution, development progress, incident response and infrastructure improvements, the ITIL framework can help give businesses metrics on which to base their decisions.
Solution: ITIL has the advantage here, since it is geared precisely to this problem, but DevOps has a few tricks up its sleeve as well, with visibility and logging tools that can make enacting ITIL processes more feasible. DevOps by itself can help by starting a culture change that makes IT professionals more aware of their role in the business and more invested in making choices that support the big picture, instead of just one piece. Chances are pieces of both can help alleviate this problem.
“Knowledge silos in IT are bottlenecking projects and lowering morale.”
Problem: Sysadmins know the systems, developers know the software, network admins know networks, but that knowledge is siloed inside a section (or individual) and information is rarely shared, with finger pointing ensuing whenever there is an issue.
DevOps: Along with software delivery, breaking down IT silos was one of the main points of the DevOps movement. Anyone who’s worked in IT knows how difficult a knowledge silo can make things. DevOps practitioners often use the word empathy, because putting yourself in someone’s shoes and trying to understand the choices they made is the key to collaboration. Tools like Slack or a Kanban board can help keep teams connected and visualize work-in-progress.
ITIL: Technically ITIL can help with knowledge siloing because if everyone follows the strict methodology, everything should be documented. But in practice, ITIL may not help with knowledge siloing at all and can even create additional silos, such as “the person who knows about ITIL.”
Solution: DevOps, in its very name, is about bringing formerly disparate teams together. If knowledge silos are your problem, a DevOps approach may be your best bet to breaking them down, because it focuses on the human aspect, which factors heavily into why knowledge is or is not shared. The ITIL framework, especially if it's something you already have in place, can help regulate protocols, but should not be seen as a replacement for the ideas and tools DevOps brings to the table.
“Trying to get a change done is a nightmare.”
Problem: Current change management processes are ineffective, overbearing or non-existent. Operations people don’t want to make changes because it means downtime. Developers want constant change to the environment to support the changes they make in the software. Unplanned outages are usually the only way anything ever gets done, and by then it's too late.
DevOps: One of the biggest problems with structured change management is that the process can overtake the people and sometimes even the goal. Changes getting rejected out of hand become more common and the avenues to get them approved become narrow and crowded, creating a bottleneck out of a process that was meant to streamline. If this is more your problem, DevOps principles can help: collaboration, face-to-face engagement, empathy: these things, as simple as they sound, can turn a restrictive change management process into an effective one.
ITIL: ITIL is one of the most popular change management processes available, and if your problem is that you don’t have a good way to manage change at the moment, ITIL could be exactly what you’re looking for. Because change can be so contentious, having a written protocol on how it is handled reduces stress and gives people something to reference if opinions are clashing. But it still is susceptible to the caveats above and for some people is even worse than no change management at all.
Solution: ITIL has the framework, DevOps reminds you real people are involved. If change management is your big problem, remember tools and frameworks aren’t enough to fix it: the people involved still have to buy in and follow the framework and use the tools for real improvements to happen. Failure to achieve buy in results in slowing an IT team down even more.
“I don’t know what problem I’m trying to solve, but I keep hearing about DevOps/ITIL!”
Problem: You’ve heard a lot about DevOps, ITIL and other systems that are reinvigorating IT departments, or at least getting a lot of buzz in the tech world, and you want to know if and how it could help your environment.
Solution: Be careful falling prey to buzzwords and pie in the sky promises. A CTO might attend a conference where someone mentions DevOps and go back to his or her team and say “let’s do DevOps” without really knowing what that entails. A careless implementation of a methodology will create more problems than it solves and more work than it reduces. On the upside, knowing enough to ask the question means the awareness of a new way exists. But the variety of information can be overwhelming, especially to someone new to the topic. Instead of trying to wrap your head around entire systems, start with the problems you’re having and the goals you want to reach. Then figure out how DevOps and/or ITIL can help.
It doesn’t make much sense to try and compare ITIL and DevOps in a vacuum. Instead, compare them based on the problem you’re trying to solve and focus on the tangible benefits you and your team would see from each. ITIL focuses on process, standardization and metrics. DevOps adds in the human element and explores how teams can collaborate to achieve more than their individual efforts alone. Chances are both methodologies will have something to offer and give you at least a starting point on how to improve your operation.
For more details on ITIL and DevOps, check out UpGuard’s free eBook, The ITIL Guide to DevOps:
Chances are you’ve browsed to an online IT community looking for information about a technology. But taking full advantage of them means understanding how they work and what they can do for you.
Read Article >
Any way you slice, it, DevOps means thinking about making quality software quickly–and that definitely includes security.
Read Article >