DevOps means a lot of different things to different people and there are probably as many definitions as there are software development methodologies. For some, DevOps is a philosophy for increasing collaboration between the traditional foes of Operations and Development. For some, DevOps is a focus on the building of tools and automation to increase the efficiency of traditional system administration tasks. For some, DevOps is a really cool catch phrase and bullet point on a resume that might buy you a higher rate when you are looking for that next position.
In my mind, DevOps represents the totality of the implementation of software. That is the traditional role of System Admins everywhere, although in many cases, the specific rewards and measurements were not structured to promote a focus on delivery. Obviously, there are simplifications there, Operations is concerned with stability, control, availability and the like. But, I think historically, Operations viewed any change as automatically negative, something to be distrusted, contained and only grudgingly allowed, once it had been proven to be safe. DevOps is a movement to change that mindset dramatically.
DevOps is ultimately, a service provider to Development. Each group within a software lifecycle is a provider of services, from product management, controlling scope and setting deadlines, to Development, designing and creating new functionality, Quality control, attempting to control the chaos that rapid change inevitably creates and Quality Assurance, attempting to confirm and demonstrate that the code achieves its intended purpose. Operations has always historically been the last stop and System Admins have referred to the release process as throwing the code over the wall. The DevOps movement moves Operations from the last stop in the chain, into the fold, making Operations a service provider who become part of the process.
This doesn’t mean that DevOps is not concerned with stability, consistency, and availability. Quite the opposite, it means that the tool box to insure these things is dramatically increased in size and form. It allows DevOps to have input into design elements that affect implementation, guiding the process from the beginning to enable quicker implementation as well as safer implementation. Automation and the building of tools, rather than relying on the manual intervention of highly skilled and trained personnel, insures repeatability of process, consistency of form, and ultimately, increases the certainty of change. One obvious advantage is that as you increase the certainty of change, there is the ability to see an increase in pace of that change.
However, one change that I do see with this new view of Operations is the decreased reliance on the traditional System Admin that required developers to come, hat in hand, kneel at their feet and perform the correct genuflections in order to be deigned acceptable to receive the services of the vaunted Operations priesthood. The level of arrogance that is often displayed in traditional organizations has always seemed somewhat problematic to me. Ultimately, the delivery of software is the raison d’être of the infrastructure that we create and manage. Without development, there is no use for the myriad, artisan crafted servers that are maintained ceaselessly by the clergy of Operations.
DevOps pushes that arrogance aside and plants the feet of Operations firmly on the side of delivery and implementation of new functionality. Ultimately, we are partners with development, not necessarily with the exact same measures and goals. I like to think that we can all learn something from the work of Deming concerning the end goal of the act of production. We are all stewards of the products that are produced from our labors. The shared goal should be to present the best possible product to the customers of my employer. Sometimes, this means making the hard decision to stop the assembly line to allow for something to be corrected, even if that is not something in my direct area of responsibility. I would hope in turn, that if someone else found an issue that was in my area of responsibility that was missed, they would perform the same action and stop the assembly line until corrections could be made.
But, in the end, that is part of the common goal of delivering the best possible product, as quickly as it can be delivered and ultimately, serving the interests of our common customers. In that respect, I think that DevOps shows tremendous promise in creating better collaboration and creating common cause for everyone involved in software development.