Operations engineers have a few complaints about working with developers that shouldn’t be dismissed as merely rants because they are very real issues that Ops faces. Granted, developers have their own gripes, although this article is meant to provide some insight about what developers should know about operations, not the reverse. Three common complaints from Ops personnel are:
- We’re tired of being called in on nights and weekends to fix your software.
- We’re not as dumb as you think we are; and
- If you understood what we do, you’d understand why we’re not moving as fast as you are.
Some developers still have a throw-it-over-the-wall mentality as it relates to operations personnel because hey, after code is committed, the developer’s job is over. In a DevOps context, a developer’s responsibility should not end with a code commit.
“Developers need to know that operations-focused engineers are responsible for every layer of the application stack, including its stability, security and recovery plan said James Giles IV, DevOps engineer at database release automation solution provider Datical. “When it’s 2:00 in the morning and the system metrics have reached a state of unreliability or severe stress, the operations engineer is the one who wakes up to take the call or in a best case scenario, wrote a nice recover script to ‘self-heal’ the environment. Their job isn’t done after that because the root cause of the problem has to be determined swiftly to prevent the issue from happening again.”
Some organizations have addressed the ownership problem by creating a level playing field, which can mean developers are responsible for their code throughout the entire SDLC.
Related Content: What developers should know about IT Ops
“Typically, it’s the production operations group that has to bear the burden of being on call. Here at Jibestream everyone is on rotation, including management so everyone knows we’re all in this together,” said Matt Baxter, VP of engineering at Jibestream, an indoor navigation and mapping engine provider. “It’s not like, ‘Oh, it’s my turn to be on call, everyone’s trying to screw me.’ It’s I get to be on call. If you’re a manager and you’re not in the trenches with the team, it destroys trust.”
Sometimes, it’s difficult to overcome prejudices that have been engrained in one’s thinking for years or decades. For example, Olivier Bonsignour, EVP of Product Development at global business consulting and IT solutions firm CAST has been a developer for 25 years. DevOps has helped him view the relationship between Dev and Ops differently.
“It’s a long-term change. Dev has to learn from ops and the opposite is true,” he said. “I’ve been a developer for 25 years, so I’m not trying to blame Ops. It’s not easy. [I might think] Ops is not doing the right thing [or] they’re not using the right infrastructure. When you do DevOps you remove this kind of excuse.”
Some prejudice is rooted in a sense of intellectual superiority. For decades, testing and QA personnel have often been accused of being developers that never could be. The same is true for Ops.
“There’s a general perception that people who are smart enough to become developers become developers and that people who are not smart enough to become developers or development managers find themselves in operations,” said Tom Hall, an independent infrastructure engineer. “Systems administration, infrastructure management and architectures are valid career choices, not something they have to settle for because they can’t be developers.”
Old prejudices only fuel the age-old animosity between developers and operations, which is one reason why DevOps should be viewed as a journey rather than a destination. Having the right tools is one thing. Adapting organizational culture is another and it’s much more difficult to do.
Another point of contention, is the differences in cadence between developers and operations. Developers continue to move faster, but operations isn’t keeping pace.
Forrester Research’s principal analyst Robert Stroud thinks it’s important to understand what the common goals are and take more of a systems view of the SDLC.
Related Content: Infrastructure terminology you should know
“What does it take for a change to go from idea to software a customer can actually utilize? It’s wise to look at every piece of the flow, throughout the value chain. How do we improve each of the steps along the way and which of these steps can we eliminate?” said Stroud. “You need teams collaborating in a way they haven’t done before.”
