There are many things in this world I just don’t understand: why do spaceships always meet head on at the same level in space movies; how can you tell when blue cheese has gone bad; and why organizations create separate teams to execute a DevOps transformation.

What is DevOps?

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”.

The difference between transformation and addition

A transformation means change. If something is transformed, it is not the same as it was before. This is distinct from an addition. An addition means that something is added. Many DevOps “transformations” are actually DevOps “additions.” Adding a DevOps team to your Dev and Ops teams is the opposite to what DevOps stands for. Adding another silo and shuffling around responsibilities does not reduce finger pointing, it adds a couple more walls to throw things over, and it adds more job descriptions that don’t cover tasks that need doing.

A DevOps transformation requires changes to how Development and Operations work. Developers need to take responsibility for shepherding their changes into production and dealing with issues. Operations need to understand the application deeply and be involved with changes as they are programmed. The development and operations teams cease to exist as separate entities and the DevOps team is born.

Cross training, job shadowing, team building, and managerial support are all required to bring everyone up to speed in the new DevOps world. The velocity of feature development may slow as training and support activities occupy the teams’ time. By removing roadblocks, the time it takes for a change to go from ideation to production will be reduced. There are fewer handoffs and less waiting time since the team is taking care of the change from soup to nuts. Also, production outages can be resolved more quickly since hardware and software issues are investigated by the same team.

Getting There

Adding members to your team with “DevOps Engineer” skills must be done in the context of bringing those skills to the team and not bringing in a scapegoat to blame every time an environment goes down, or someone to figure out your AWS/Azure/GCP architecture and processes so your current team doesn’t have to. DevOps is, after all, about one goal: Releasing Better Software.

Photo by Bill Anderson on Unsplash