An Introduction to DevOps

The name “DevOps” is an abbreviation of development and operations. Traditionally, the development team would create and test a software product, before handing it off to the operations team for deployment. While this separation of duties into teams seems logical, the development and operations phases have often been built up into “silos.” Despite working on connected stages of the same product and pipeline, there has been very little cooperation between development and operations in most organizations. DevOps attempts to merge these distinct parts into a single, cohesive path.

Why is DevOps Needed?

Where traditional development is geared toward older desktop applications and the same sort of development environments that people have used for decades, DevOps seeks to modernize these processes. Software consumers today use far fewer desktop applications, and many more web applications and cloud services. Many of these apps and services blur the line between development and operations, so it makes more sense to have both of these areas work more closely together. In effect, this improves efficiency, and delivers a better product to consumers more quickly.

What Problems does DevOps Solve?

The first and main problem that DevOps solves is the gap between development and operations. This core problem causes a number of different issues that ultimately inhibit the development pipeline, and increase the time before a product reaches customers.

Imagine a manufacturing assembly line with a large wall between steps. When one step is finished, the team must package it up and toss it over the wall for the next team to do their assigned step. This causes several inefficiencies in the process. For one, the next step must spend time unpacking the product in order to do what they need to do. The product may be easier to handoff as a neat and tidy package, but it ultimately takes more time to finish the entire process. Additionally, if the next step needs some clarification or change from the previous step, it is very difficult and time consuming to reverse the process. The product flows strictly one direction, so incorporating changes requires significant effort.

Software works much the same way with heavily concentrated development and operations steps. Development writes and tests code, and expects to have no other responsibilities once it passes off to the operations department. Traditionally, they hand off the product in whatever form they finished with it, which may not be something that is readily deployable or easy to install. If operations has some request for development, it might be prohibitively time consuming before development can incorporate the change.

These issues stem from metrics and measurements that are too local. For every step of the development pipeline, teams are trying to hand off the product as quickly as possible. While they could make improvements along the way, that takes more time, and reflects badly on their team. Instead, that can be a problem for the next team to work on a product. These local metrics and optimizations have a global effect of slowing down the process. Each team is so concerned with speed and efficiency on the small scale, that they do not prioritize the large scale processes.