The Five Elements of Devops
Decoding modern business value
From the day the term Devops was coined, it’s been used, misused, counterfeited and mystified.
Research shows that technology delivery performance is a direct driver of business performance. Devops drives that performance. This means understanding Devops now matters throughout an organisation.
Here’s a clear, straightforward way to parse this seemingly cryptic currency of high-performing organisations.
Why does Devops matter?
Lets step back before we dive in and look at a couple of key takeaways from the research findings presented in the influential book Accelerate:
The most exciting discovery came during the first year of research, when the team found early evidence that IT performance does matter. This showed that companies with high-performing technology organizations were twice as likely to exceed their profitability, productivity, and market-share goals.
Put simply, building high-performing technology teams is how you thrive in our digital world. It doesn’t end there though: the authors are clear that this is as much about engaged senior leadership mindset as it is about team and technology design.
High performance means integrated performance.
It’s reassuring to note the factors that are not correlated with technology performance: large or small, mainframe or digitally native, green- or brown-field, organisations are still just as likely to be low or high-performing.
There’s an urgent note in the findings too: the gap between high- and low-performing organisations grows year on year. As transformed organisations pull ahead, those that don’t or won’t cross the chasm from past to present fall further behind. Transformation has a half-life: the unchanged will eventually disappear.
Decoding devops
On a practical level, devops is about commoditising and automating the mechanistic aspects of delivering working technology to meet user needs. The reason this matters is that optimising for speed, rather than cost, turns out to be key.
Time-to-market or, more specifically, the distance from innovation to meeting user needs. Short cycles, small batches and minimum friction are great for delivery of value and recovery from outages — and for forward momentum and continuous feedback.
There are four stages of activity in modern technology delivery: develop, build, deploy and run. Investing in automating build, deploy and run increases speed, correctness, visibility and repeatability by reducing or removing human effort, whilst at the same time, focusing that human creative energy where it can have the most impact: understanding, designing and developing.
I’ve not seen these stages called out explicitly but if you look at CD thinking, you’ll see these stages are there in the pipeline, for example Weaveworks Flux: https://github.com/weaveworks/flux/blob/master/site/images/deployment-pipeline.png
Develop
This is where the right people are your greatest asset. If you know how to activate a high-performing team, you have the potential to really build value with technology. This is where an integrated, Westrum generative culture becomes a multiplier for individual and team performance.
If we shift our language around software development from “engineering” to “design”, it becomes clear that it’s a creative activity. Creative work thrives in a conducive and supportive environment, but struggles under pressure and distraction. Climate control will be far more effective than command and control here. Collaboration is more powerful than control.
Build
This stage can be summed up by the term “continuous integration”. The design and development stage delivers source code into a version control system, typically Git. This can include digital signature of code changes to establish provenance and integrity of code and acts as a hand-off into the build stage.
The job of the build stage is to turn source code into deployable software. In needs to monitor version control and, when a new version is available, step through a process that turns the updated code into a deployable unit. Typically this means compiling the code (if necessary), running a suite of automated tests contained in the code to ensure it works as expected and packaging the result into a container image, which is handed off to a container registry, ready for deployment.
This stage is normally pretty well automated using Continuous Integration (CI) tools such as Jenkins, Travis, Drone or even just a Docker multi-stage build. CI is one of the earliest areas of software delivery. Automation started to become the norm around the turn of the century.
Deploy
Deployment is an area of software delivery that is openly imperfect and working its way to maturity. Tools like Spinnaker and Helm live near the dangerously complicated end of the spectrum, whilst more basic approaches like Gitops show that there are simpler, less abstract ways to automate deployment. Behind the shiny logos and websites, the reality is that organisations famous for doing it well have built bespoke systems that meet their specific needs. This seems an area ripe for innovation.
The job of the deployment stage is to be the change agent. It needs to spot that a new version of a container image has been uploaded to the registry and execute the necessary deployment actions so that the updated software becomes part of the running system.
There are a number of strategies here with colourful names like “blue-green” and “canary” deployment, but the overall aim is to ensure the changed unit of software can be released to users with no downtime and, in the event of an issue, impacting the minimum number of users for the shortest possible time.
Run
This is the place we need to get to. If we don’t deliver working software that meets user needs, then our hard work has been in vain. This is where the investment in design and development pays off. Getting here smoothly, quickly and continuously is a hallmark of high-performing Digital organisations.
The job of the run stage is quite simply to serve users. Based on a deployment configuration, success here is delivering a correct, consistent, reliable and performant service.
Kubernetes is the current enterprise darling in this space, with Google and Amazon both providing managed services, as well as some intrepid organisations building their own clusters, either in the cloud or on-premise. For all its size, complexity and bleeding-edge momentum, Kubernetes (also knows as k8s for short) isn’t the only game in town. Function-as-a-Service platform such as AWS Lambda also sit in this space. If you’re running a handful of microservices it’s worth considering whether a basic solution could be a better option. Complicatedness is, in and of itself, a risk.
Curiosity killed the copycat
Note that it’s important to start your own devops journey, from where you are and develop iteratively. There’s a wide and sensible road to failure that believes in copying what other organisations say they do. It’s imperative to understand that their state of the art is specific to their context, was built up over many years and, crucially, continues to develop at pace.
This means that not only are you unlikely to build something that works for your situation and scale, but by the time you’ve taken your best shot at building someone else’s world, the organisation you’re attempting to emulate will have moved on down their path and you’ll likely be lost between where you started and where they used to be. You risk making little or no progress, whilst burning money and the goodwill of staff and stakeholders.
Better to dance to your own beat.
The fifth element
When it comes to building a high-performing organisation for a Digital world, you’re going to need to get to a place that’s about more than just the practices of devops. Practice flows from lived values and those flow from your culture and mindset.
The fifth element is culture
Digital Transformation is ultimately about transformation. That means fundamental change. Think of it as starting with a baby boomer mindset and dismantling it until you can put it back together as a millennial mindset. Structural, internal, personal change that affects you first and everyone else in the organisation second.
Start where you are, focus on your own needs, path and next steps. Resist the temptation to compare yourself, except with who you were yesterday. The race is long and in the end it’s only with yourself.
