Digitalisation in a Post-Covid19 World (3/6)
Fit The Third!
Welcome to the third in the series on Digitalisation and the Digital Maturity Model aimed at helping demystify an often-confusing realm for leaders, by translating technical terms from the argot of engineer-speak to logical constructs that help leaders navigate modern computing concepts.
The first article provided a backdrop as to why digitalisation will accelerate post-Covid19, set out the six aspects of the Digital Maturity Model, and covered the first of these, Cloud Platforms. Then, the second article covered Cloud Native Applications. In this, the third in the series, we look at DevOps – a much feared and misunderstood six-letter word – and Site Reliability Engineering, the meaning of which should become clear as this article unfolds.
Infinite Monkeys
In Fit the Second (part 2 in layman’s terms) of the original radio show of The Hitchiker’s Guide to the Galaxy, the two main characters Arthur Dent and Ford Prefect find themselves on a new spaceship powered by something called an Infinite Probability drive.
The concept is simple. Train an infinite number of monkeys to use typewriters and they will, at some point, come up with the script of William Shakespeare’s play Hamlet (quite by chance). It’s an oblique literary reference to a philosophical thought experiment conjured up by the French Mathemetician and Philosopher Émile Borel in 1913 in his paper Mécanique Statistique et Irréversibilité [in French].
In a similar vein, it’s often said that if you ask a thousand IT folk what the term DevOps means, you get a thousand different answers… Presumably until one of them just happens to land on the correct answer (quite by chance).
Indeed, it can often seem easier to define what DevOps isn’t rather than what it is. This is another example of a lacuna in the workplace, a gap or void.
Whether the above quote, usually attributed to Aristotle, is true is the physical world or not, it is certainly true in the world of concepts and ideas. People faced with no explanation will invent one. But, when it comes to DevOps the information is out there (there’s some excellent resources listed later).
Ethos
Speaking of Greeks, it was they who came up with the word Ethos, which Lexico defines as: “The characteristic spirit of a culture, era, or community as manifested in its attitudes and aspirations.”
Despite being a great fit for what DevOps is (an ethos), so far so vague. Back, then, to what DevOps is not (anti-defintions, of a sort):
- Developers doing operations
- Operators doing development
- A double-headed hydra that can somehow do both
- An army of infinite monkeys
- 42
Stitching together the various definitions and anti-definitions allows us to arrive at an understanding that one of the things DevOps is about – arguably the main thing – is teams working together to achieve quality deliveries without introducing unnecessary delay. What can we deduce from this? Well, if you take away just one thing from this article, let it be this:
If you have a DevOps team in your organisation, you are by definition, and therefore automatically, doing DevOps wrong
For an ethos to manifest in the attitudes and aspirations of a team does not mean you should create a team with that name. That’s knee-jerk reactionism, which creates it’s own organisational structural issues for the future. Rather, creating an ethos involve infusing the culture and spirit of DevOps into existing (and future) teams created for delivering operational products.
Another way to look at this is that DevOps is about breaking down silos and creating an atmosphere where the business and technology work in tandem. Creating a DevOps team encourages silos and fosters the “Them and Us” culture that serves a nothing more than a CYA insurance policy for the leader that creates it or worse, an irreverent sortie into politics (itself no more than a mechanism for the obfuscation of present or future conflict).
The leader that strives to achieve better value for the organisation does well to guard against the creation of such teams at all times.
Site Reliability Engineering (SRE)
If DevOps is about an ethos for delivery, what then is Site Reliability Engineering, commonly referred to as SRE? It’s the same spirit, the same ethos, as DevOps, but with the focus on keeping software running, stable, and in efficient operation at all required times. I’ve added the word required because there may be times when a software resource should not be up and running – if it is up at such times, then it’s behaviour is unreliable.
One way of looking at it is that SRE is the post-production sibling to DevOps. For SRE, it may make sense to have a team that wears an eponymous badge, but the ethos is grounded in the same roots as DevOps. This means the SRE team need to work in conjunction with the teams that deliver code and must be able to reject code that could jeopardise the reliability of the site. In this context, site means the site of operation, which may, or may not, be a website.
Additional Resources
Web resources
- If you want to dive into the roots of DevOps, a great resource is The Origins and Culture of DevOps, by .Mastery. It does cost a nominal amount (about as much as a good meal out… er, in), but it’s well worth it to get the history and get a grounded explanation.
- Should time / budget be limited, a succinct, free explanation (without the in-depth history), can be found in Episode 14 of the Wicked Problems podcast, with Martin Walsh (of Think Above Cloud).
Books
The following books are also worth investigating:
- The Phoenix Project: A Novel about IT, Devops, and Helping Your Business Win Paperback by Gene Kim and Kevin Behr
- The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, by Gene Kim , Patrick Debois , et al
- Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren and Jez Humble
The first Ten Million Years...
As a warning for those who do want to rush off and create siloed DevOps teams, potentially with a million monkeys, I’ll close with these words from Marvin, the paranoid android, from The Hitchhikers Guide to The Galaxy in the second part of the series, The Restaurant at the End of the Universe:
DevOps teams may tick a box temporarily, but longer term may create a problem that even an infinite number of monkeys won’t solve.
Before you go...
If you’ve found this article informative, please consider sharing it with colleagues and others in your network.
Next time...
In the next article, we’ll cover the fourth aspect of Digital Maturity: Agile Delivery. Don’t worry, it’s also aimed at leaders, not engineers.