DevOps
In recent years the term ‘DevOps’ has come to refer to a set of practices and approaches to building software that emphasise strong cooperation and collaboration between the various teams involved in building software (especially development teams and operations teams, hence Dev & Ops, or ‘DevOps’). DevOps recognises the harm done by the IT outsourcing craze of the early 21st century (and by ongoing CAPEX/OPEX[1] budget splits) where the development and operation of software systems were/are treated as quite separate activities, rather than being two equally important parts of producing valuable, working software, requiring close communication between teams in order to avoid costly bugs and outages in Production.
The speed with which IT infrastructure can now be ordered, configured, and made available – thanks in part to virtualisation technologies and ‘cloud’ hosting – has driven a need to define and manage much IT infrastructure using software techniques to take advantage of the rapid time-to-market now possible. Version control, test-driven development, continuous integration, and deployment pipelines – all established software development practices – are increasingly being used to automate and test activities that were once manually undertaken by system administrators: this is termed ‘infrastructure as code’.
The increase in speed combined with greater automation has led to the need to establish a strong trust bond between different teams and roles involved in the software systems, which in turn turns a spotlight on the culture within (or between) organisations. Those organisations with a ‘blame culture’ tend to find it difficult or impossible to achieve sustainable, rapid delivery of working software, whereas more open organisations where learning and cooperation are highly valued find this easier.
DevOps and Operability
The four ‘pillars’ of practice that support the collaborative DevOps approach are Culture, Automation, Measurement, and Sharing (CAMS)[3], but none of these pillars is a goal of DevOps in themselves; these are means to an end. Using the CAMS pillars of DevOps, organisations aim to build and operate software that works well in Production. Since software that works well in Production is by definition operable, good software operability is really one of the goals of DevOps.
ITIL and ITSM
The body of valuable knowledge and effective practice contained in ITIL (and other IT Service Management (ITSM) guides) is at its heart pragmatic and well-meaning, being based on real-world situations involving the management of IT services. ITIL/ITSM are often criticised for being too ‘heavy-handed’ with respect to change control, and too ‘anonymous’ with respect to a faceless, ‘hide-behind-tickets’ approach to customers; some people claim that ITIL prevents the rapid and frequent changes which modern organisations demand. However, much of the clumsiness associated with ITIL arguably derives from poor, over-complicated implementations (often by ‘experts’) that have lost sight of the real drivers for auditable change control: better fault diagnosis, rapid restoration of service, cross-service incident response and coordination, etc. [4]
ITIL and Operability
By using aspects of ITIL we can capture and reason about operational criteria of software at a sufficiently early stage to be able to test and modify the operability before software reaches Production. With appropriate conversations and interactions with development teams during Service Design, Service Transition, and Service Operation, we can avoid a tendency towards operational costs increasing over time as ever more byzantine fixes and workarounds are applied to software which is itself not operationally ready.
Furthermore, by heavily automating the acceptance and auditing of Standard Changes, we remove much of the ‘bottleneck’ often caused by process-heavy ITIL implementations, freeing up time for reviewing (and possibly automating) aspects of Major Changes. More time is also available for greater collaboration with the software development teams about forthcoming software changes and deployments, which helps the operability of the software to improve (see The software development team writes a draft Run Book).
DevOps + ITIL + Operability
DevOps focuses on high quality collaboration between development and operations teams in order to make software work better. ITIL helps to ensure that we have an audit trail for changes, that we consider operational criteria for software, and that incidents are handled effectively, all of which can also help to make software work better. By identifying operability as a key concern for both development teams and operations teams, we can bring DevOps and ITIL together in order to build and run resilient, so called ‘antifragile’ software systems.
In The Visible Ops Handbook, software operations experts Kevin Behr, Gene Kim, and George Spafford recommend an approach to ITIL which shares much with the aims of DevOps [5]. Rob England (‘The IT Skeptic’) has written on why and how DevOps and ITIL are compatible and complimentary, as has Jez Humble, co-author of the book Continuous Delivery [6]: they argue that the real goal of both DevOps and ITIL is to produce resilient, antifragile software systems. An explicit focus on operability for all teams involved in building and operating the software helps to reinforce this goal. [7], [8]
References and further reading
[1] Capital expenditure vs. operational expenditure. In the USA, UK, India, and other countries, CAPEX attracts tax breaks, whereas OPEX does not. Software development is typically CAPEX, and software operations OPEX.
[3] J. Willis, ‘What Devops Means to Me | Chef Blog’, 16-Jul-2010. [Online]. Available: http://www.getchef.com/blog/2010/07/16/what-devops-means-to-me/ [Accessed: 12-May-2014].
[4] R. England, Basic Service Management: A 50-page introduction to providing services. Porirua, N.Z: Two Hills, 2011.
[5] K. Behr, G. Kim, G. Spafford, and & 0 more, The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps. Eugene, OR: Information Technology Process Institute, 2005.
[6] J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, 1 edition. Upper Saddle River, NJ: Addison Wesley, 2010.
[7] J. Humble, ‘On Antifragility in Systems and Organizational Architecture | Continuous Delivery’, 09-Jan-2013. [Online]. Available: http://continuousdelivery. com/2013/01/on-antifragility-in-systems-and-organizational-architecture/ [Accessed: 12-May-2014].
[8] R. England, ‘Kamu: a unified theory of IT management – reconciling DevOps and ITSM/ITIL | The IT Skeptic’, 05-Feb-2013. [Online]. Available: http://www. itskeptic.org/content/unified-theory [Accessed: 12-May-2014].