DevOps is a great way for many organizations to optimize software design and delivery. Yet, like every other technological innovation in history, DevOps is not perfect. Here are some examples of drawbacks associated with DevOps.
By no means do I think DevOps is a bad idea in general. I want to be very clear about that.
However, organizations considering making the move to DevOps—and those that are already doin’ DevOps, as we say here on staging-devopsy.kinsta.cloud—can gain useful perspective by recognizing the difficulties that DevOps can present. Those include …
Narrower Team Member Roles
Traditionally, software engineers were expected to bring “full-stack” skills to the table. That meant they should understand the ins and outs of all layers of an application stack.
Under the DevOps model, each member of the software delivery team has a more rigidly defined role. Coders code, QA engineers test, IT Ops admins administer and so on. These people all talk to each other, but they do not share in the same tasks.
In many cases, this approach is better because it allows each professional to focus on what he or she does best. But this can be a drawback for full-stack developers. Their broad skill sets are no longer valuable. This is why people such as Jeff Knupp complain that DevOps is “killing” developers.
There’s a potential downside here for organizations, too. Under DevOps, they have to hire and manage more personnel to make sure there is a specialist who can cover each stage of the software delivery pipeline, rather than investing in a smaller number of full-stack developers.
Software Feature Bloat
One of the key advantages of DevOps is that it promotes continuous software delivery. That means new features can be rolled out faster.
But the ability to add features more easily also raises the risk that software delivery teams will add functionality to software just because they can, not because it’s needed. More features are not always better, even if they can be implemented efficiently.
Infrastructure Changes
To make the most of DevOps, most organizations will have to upgrade at least part of their infrastructure to optimize software delivery. Many will need to migrate apps running on virtual servers to containers, for example.
There is nothing inherently wrong with such infrastructure upgrades. But they are potentially expensive and complicated endeavors, and if you don’t complete them properly, you might not actually get very much out of the other DevOps processes that you implement. Organizations considering DevOps should keep this in mind.
Half-Baked DevOps
The final major risk of a DevOps migration is not actually a downside of DevOps, per se. It’s a risk that results from the chance that organizations will implement DevOps imperfectly.
This can be easy to do, because organizations can mistakenly believe that doing DevOps means simply running a continuous integration (CI) server or changing job titles. In practice, DevOps also requires significant cultural changes and new methods of communication. If you implement a half-baked DevOps environment that includes the tools but not the culture, you’ll likely be worse off than you would without having attempted DevOps at all.
Conclusion
Again, I want to be clear that there are lots of good reasons to do DevOps. I’m not trying to go on record as the guy who hates DevOps, because I absolutely don’t. Almost all organizations have much more to gain than to lose by adopting DevOps, if they have not already.
Still, being aware of the imperfections and risks associated with DevOps is important. DevOps is not a magic pill that will solve all of your software delivery problems with no side effects. If you want to avoid mistakes or unrealistic expectations when doing DevOps, you need to appreciate the drawbacks you may face.
