Many people fear change and, without a doubt, DevOps represents change. However, much of the uncertainty and hesitation that is attached to the notion of DevOps can be lessened simply by educating individual stakeholders on how DevOps will affect them, its pluses as well as minuses, and, most important, their role in shaping your organization’s approach to DevOps.
Convincing Developers? Easy. Operations? Not So Much.
Developers are often the easiest converts to DevOps for several reasons. First, they’re more accustomed to change than those from other disciplines. Unless they graduated from engineering school yesterday, most software engineers are coding today in a language that they learned in the workplace, not a university classroom. In addition, the buzz about DevOps often emphasizes the quality of life and job satisfaction benefits to developers, including faster provisioning, and thus greater room for creativity and innovation. And let’s face it: developers just like new toys, and DevOps comes with lots of them.
Operations professionals react differently. Many fear that with DevOps, developers will dump untested, failure-prone software into production, destabilizing the system. While there’s ample evidence that the reverse is usually true, keeping the system running is the number one imperative for operations, so DevOps can be a harder sell for them. The trick here is to help operations personnel understand that faster deployment cycles, with significantly fewer changes per cycle, mean that problems are much easier to identify and rollbacks should be painless.
Will DevOps Lead to NoOps?
Another concern for operations is that their function will go away, a fear that is exacerbated by the talk about the NoOps (No Operations) movement. The idea of NoOps is that automation, abstraction, and outsourcing to cloud service providers eliminates the need for IT operations entirely.
While the idea has been around for years, new technologies such as serverless computing are paving the way for complete automation of the production operation process.
Operations may suspect this is one step on the path to being eliminated altogether. However, as serverless automation evolves, it just means that operations will be focusing further upstream than before. Ops folks “will still need to ensure that code is packaged and provisioned correctly … the new operations professional will apply systems thinking to holistically look at how business applications and customer experience can be improved,” says TechTarget's Beth Pariseau.
Everybody Gets into the Act
DevOps impacts people in the organization in a number of areas. It requires new skills; for example, system administrators may have to develop new tools, a skill they may not have learned or used often. The pace of DevOps can be challenging, especially for developers who work in the more linear world of waterfall development. Line managers may resist the formation of cross-functional teams based on concerns about the difficulty of managing in such an environment—in fact, this objection is a major inhibitor to DevOps adoption in larger enterprises with hierarchical management systems. Executives fret that they will not be able to attract and retain talent with the new skills and abilities necessary for DevOps and worry about undermining salary guidelines to compete for scarce software professionals.
Have You Thought About…?
DevOps changes software workflows and that has implications as well. For one thing, legacy linear management tools are often not suited for DevOps, requiring capital investment in new tools (although many organizations are turning to open source and home-grown tools as a way to mitigate the expense). DevOps also requires much more cross-functional collaboration, which means that teams need to be looking at the same source of data to agree on priorities and measure the progress of their efforts (see more about KPIs in chapter 2). In addition, the intertwined workflows are harder to visualize and document, making regulatory compliance more difficult and time-consuming. Security teams need to adjust as well: