Many organizations claim to be doing DevOps, but is that actually the case? For one thing, just about everybody has their own definition of DevOps, and that interpretation tends to impact how DevOps operates within a team or company.
Following are five of the misconceptions.
#1: DevOps = Dev + Ops
On some level, parsing the term seems logical. For the past 15 years or so, the software industry has been saying that Dev and Ops have to work together as a cohesive unit to deliver higher quality software faster. Interestingly, the belief that the definition of DevOps is Dev + Ops falls apart on several levels. In fact, Charles Betz, principal analyst at Forrester says this is the #1 misconception.
“There were a series of epiphanies, discussions and lessons learned coming out of a wide variety of really smart people working in very challenging environments. You have to have some familiarity with that history to begin to make sense of it,” said Betz. “We get a lot of people calling in and that’s their level of understanding. They haven’t challenged themselves to really dig into where the whole movement came from.”
Simply parsing the term can cause issues. For example, testing is obviously missing from the term. While DevOps teams do testing, they sometimes treat it like a second-class citizen and as a result, quality is not as high as it could be.
“Without testing, you lost a vast majority of the benefits,” said Dave Messinger, CTO at talent marketplace Topcoder. “We’ve put a lot of emphasis on quality assurance and testing.”
Clearly, security isn’t included in the term either. Because quick CVE scans aren’t enough, some teams have embraced DevSecOps to ensure that security is addressed adequately throughout the lifecycle.
#2: It’s all about tooling
Many types of cultural change are confused with tool procurement. DevOps, Agile, and even digital transformation are often viewed this way. If one simply procures a tool or set of tools, then, from that time on, the organization is “doing DevOps.”
“We dive into conversations about do we do Jenkins, do we do Docker, do we do Swarm and it just becomes a tool conversation. And then we have these philosophical battles about which tools are the best,” said CTO consultant Emad Georgy. “Foundationally, they’re just not ready for the cultural changes [and] they have no idea how to communicate the business value of what they’re doing.”
Forrester’s Betz said changing practices and changing tools changes culture, although a tool may not impact culture at all, so technology has to be combined with peoples’ expectations, their priorities, how they’re measured and how they’re incentivized.
“People focus on process and tools instead of interactions and individuals and how they come together,” said Pradeep Menon, EVP at business and technology services firm Orion Business Innovation. “It’s about culture and faith.”
Consultants often say that their clients tap them for tool recommendations before thinking about the larger picture.
“A big mistake teams make is to go out and look at the entire ecosystem with hundreds of thousands of tools, trying to build the perfect solution,” said Dominic Holt, CTO of fractional CTO company Valerian Tech. “By the time you’ve built your DevOps pipeline, you’re going to change at least 50% because the ecosystem is moving so fast.”
Some companies have spent 12 to 18 months building those pipelines only to discover they didn’t do it right the first time, so they spend more time redoing it, wasting two and a half years.
“If you haven’t done this before, talk to people who have done it,” said Holt. “It probably took me six to 12 months to become familiar enough with these tools that I realized I didn’t do anything correctly.”
#3: DevOps increases error rates
One of the benefits of DevOps is fast feedback. However, if failure is not tolerated and the pipeline is automated, it may appear as though code quality is worse than before.
“People don’t realize that DevOps involves a lot of failing and learning,” said Georgy. “Some organizations aren’t ready for that information. They’re seeing it as ever since we adopted a DevOps culture, we’re getting more errors than we had before. What they don’t realize is the errors have always been there.”
#4: It’s about automating part of the SDLC
People often talk about the importance of automating a pipeline, but some view it as synonymous with DevOps.
“A lot of people miss the mark and say DevOps is writing automated tests, configuring continuous integration for my project, or using code to provision and configure infrastructure resources in the cloud,” said Justin Rodenbostel, VP of delivery at digital transformation agency SPR. “People confuse components or ingredients of DevOps with DevOps like somebody seeing a tree instead of a forest. For us, the most important part is the unified cross-functional aspect of working together. The communication and process aspects. We see tools as the support system.”
#5: A DevOps engineer will enable a DevOps transformation
Some organizations try to hire DevOps engineers to affect a DevOps culture. Others rebrand operations engineers as DevOps engineers and then claim to be doing DevOps.
In a top-down transformation, the newly-hired DevOps engineer may not be empowered to spearhead a DevOps transformation.
“You need champions because it’s very hard, especially in larger organizations to do these cultural shifts, especially when things are very much imprinted in the way things are done,” said Valerian’s Holt. “Otherwise, people will go back to what’s comfortable, their defaults.”
In a bottoms-up transformation, the person may fail for people-related reasons, either because people don’t want to change, or they resent the new role which has been charged with changing the status quo.
Topcoder has two dedicated people that manage the DevOps pipeline and processes which CTO Dave Messinger says “cascades through the entire organization.” Specifically, they help manage the infrastructure, processes, enforcements and how DevOps is done, down to individual development teams and individual sales teams.