Skip to main content

Too much Ops, not enough Dev—how to fix DevOps

(Image credit: Image Credit: Profit_Image / Shutterstock)

Firefighters do more than fight fires. Sure, the often popular image is of them racing off to emergencies to douse flames, rescue people from burning buildings, and possibly retrieve the occasional cat from a tree.

But they do also work in fire prevention. Fire brigades also provide educational advice on the best way to avoid fires breaking out, provide guidance for organizations to keep their people safe, and campaign on fire prevention issues, for example the London Fire Brigade’s campaign on sprinkler laws.

That a fire brigade would take on these dual roles makes sense. Firefighters have authority in the area of fire prevention because, by the nature of their job, their training and experience gives them insight into how to prevent fires.

What does this have to do with DevOps? There are parallels here with the DevOps team’s dual role in development and operations. Rather than two separate teams, one working on developing new features while another team keeping everything else running, DevOps was supposed to create a unified team that would do both at the same time.

But what happens if there are too many fires to put out? We can’t expect a fire service to perform these other duties if every day is spent rushing from one fire to the next. Similarly, DevOps teams are finding that they are doing too much Ops and not enough Dev—and the promise of DevOps is not being fulfilled.

Solving old problems, creating new problems

The promise of DevOps was to create a unified development and operations team. Previously these were siloed teams with demarcated roles. Broadly, developers are tasked with introducing new features to an application, while operations teams want to preserve the stability of an application once it is released.

These two teams, in certain ways, work against each other. While they’re not exactly mortal enemies, they do have aims in that conflict.  While operations is all about keeping things stable and on course, the development team wants to improve the feature set of a product—with all of the risk this entails. The ops team would probably have an easier job if the dev team took some time off.

So rather than have two teams pulling in opposite directions, DevOps creates something more unified. It is supposed to encourage collaboration, integration, and transparency between the two disciplines. The Ops team no longer holds the Dev team back, and the Dev team doesn’t cause headaches for the Ops team

When it works, there is a continuous loop of improvement, development, testing, and deployment. Rather than the Dev and Ops being in opposition, they are pulling forward in the same direction. These efforts can result in the continual release of necessary feature changes or additions. Like the fire brigade in our original analogy, DevOps teams are both putting out fires and innovating on new ways to prevent fires at the same time.

Unfortunately, this isn’t always the way it works. Rather than freeing up resources for more effective development, the focus has shifted more and more towards IT operations. Like a fire department on a day like the Fifth of November or the Fourth of July, the focus has to be on reactive response rather than innovation. Rather than a combined Ops and Dev team, you have an Ops team that occasionally dabbles in development.

This is a big problem. When a DevOps team becomes more about Ops than Dev, you lose the Dev side of things. Skilled developers end up wasting time performing routine tasks when they could be doing something way more innovative. And as these skilled professionals are far from easy to hire right now, this waste becomes even more egregious.

How to shift the DevOps balance 

This is not an unsolvable problem. It is possible to shift the balance back and ensure that DevOps is truly DevOps.

The most important step is to automate everything. This needs to be the mantra of a DevOps culture. Trust the machines and ensure that deployments are sufficiently automated, to become non-events. This way a business should be able to deploy its system at any time—even on a Friday afternoon, the “forbidden time” to deploy. Making this happen requires both organizational alignment around the goal of predictability with speed, as well as the right toolkit.

A lot of Ops work is about performing rote tasks to a high level of precision to underpin development. Automation means that Ops teams can not only provide the stability required of them, but also that they can easily roll back changes if necessary.

There also needs to be improved testing. Continuous deployment can mean a high frequency of releases, and this places a high demand on those tasked with maintaining stability. Just as you should automate deployments to predictably create isolated environments for new features, it’s also necessary to run and enforce tests alongside them. Any time a commit is made, that collection of tests is run. If they all pass, teams are free to focus on a qualitative review of those changes. Should they fail, changes are abruptly prevented from reaching production until its issues are addressed and fixed. 

Automation is one thing, but it’s only when paired with a better understanding of how every process interacts, and how a code change may affect other applications, that we can make sure that continuous deployment delivers on its promise.

Implementing DevOps the right way

Ultimately, DevOps does not remove the need for either Ops or Dev. Both are vital, and neither is more important than the other. Ops without Dev would mean a business stagnating—it might be stable but it will soon be left behind by competitors who are constantly innovating. Meanwhile the other way around is just as unsustainable, creating an innovative but unstable product that will fail just as badly.

Simply removing the barrier between two disciplines is not enough. There is a balance to be struck in DevOps, and without maintaining that balance there is a risk that one is seen as more important than the other.

Damien Tournoud, Chief Technology Officer,

Damien Tournoud Chief Technology Officer,