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. But building good IT processes is they key to resilience, and UpGuard can help.
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.”
“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.”
“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. UpGuard validates IT processes in whatever methodology you use. Don't wonder if your processes are working. Visualize them.