On DevOps and product lifecycle

stan klimoff
live stanklimoff com
2 min readMay 2, 2015

The idea of DevOps is kinda peculiar since there’s no real hard boundary between development and operations.

A common misconception is that the role of developers is churning out code, while operations are supposed to look over infrastructure. It does not take much to see holes in this approach. Configuration is code, but is usually handled by operations. Building the code repositories is operations, but it it usually relegated to development. The fact that development and operations are a two sides of the same coin is a truism by now — and still, the organizations are still divided at the top by mandate, despite the social movements to unify them that arise every five years under different banners.

Why do development and operations get separated over and over?

I believe that is might have to do with the product maturity concept. If we (simplistically) treat the product portfolio as a set of features, each of this features will start out as a custom implementation with zero or minimal adoption, go through a set of iterations with actual customers and eventually settle in some configuration where other features can use it as a utility. The optimization points are very different, of course. At the beginning, we care more about making it right rather then making it efficient. Hence many software projects begin as “greenfield”, trying to minimize external dependencies, using whatever software stack is available and optimizing for agility. Over time, they are consolidated with existing services, sometimes getting rebuilt on a more solid/supported stack. Finally, all development moves elsewhere and all that’s left is keeping the lights on. This difference in optimization points is the reason why we’re ending up with two sides of the house, one getting all the staff and deadlines and other getting all the capex and uptime requirements.

This makes me think that a better software organization would be aligned to this supply chain of sorts and look like a series of concentric circles. Every new feature starts as an application and slowly progresses into the core as more dependencies are introduced. Each circle is responsible for development and operations, but agility is superseded by efficiency as each feature matures.

--

--