DevOps and its place in the Enterprise

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.

DevOps and Agility in the Enterprise

So, to preface this post, I have been working in implementation and System Administration for the past 2 decades.  DevOps is the latest term used to describe what I think should have always been the focus of System Administration but was not.

System Administrators have always used automation to speed up certain operations activities, since the first time I setup any server, there have always been automation routines created to ease the process of maintaining and making changes.  However, the comprehensive nature of today’s automation platforms is a natural growth of the move from monolithic and expensive hardware servers, such as Sun Solaris servers, to the decentralized and commodity servers running Linux.  More to the point, today’s environment is littered with virtual servers and cloud hosting, which makes the individual server even more of a commodity, basically nothing more than a collection of disk, CPU and memory to serve as a platform for software.

Amazon’s Elastic Beanstalk offering and the move to containers such as Docker, take that even further by abstracting the server completely out of the requirements for hosting.  All of these movements increase the decentralization of server platforms and require more complex automation to duplicate and control the process of configuration management.  This allows software to be delivered in such a controlled and automated fashion that agility is much higher than it has ever been in the past for system administrators.

However, while the speed and agility of the operations services have increased, the other inherent problems in any organization are not improved by these trends.  Certainly, you can get software deployments in quicker and faster increments, but you also duplicate any other issues that are currently part of the landscape of your software development shop.  Namely, if your quality control is in question, it means you are producing software that is unpredictable and unreliable, and you will get that multiplied by how much more often you release software.  If your architecture is changing more rapidly than your QA group can retool to test it, then you will push problems out to your production servers more rapidly as well.

This speed can be a great thing for companies, if it is coupled with the same types of rigorous testing and software control that reiterates over multiple environments prior to the actual production release.  If not, software will be released in whatever state those processes have left it in and your customers will be using  essentially untried and untested products.  That can negatively impact your brand and reputation, the loss of which can be difficult to rebuild to your customer base, and especially to new customers.

I have often thought that the two separate groups, Development and Operations, each have a counter role to play within an organization.  Development discounts outdated tech solutions and embraces new technologies, chafes at the restrictions that prevent new concepts and tech from being embraced.  Operations is focused on stability and reliability and looks upon new technologies with a cynical and distrusting eye, ever knowing that new tech tends to be unstable/untested and can contribute to instability, outages, and potentially have far reaching negative consequences.

When joining these two teams, as the DevOps movement desires, enterprises should take care that they don’t get the worst of each of these two philosophies to marry together.  The end result of a successful DevOps culture should be the rapid adoption of new tech into a stable and reliable implementation.  Not, the abandonment of stable environments and operations in favor of the rapid implementation of unstable, new tech solutions.