In the world of cloud computing, Agile development, and the race to do more with less, the role and use of DevOps has grown exponentially. At this point it is practically a buzz word; a point of bragging rights that you don’t need developer-only developers or operations-only operations people. The article How DevOps is Killing the Developer by Jeff Knupp does a great job detailing the background, use, and drawbacks of DevOps. This post is an extension to that.
In a constrained workplace, especially in that of a startup or any small team with big goals, DevOps can be a necessity. In that environment, Developers aren’t the only ones taking on additional roles either. Everyone in the company has to step up to fill additional roles.
The more important part, and the reason for my post, is that DevOps shouldn’t be over-used when the resources are available. Developers don’t work at their best, most productive, and most innovative when they are also worrying about QAing and deploying code, maintaining servers and dealing with production issues.
As anyone who knows how I work (I would hope), I’m not afraid to ssh into production systems and update IPTables or restart Tomcat. And I enjoy being able to do that. It’s a good change of pace and it is good to experience how your code is functioning and is being used in the real world. Staying too detached from production can insulate you from issues or inefficiencies in your code. There is no better way to get a bug fixed than to put a developer on the Nagios alarms for it.
As a Developer, having a wide range of skills along the development stack is a tremendous asset. But it is an asset that should be used sparingly, as it takes developers away from their most skilled and enjoyed roles. Used effectively, however, the DevOps role can be greatly beneficial to a company, whether it is out of necessity or to mix things up.
There is an additional potential use case for a full-time DevOps role when there are also developer-only developers and operations-only operations people. In this case I think it makes the most sense as an individual or team that is part of the Operations team but focused on development of tools and systems for use by or in support of the Operations team. This could be monitoring, maintenance, or deployment management tools. It is likely not software specifically for primary business objectives, but rather in support of operations and management of the platform.