This is the second in a series of 7 blogs inspired by Rudyard Kipling and DevOps! Having started the series with Why DevOps? My trip through Kipling’s trusty serving men stops at What is DevOps? I will also take a stab at answering the question of what DevOps isn’t.
As the name suggests DevOps finds its roots in those old foes of the IT department namely the DEVelopment and OPerationS domains. DevOps is the meeting point of systems, culture and technology where operations and development engineers work together in the entire service or product lifecycle, from design through the development process to production support. This is a step change where previously lifecycles involved painful hand offs between various domain based IT teams. Much waste, much frustration, much failure. The goal of the DevOps way of doing things enables an organisation to quickly realise value from effective flow of work from development (software engineering) through test (quality assurance) and deployment while preserving operational reliability, performance and security (technology operations). It’s really what we’ve always wanted from IT but this is a radically different approach to achieving those ideals.
The essence of DevOps can be best summed up in the 5 elements described by the acronym “CALMS”.
C is for Culture. Patrick Debois, a godfather of the DevOps movement, always says DevOps is a human problem. Perhaps the trickiest aspect is the culture shift which fundamentally means changing entrenched attitudes and behaviours of Dev and Ops engineers. Trust, sharing, co-operation must become endemic for DevOps to succeed. Think about how difficult it might be to change a conservative organisation into one which embraces experimentation!
A is for Automation. Computers snooker humans time and time again at performing regular tasks over and over. Automating repetitive, time-consuming, error-prone release tasks pays enormous dividends. Areas such as automated testing, automated builds, infrastructure-as-code are prime candidates to be automated. You might even be adopting artificial intelligence in support. Automation is a key aspect to improve speed, consistency, and quality.
L is for Lean. Quite simply the same lean practices that were applied to manufacturing in the 1980’s are being applied to IT now. So we ask ourselves do we understand the end-to-end process we use to deliver value with software to our customers? Can we find inefficiencies and waste? In DevOps environments get used to hearing Japanese words associated with the founding fathers of Lean at Toyota. Muda, Muri and Kata will become part of your dictionary.
M is for Measurement. “You can’t manage and improve what you don’t measure” is a phrase that has been uttered by many a management and systems guru. It’s true you know. We need to track metrics associated with actual outcomes our customers want to achieve. We can use the information to drive feedback loops and decision-making. Measuring aspects of your engineering and business operations will yield valuable insights so you can respond faster and improve.
S is for Sharing. Good communication improves performance. Your culture (see above) will directly affect this. Optimising information flow between people, teams, functions, and levels within the organisation is a goal of DevOps. Quite simply the more you share the better you will perform.
So here is a view of what DevOps isn’t……
- DevOps is NOT a silver bullet – if only life were that simple. Don’t fall for the cheap sales talk…Silver Bullets, Santa Claus and (sadly) England World Cup winners 2018 all have something in common!
- DevOps is NOT a team – you don’t breakdown one set of silos (Dev and Ops) to create another (DevOps). That’s madness!
- DevOps is NOT a set of tools – Don’t ever tell me you’re “doing DevOps” just because you’ve bought Jenkins and use Trello boards!
- DevOps is NOT anarchy – Leave ‘Anarchy in the UK’ to the Sex Pistols. Governance and rules exist in any world and DevOps is no exception
Finally, DevOps is NOT a one size fits all strategy. Remember your history when we told you no two organisations are the same and therefore no two organisations “do the ITIL” the same way. Well ditto DevOps. So please, please, please when listening to presentations from the guys at Etsy, Amazon and others remember what worked for them was situational. Imitation may well be the sincerest form of flattery but it’s the quickest route to disaster too.
Its situation I tackle in Part 3 of this DevOps/ Kipling series when I ask the question “When” to start.
Missed part 1 of why DevOps? Catch up here.
Global Product Director