Where does the old school fit into a DevOps world?
- Welcome back, to our final section on the building blocks of DevOps. This time, I'd like to talk about ITIL, and IT service management in general. DevOps stands on the shoulders of giants. And there are a lot of concepts from the various ITSM and SDLC frameworks and maturity models, that are worth learning. To this day, my team's Wikispace is organized around the standard ITIL processes, with sections for change management, supplier management, incident management, and so on. But when you implement these processes, you want to use a lean and agile mindset, and need to craft them in a way that's people first, and that doesn't introduce waste or bottlenecks, into the value stream, in the name of standard or best practices. Old crusty IT veterans like myself, who've done ITIL work, but for the kids nowadays, who haven't encountered it, let me explain. First, IT service management. IT service management is a realization that service delivery is an important part of the overall software development life cycle, which should properly be managed from design, to development, to deployment, to maintenance, to retirement. Back in the day, conceptions of the software development life cycle, really just focused on the code writing, and tended to stop at handoff, or if they mentioned deployment and maintenance, went into very little detail on them. In this way, ITSM is clearly one of DevOps ancestors. ITIL, was the first ITSM framework. In fact, it launched the idea of ITSM. So many folks still speak about them as if they're the same thing, even though other ITSM frameworks like COBIT, have emerged since. ITIL, is a UK government standard, grew out of the Thatcherism of the 1980s as the, previously, shall we say, organically managed IT assets, and the UK government, didn't have a lot of alignment and standards. And so their central IT division, published a set of guidelines on how to manage services in the late eighties, and early nineties. This first version of ITIL, was so well done that it peaked interest outside of the UK government. In 2001, ITIL v2 was published with the explicit intent of it being used by others. V3 was published in 2007, and updated in 2011. It uses a process model based view, of controlling and managing services. It can be said to inherit from Deming's plan due check act cycle. ITIL recognizes four primary phases of the service lifestyle. Service strategy, design, transition, and operation. It has guidance for just about every kind of IT process you've ever heard of, from incident management, to portfolio management, to capacity management, to serve catalogs. While all of the high level principles of ITIL makes sense. It's designed to be a fairly prescriptive and top-down framework. While it's not technically against ITIL, to do agile development, or perform continuous integration and deployment or, other such practices, honestly much of the culture, and advice and consultancy around ITIL, assumes a waterfall push driven model of the world. But, it certainly doesn't have to be that way. Gene Kim author of the "Phoenix Project" and the "DevOps Cookbook" and probably the single most avid DevOps evangelist today, founded the IT Process Institute, a nonprofit dedicated to studying IT process, and analyzing best practices around IT performance. In 1999, Kim, along with Kevin Behr and George Spafford, published a slim hundred page book, "The Visible Ops Handbook, Implementing ITIL in Four Practical and Auditable Steps" in 2004. It describes not only the core parts of ITIL that have the most correlation to an IT organization success, but puts forward a roadmap, to implement them in a lightweight manner. "Visible Ops" spread slowly as sort of a cult classic IT book originally. The content of the book was great, but it was also the implications of the book that were truly electric. The idea that you could have well-defined control processes, that were compliant and auditable, but they could be light and agile and, the complete opposite of most ITIL implementations people had experienced. So, using learn from ITIL and its brethren, but think twice before implementing a specific reference process, instead consider what the goal of the process is, and analyze how you would accomplish that in a, lean DevOpsy manner. From CI to the chaos monkey, a lot of DevOps is about taking an alternate path to the intended goal, and finding out it's better than the path established IT wisdom might tell you to take.
In this course, well-known DevOps practitioners Ernest Mueller and James Wickett provide an overview of the DevOps movement, focusing on the core value of CAMS (culture, automation, measurement, and sharing). They cover the various methodologies and tools an organization can adopt to transition into DevOps, looking at both agile and lean project management principles and how old-school principles like ITIL, ITSM, and SDLC fit within DevOps.
The course concludes with a discussion of the three main tenants of DevOps—infrastructure automation, continuous delivery, and reliability engineering—as well as some additional resources and a brief look into what the future holds as organizations transition from the cloud to serverless architectures.
- What is DevOps?
- Understanding DevOps core values and principles
- Choosing DevOps tools
- Creating a positive DevOps culture
- Understanding agile and lean
- Building a continuous delivery pipeline
- Building reliable systems
- Looking into the future of DevOps