We here at Fixate like DevOps (and DevOps practitioners) a lot. We see DevOps as one of the greatest innovations in programming in a generation. We believe that, by making software development and delivery faster and more efficient, and infrastructure more agile, DevOps will play a key role in facilitating the apps of the future.
Yet we’d be silly to pretend that everyone likes DevOps as much as we do, or that it’s a universal solution for all programmers’ woes. Some developers feel threatened by the DevOps revolution, and their feelings are understandable. Others question, legitimately, whether a DevOps approach to software delivery is the best fit for their organization.
So as we promote DevOps, it’s worth taking a look at the reasons why some professionals are resisting the DevOps movement. They’re not just crazies living on the fringe. They have legitimate concerns, and if we’re going to make the most of DevOps, we need to understand them.
DevOps vs. Full-Stack
If you read critiques of DevOps, one theme is clear: Some programmers see the DevOps revolution as running “counter” to “full-stack” development. Some even write that DevOps is “killing” full-stack developers.
What these people mean is that, traditionally, the most successful programmers were the ones who were full-stack developers. That meant they could do it all: Program in many languages and frameworks, understand databases as well as frontends, and handle deployment to boot.
For example, if you are a full-stack developer working on a PHP web app that uses MySQL and runs on Linux and Apache, you’d be expected to have expertise in the complete Linux-Apache-MySQL-PHP (LAMP) software stack. Employers would like you because you’d provide a complete solution to their development and delivery needs for that app.
Yet the DevOps revolution has turned full-stack priorities on their heads. That’s because the DevOps culture prizes programmers who have deep expertise in one particular part of the stack—and are prepared to collaborate with others in order to facilitate the rest of the delivery pipeline.
There are good reasons for this. The main one is that software stacks have grown much more complicated in recent years. There are more languages to contend with (PHP now has lots of alternatives, from Ruby to Lift), more deployment platforms (not only Windows or Linux servers but also the cloud and containers, among other things), and lots of storage options (as MySQL gives way to the NoSQL family of databases). Expecting a programmer to be an expert in all parts of this broad stack is no longer realistic.
Yet that does nothing to dampen the threat that full-stack developers feel when DevOps advocates suggest that the broad expertise that the former have gained over the course of their careers is now a drag.
Startups vs. enterprises
The other main critique of DevOps is that it’s a poor fit for large enterprises that already have established workflows. It’s better, critics say, for startups that don’t yet have deeply entrenched ways of doing things and steep barriers to the DevOps migration.
With time, this concern will probably abate. DevOps tools like containers are still maturing. Migration solutions will probably appear in time. And enterprises can gradually change their workflows and mindsets in order to adopt DevOps practices.
Still, it’s worth keeping in mind this hesitation on the part of some large organizations to do DevOps. People who resist for this reason are not off their rockers; they’re observing legitimately that it’s harder to teach a large enterprise new tricks than it is to found a startup that does DevOps out of the gate.
Addressing concerns (and parroting open source)
So how do you handle the DevOps backlash? How do you endorse DevOps principles while recognizing that some people, for good reasons, question whether DevOps is really a good thing for them?
The first part of the puzzle boils down (again) to admitting that these people are not just out of their minds. You don’t want to end up like open source diehards in the late 1990s who claimed that anyone who questioned open source was simply either a lunatic or a diabolical secret agent of Redmond. Open source was not a perfect fit for everyone when it reached the big leagues in the late 1990s (it arguably is a better fit now), and its critics had valid points much of the time.
At the same time, DevOps advocates should work to address the real technological limitations that constrict organizations’ ability to do DevOps. Better migration tools are needed, as I noted above (for example, it would be great to have tools that could take an app designed to run on a virtual server and containerize it automatically so it could deploy on Docker).
Last but not least, DevOps fans should keep touting the benefits of DevOps (while remaining honest about its limitations). Like open source before it, DevOps needs more time before reaching massive buy-in. So DevOps teams need to keep calmly and consistently sending the message that agility is key to innovation in the software space. Eventually, people who are not yet listening will start. If you need proof, just look to Microsoft, which, after so many years of hating on open source, has finally decided to cooperate with it.