DevOps – it’s not dead yet
Ron Cogswell from Arlington, Virginia, USA, CC BY 2.0 <https://creativecommons.org/licenses/by/2.0>, via Wikimedia Commons

DevOps – it’s not dead yet

DevOps is about improving culture and processes - and many organisations still have some way to go. That’s why rumours of the demise of DevOps have been exaggerated

It’s one of those questions that’s tossed around the internet quite regularly. “Is DevOps dead?” Is there a genuine reason to think that DevOps is on its last legs? Or are authors just trying to get clicks by making controversial statements?

Let’s look at some of the main justifications given for raising this question:

  • The word DevOps isn’t appearing as much in conference talks
  • NoOps proponents say it has/will replace DevOps everywhere
  • Serverless and Kubernetes platforms mean that we don’t need to worry about infrastructure and developers can just do it all themselves
  • Everybody is moving on to the next thing and DevOps is just yesterday’s news.

I’ll come back to these points shortly. But first I want to ask my own question: why did DevOps develop and are those drivers really no longer relevant?

In its purely literal sense, DevOps came about as a means of addressing the problems that existed between the development and operations teams. Organisations that had adopted agile development practices became frustrated that they didn’t lead to better outcomes as waves of code crashed against the rocks of bureaucratic deploy and release processes. The first goal of DevOps was to remove these siloes and the impediment to software deployment that they created.

So, my question to you (if you think DevOps is dead) is have you removed all siloes, manual approvals and other bureaucratic obstacles from your value chain that prevent you from releasing software frequently and with high quality and confidence?

Siloes don’t just exist in development and operations teams. What about compliance or security? What about your testing team? Are all tests automatically run every time software is deployed? Is security baked into your pipelines? Do automatic tests run for performance and accessibility? Or do your services need to be regularly tested manually, potentially creating bottlenecks around deployment? Have you created feedback loops from production back to your development team so that they can keep improving their software’s features and reliability?

The principles behind DevOps will continue to survive whether the term does or not. Approaches to software delivery will themselves continue to evolve and improve. But the principles of DevOps will remain.

The goal of both agile and DevOps approaches is to get value to your customers/users as quickly as possible so if your development team is still toiling away for six months with no release are you really gaining benefit from either approach?

From observation, there are many organisations out there that have yet to benefit fully from DevOps because they still retain impediments in their processes and so have not truly implemented a DevOps culture into their organisation even though they employ “DevOps Engineers” and are using a grab bag of approaches – CI/CD, IaC, monitoring et al that are often considered ‘DevOps practices’. It seems like there is still a long way to go before DevOps is done well and extensively.

So if this is true why are people asking the questions? I think the answer can be found in the technology adoption lifecycle:

Technology Adoption LIfecycle

All technological approaches go through the same process and DevOps is no exception. More organisations who develop software than not have adopted at least some DevOps practices at this point and so adoption is well to the right of this graph – in other words it has normalised. 

It’s natural at this point for technologists to lose their excitement about DevOps and start looking for the next big thing – and newer concepts like NoOps start to sound very plausible (and appealing) when you take the DevOps promise of automating all the things to its logical conclusion. 

Similarly, advances in the completeness of out-of-the-box application running, container hosting and orchestration services from the major cloud providers could persuade some managers that developers don’t need operations staff to enable them to release production ready software.

There are some truths in these opinions. Yes, a skilled operations engineer or platform team will gradually reduce a development team’s need for full-time support by creating repeatable automated services that allow teams to self-serve themselves tried-and-trusted patterns of software build and test – and to easily deploy into standardised production-like environments. 

Yes, cloud platform providers will continue to offer improved products that remove complexity and allow even relative novices to spin up secure and highly available services. But these things don’t remove the need to adopt a true DevOps culture.

Both agile and DevOps are based on continuous improvement. Processes can always be improved, better tools can always be developed. Practitioners should always strive for greater efficiencies and better outcomes. Organisations who set their development and release processes in stone, those who think they have “done” DevOps are yet to fully adopt a DevOps culture.

The principles behind DevOps will continue to survive whether the term does or not. Approaches to software delivery will themselves continue to evolve and improve. But the principles of DevOps will remain. 

So, not dead yet then.


Good article Adam! You make some great points here but do you ever wonder why we talk a lot about moving the 'software development function' of an organisation (what we used to call IT) to more and more agile (with a small 'a') approaches but not the rest of the org? What we often do in introducing agile/lean approaches in just the software development function is increase the friction between that and the rest of the business and actually can make things worse! The typical response at 'C' level is to dial back agile/lean, introduce buffers between s/w development & the business or even abandon agile/lean altogether. It's no coincidence that ALL the companies we cite as being quite successful at these agile/lean s/w approaches are mostly or entirely software product/platform companies i.e. their business IS software so there's little to no friction. The fundamental issue is that once most of your customer interactions are thru digital means your business IS a software company and introducing agile/lean is a paradigm shift for the WHOLE company, not just s/w developers. Cited this article before but here's a more detailed explanation of why the change has to be at the paradigm level https://www.devcycle.co.uk/levers-of-change/

Nice piece Adam!  #PossibleMadePowerful #ocpeople

Like
Reply

To view or add a comment, sign in

Others also viewed

Explore content categories