In a post on his blog , programmer Josh Johnson points out that “radical claims of great cultural shifts, especially in technology” are usually “bullshit”. “Over time technology changes, but true radicalism is rare. Most often, a reinvention or revisiting of past ideas forms the basis for such claims. This DevOps thing was no different,” says the post from Josh Johnson, Software Engineer at Adzerk.
In 15 years as a technology journalist, I’ve heard vendors use labels and marketing speak to sell solutions. You can’t judge the efficacy of a solution by its label any more than you can “tell a book by its cover.” But is there something to these devops practices that we should take seriously? Should we make the effort to separate the wheat from the chaff, the faster, better software builds from the buzzwords and BS? I think so. And when I read Josh’s post, I came to believe that he thinks so, too. Josh shared his thoughts with me. Here are the fruits of that exchange.
First, no one should be doing devops. It’s not an action, it’s not a title, it’s a blanket term for approaches that bridge the gap between traditional operations and development groups, says Johnson. Second, having devops teams is wrong. “Sectioning off a group of people and giving them special projects and expecting devops skills doesn’t fix the divide, it creates new divides,” says Johnson. This leaves other developers and ops people, not to mention management, out of that inner circle. “The value of devops is in the cross-functional aspects of bringing people together from different disciplines,” says Johnson. True devops should include everyone.
A healthy, organic transition to devops practices should encourage people who specialize in operations or development to apply their specialties to the fullest while learning what the other side does. “If I’m the security expert,” says Johnson, “I’m going to monitor CVE feeds and recommend policy and practice. On a cross-functional team, I will also perform code reviews, participate directly as a peer in planning, and help the QA specialist by turning them on to fuzz testing. They’ll teach me how to use Selenium. I’m still the security expert.” In this scenario, the security expert grows and benefits and so does everyone whose work he touches.
Hurdles
The company will make compromises. The enterprise is asking a lot of its people and will have to pay to get it. The turnover in human resources can slow change to a crawl. The organization will probably have to outsource at least some tools and talents. “You may have to use GitHub instead of hosting your own git server,” says Johnson.
The more the devops metamorphosis progresses, the more the organization can lose central control of critical components. All things being equal, the bigger the enterprise, the harder it will be to let go. Initial costs and security concerns when getting started, together with outsourcing, can drive project scope through the roof. And that’s not the worst of it.
“You might lose some great people. There are some people who really need to focus exclusively on their specialty. There are managers who don’t thrive outside of silos. There are people who will not be able to rise to the occasion and work well with their new teammates,” says Johnson.
Don’t Force It
To achieve a thriving instantiation of devops while maintaining your sanity, you have to guide everyone to simultaneously want these practices. Start by poking holes in silos and letting members of different teams peek through. “Take a team of bright, collaborative people, give them a goal (say, reduce downtime in deployments by half) and empower them to make it happen, and it will happen. DevOps will magically spring forth,” says Johnson.
This organic approach is far afield of simply adding a devops team in hopes that it will save money by reducing staff. “Four DevOps engineers are not directly equivalent to two systems engineers and two software engineers,” says Johnson. If that’s the case, it’s worse yet to believe that you can replace four specialists with three experimental devops positions and maintain quality output at a savings of one FTE. Instead of saving money, this move may increase costs due to compressed time to burn out, expensive errors, and an enveloping drop in moral. “That will blow up in your face,” says Johnson.