We've spent a lot of time with organisations in recent years trying to define DevOps - and it's clear that although we know that at the core of it DevOps is about making better software faster and more safely, there is a lot of differing opinion about its definition, partly because its breadth is huge (organisational disciplines, streamlined interactions, automation) and also because of the resistance to putting any kind of framework or manifesto around it (because ITIL and Agile have had problems with this and because DevOps is based on experimentation - there is no 'one size fits all').
That said, my personal favourite definition of DevOps comes from Jesse Robbins:
"Don't fight stupid; make more awesome."
I love the simplicity of it and the almost haiku-esque poetic quality. What I've found more useful though, is thinking through what's different about DevOps? Or trying to answer the question: "Why has DevOps got so much currency in today's market?" - you just have to do a search on the keyword in Google trends to see how popular the term has become. So why such a buzz about one portmanteau or Frankenword? I think there are three key drivers:
and its Impact on Traditional IT Organisation
The transformation of the way we do business as consumers and service users/providers with the advent of the internet a couple of decades ago has accelerated the pace of innovation organisations have to deliver in order to remain competitive. Businesses put development under pressure to push change through to delight their end-users. At the same time, infrastructures have evolved over several decades and become very complex; heterogenous environments, service oriented architecture, integrations between systems and to third party services - all of this adds up to fragility. So we have Dev teams pushing change and Ops teams focussed on stability: the teams' goals are in direct opposition to each other. And in a traditional IT organisational set up these teams have separate reporting lines and are often physically separated too - on separate sides of a corridor, separate floors or buildings either. This conflict manifests itself in many ways:
- Dev complains that Ops take too long to deliver an environment
- Ops complain that Dev are asking for access to production environments
- Outages result in 'war rooms' where blame is laid
- 'Release weekends' occur where already stressed employees work out of hours
- Unplanned work makes it impossible to find time to save time
2) Agile, ITSM and Lean
and the Convergence of These Approaches to Interactions
The increasing prevalence and maturity of iterative development approaches (Agile), better controls and understanding of IT operations process (ITSM) and constant streamlining (Lean) is resulting in a convergence of these disciplines; what Jayne Groll referred to on a CrowdChat recently as: "The happy, polygamous marriage" of DevOps.
and using Automation to build a DevOps Toolchain
The last five or so years have also seen new tools arrive on the scene that enable us to do things we simply haven't been able to do before such as:
- Release and deployment automation
- Service virtualization
- Business transaction monitoring
We don't build DevOps toolchains JUST for speed though - we also do it for traceability. We have to be able to tie our development and delivery efforts back to the business goals. The ultimate measure of DevOps: "aha to kerching".
DEVOPS GOAL: Measuring Ideation to Realisation.
DevOps does mean different things for different people for sure, but there are patterns in DevOps that we have observed in the past few years of working through DevOps Transformations.
Next week I'll kick off a three part blog series on DevOps Patterns:
Week One: Organisational Patterns
Week Two: Patterns in Interactions
Week Three: Automation Patterns
See you then! Stay DevOpstastic ~=>