DevOps Requires OpsDev: It Is Time for a Change

There is a huge disconnect between the DevOps world and most current enterprise IT organizations. One element in the gap is that developers do not want to know about infrastructure. Another is that the operations team does not trust developers to make changes to the production infrastructure. Developers want to focus on their application and the value it delivers to the organization. Developers want to know the characteristics of the infrastructure but do not want to build it or operate it. As a result, DevOps does not mean the end of the operations team. In fact, I see the reverse as being essential. The operations team is absolutely critical to the success of DevOps methodologies. The developers must be able to trust that the infrastructure has specific characteristics: characteristics like performance, connectivity, availability, and uniformity. To enable this trust, I believe that the operations teams are going to need to become more like developers. I call this OpsDev.

DevOps is a set of methodologies based around making application development and deployment rapid and consistent. At its core is the ability to test and deploy changes fast and frequently enough that individual changes are insignificant. A crucial part is the ability to automatically deploy copies of the production infrastructure to test changes before they are deployed to production. There is an implicit assumption that the production infrastructure that runs applications is consistent and repeatable. In many enterprise organizations, the production infrastructure is a unique and beautiful creation. Handcrafted from many disparate technologies, the infrastructure is a delicate object. Recreating production for testing changes is almost impossible. As a result, changes that worked perfectly in test fail in production. Testing changes with an exact replica of production is crucial to successful deployment. In order to create development and test environments that match production, it is crucial to change the way production is built.

This is where I believe OpsDev begins. The route to the required consistency is an automated build and configuration process. Infrastructure builds must all start with a set of files that describe the infrastructure to be built. These description files are the source code for the infrastructure. If the infrastructure needs to change, then these source files are modified and the changes applied to the infrastructure. There are no ad hoc changes to infrastructure, ever. As you can imagine, these source files are important. To protect these files, they are kept in a version-controlled source repository. Versioning these files allows changes to be rolled back by reverting the files, addressing a big pain point in change management. This version controlling of source files is very familiar to developers but quite foreign to many operations teams. OpsDev will require operations teams to learn new skills and change a lot of their processes. DevOps is a similar change for the developers. Having both teams going through similar change will help them to understand each others worldviews. This greater understanding is a vital part of supporting a DevOps and OpsDev environment. Understanding will enable more shared responsibility and should enable better value back to the business.

OpsDev is not simply about having a scripted build for servers. That is a starting point, but it is not sufficient. OpsDev is about having a full infrastructure that is built and maintained automatically from a set of source-controlled configuration files, and then having development and test environments that are built using the same methodology. Not just the initial build, but the ongoing changes must be automated from these source files. This is where declarative configuration tools, which define the required state, are crucial. Declarative tools allow the operations team to define how the infrastructure should be configured: a configuration policy, if you will. These tools allow the Ops team to check that the infrastructure is in its defined state. They also drive the infrastructure back into its documented state without rebuilding everything.

DevOps is not about developers taking over the role of operations teams. DevOps does make developers much more discerning consumers of infrastructure. It demands that operations teams provide a consistent infrastructure across multiple environments. DevOps is a total change to the way developers work. In the same way, OpsDev is a total change in how operations teams work. Automation, declarative configuration, and source control are all new skills that operations teams must learn. As it is in nature, so it is in IT. Evolve or die.

Posted in IT as a Service, Transformation & AgilityTagged , ,

Leave a Reply

Be the First to Comment!