Organizations building software, whether for sale or internal use, traditionally divided technical staff into Development and Operations teams due to the varied skillsets of both teams. Designing and implementing algorithms to intake, process and output data is different from racking servers, routers and switches and running cables to connect them.

As technology has evolved, hardware has become more and more abstracted, and largely moved out of physical data centres and into the cloud. At the same time, the ability to define and manipulate these hardware abstractions as code has progressed by leaps and bounds. The operations role looks more and more like a software development role – maintaining files of code that defines compute, storage, and network resources and rules.

Similarly, containerization technology has changed the way software is developed. No longer do APIs need to be stubbed, mocked and doubled to develop against. In many cases, a local instance of an application is available in a docker image. This means that a complex application topology can be spun up on a development machine and changes can be experimented with in a similar environment to production without impacting external systems. Software developers need to understand how the target production environment works and how to wire up container versions of the applications in their local environment to mirror production. This is a level of understanding previously reserved for operations staff.

The DevOps movement recognizes these shifts in knowledge, skills and responsibilities and advocates blending roles, cross-pollination, and even a merger between these units. Ideally, it removes the barriers that slow down development staff while they wait for hardware, storage and network changes, and shares the responsibility for production outages with development staff. DevOps means no finger pointing, no throwing stuff over a wall and forgetting, and no more “that’s not in my job description”.