Tom Healy of Jama Software published a blog entry entitled, “DevOps is Dead, Long Live DevOps” as did Andrey Akselrod and also Nir Cohen. Interestingly, I find these pieces to have related concerns but different reasoning. Clearly, there are naysayers within the IT community that don’t buy into the DevOps fanboi messaging; and that’s okay!
Personally, I believe the IT industry is notorious for taking a good concept, like DevOps, and twisting and contorting it until it fits a consistent model that highlights tooling (product) over outcomes, specialization over generalization, and engineering prowess over simplification. We have seen this same pattern occur with Java, Service Oriented Architecture (SOA), Cloud Computing, and now we see it with DevOps. Ultimately, the downside negative impact is that we lose the support and interest of business as these efforts become more and more technical in nature. Moreover, it feeds an ever increasing cost of operations for IT and minimizes the available pool of candidates for jobs.
DevOps is already well-along the path of being molded to the model outlined above. From the outset has been plagued with dissention that embodies my aforementioned characteristics. The first major point of dissention was about the viability of Enterprise DevOps—was the nuances about the needs of DevOps in the enterprise different than those of startups. Debate is good, when it helps to hone a new concept for the benefit of all. But, this was not a healthy debate with much of it devolving into personal attacks on individuals’ credibility as a means of one perspective being perceived as “the right way!”
As Nir points out in his presentation, linked above, the label DevOps is being attached arbitrarily to roles, jobs, tools, etc. Again, if everything is DevOps, then nothing is DevOps. Each day DevOps become more strongly molded in the aforementioned model and further from the reason the DevOps conversation arose in the first place. That is, we are losing sight of the value that could be derived from recognizing and correcting the hurdles and problems that exist in currently delivering and running systems for the purpose of running a business.
What are those problems again that are limiting our abilities to be perfect (as a goal, not a requirement) in our delivery of IT services to the business?
- Lack of automation means more human intervention and greater chance of error and outages
- Lack of collaboration between those who build and those who operate leads to greater opportunities for inconsistencies between environments and outages
- Lack of automation and collaboration in addition to out-of-date policies limits the ability for IT to respond to business needs faster
There are some learned practices that seem to greatly help some IT departments respond to these problems. There are some tools that improve configuration management and allow automation of complex, distributed environments. There are tools, policies and procedures that help to improve collaboration and communication between those who build and those who operate. There’s still a need to manage up to help senior management understand that this is not solely a “below the waterline” problem and needs executive sponsorship to succeed.
Let’s not allow DevOps become so mired in a need to be molded to some idea of a geek fantasy project that we lose sight of the good that come its origins. Allow the knowledge of and experience of those that have mastered moving their business to a more agile and high-quality environment guide your own efforts, but don’t get caught up in whether or not it’s “DevOps”. Are you addressing the key problem areas identified above? If so, then your business will benefit from the improvements in IT service delivery.