Why DevOps is not for everyone and how release automation helps in bimodal world
So am I really going to write a blog calling DevOps a big hoax?
Well, not exactly, but as a follow-up to my previous blog on the difference between DevOps and Continuous Delivery, I want to alert you to a few key facts:
- DevOps is not always the right methodology for developing and delivering software.
- Agility and speed can be achieved even in a waterfall method if the right tools are in place.
- Release automation is bigger than DevOps (yeah, I said it!).
Say No to DevOps?
Okay, so here goes: Why is DevOps not always the right way to go? Simply because not all systems are born equal. For a back-end master customer data system, stability trumps iteration. Fail fast and roll forward simply aren’t sustainable in many of today’s most core business applications such as banking, retail, media, manufacturing or other industry vertical. Clearly, these enterprises still need to innovate and provide new and exciting ways for their customers to engage through web and mobile, but not at the risk of a terminal business failure at the back end.
Delivery capabilities for these back-end systems need speeding so they don’t become the bottleneck for the entire business. However, restructuring teams and changing development along with test and release into tens and hundreds of small/tiny parallel updates cannot be supported by a legacy technology stack (say Siebel or SAP at the back end). It is likely not even advisable at all.
This doesn’t mean we should accept the realities of the last century, resort to the status quo and leave our release cycles to once or twice a year for key applications. Slowly and surely we would lose any competitive edge.
Luckily there is a middle ground, and this is why I believe release automation is bigger then DevOps. That middle ground is release automation. I will explain why, but I need to start by examining DevOps a little more first.
What is DevOps?
At its core, DevOps aims to get new ideas and functionality into the hands of users quickly and iterate fast. It achieves this by fixing two traditional weaknesses in the software delivery life cycle, namely “overhead” and “rework.”
Overhead is anything that developers do that isn’t directly related to developing new features or improving existing ones (manual deployments would be a big item in the overhead column for sure, as would debugging production deployment issues or handling configuration problems).
Rework occurs anytime developers have to go back over a piece of code they already have worked on. However, this does not include bug fixing, so rework occurs when test cycles take a long time and developers already have been working on new functionality, which now needs to be reworked to address a newly found problem.
DevOps tackles these challenges by attempting to shorten the cycles—for example, by adding smaller changes that developers and testers can test in real time or by using tools such as Puppet or Chef for provisioning quickly to test while ensuring consistency across systems.
This relies on Devs owning updates and rollouts across the life cycle, including production, which challenges everything in the way enterprise teams are traditionally organized. It calls for completely new processes, which often are a great fit for newly developed applications and modern architectures, but can be a complete misfit (and regulatory obstacle) for so many other core systems.
I’m sure you can see where I am going with this. Much like the story, “The Emperor’s New Clothes,” DevOps isn’t what people believe it is.
Why Release Automation is Bigger Than DevOps
The goals of DevOps are sound, however, which leads me to my last point: Release automation is bigger than DevOps. Done right, release automation can accommodate diverse organizational needs and different types of applications in this new, bimodal world. It improves the software delivery process and its final product by rooting out manual work, improving cycle times, reducing overhead and rework.
Crucially, release automation enables incumbent businesses to stay competitive and ensure survival without forcing them to completely abandon their DNA across the board in a “big bang” fashion. Such a process could put the very existence of a large enterprise at risk.
Before signing off on this blog entry I want to make one last thing clear: The argument I am raising here isn’t trying to downplay the benefits of DevOps as a valid methodology. Nor am I denouncing any of the DevOps tool chain technologies out there, which are all welcome advances, of course. This year, 2016, is (according to most industry experts) the year in which DevOps adoption goes mainstream, and I fundamentally believe that it is release automation that drives this adoption, not just pure DevOps conversions.
Stay tuned!
