In the pre-Kubernetes era, infrastructure and app development were inescapably intertwined. As complexities grew and teams evolved, we saw “DevOps” emerge as a bridge between development and operations in an attempt to resolve the age-old delivery trouble arising from developers throwing things over the wall to ops and then ops having to deal with production issues on the other side. DevOps rose to be a new subculture within existing teams, sometimes yielding new “DevOps teams” and even leading to a new class of tools and methodologies.
In reality, though, bridging skills and evolving an operational culture was not enough. Issues arise in the correct functioning of an application without proper configuration management in place. Application configuration would often conflict with IT’s own configuration goals towards security, scalability and availability. Inevitably, every time the pager went off — except for trivial issues — both roles would get pulled in to uncover the mysteries of running software in production.
The challenge of agile delivery was that application configuration and infrastructure configuration had to be achieved collaboratively yet have well-defined ownership and clear role separation. In the absence of such a model, there were too many heads still involved in delivery, resulting in a lot of friction and spilled energies. On top of that was the classic case of ‘it-works-for-me’ syndrome wherein developers would often complain that their software worked fine in their own configured development environments but behaved differently once pushed to an IT configured environment. Configuration hell reigned, even as the culture of DevOps seemed to be finding its way.