DevOps: The Revolution That Stalled

Since the early days of the internet, we have had two broad categories of software people: application developers, those entrusted to develop new products and features to existing products; and operations, those tasked with keeping the live system running and healthy.

The reason for this division is simple. Organizations that develop and manage software need to do two things simultaneously: a) maintain a working system that customers or internal users depend on, and b) change that system in novel and unpredictable ways.

Right away, we can see a conflict. These two mandates are completely at odds because making any change to a running system introduces risk.

To demonstrate this basic paradox, I present the following hypothetical scenarios:

1. If we were to implement a permanent code freeze, we could ensure that our system would be stable — or at least, it would fail within known parameters. We could sleep soundly at night, knowing that no changes would be made. Of course, we’d still need to upgrade for security patches, but the range of potential changes would be quite limited.

2. If we were to do away with our testing, release, and deploy processes entirely, we could effortlessly push changes out to production and get features in front of users at will. Sometimes this is called “cowboy coding.” Product teams would be amazed at how quickly features make it into production, but we would inevitably have quality problems due to the breakneck pace of…