The History of DevOps

The most expensive part of any business, but especially the software business, is payroll. If you are spending more money on anything else, stop. I'm not talking about Capital Expenditures; but your monthly expenses should be almost entirely devoted to headcount.

To be clear, this is a good thing. Development of software is a creative activity, and despite what anyone wants to sell you, people are the root of creativity. No machine, no computer program, no special sauce; the only thing that can create in any meaningful way is people.

That having been said, because companies are for making money, not software, there is an ever-present pressure to reduce costs and maximize profit and often this is done by reducing headcount.

In traditional development processes, the expectation was for software developers to write (develop) software, and then hand it to an Operations group, who was responsible for deploying and maintaining the software. For software-as-a-product, the Operations group would also include customer service and management. As the internet matured, more and more solutions became software-as-a-service, where instead of a company buying software, companies bought access to software, and the vendor was in charge of keeping the application working.

This often meant that there was significant friction between the Development and Operations groups, as pressure to develop in faster cycles led to a lower focus on quality and reliability, which in turn meant more work on the Operations side to keep systems healthy (or at least healthy enough) to service the customers. Operations, like Security, is an organization where the best case scenario is that nothing happens, so often capacity was reduced as a cost-saving measure while ignoring work done to maintain systems. The most dysfunctional version of this process goes something like this: development codes a new feature, rushes to make the deadline, then passes the code to Quality Assurance / Quality Testing, where bugs and problems are discovered within the new code (an inevitability – humans are fallible, and therefore anything made by humans is fallible). Because of the development pressure reports of issues from QA are ignored or dismissed, and the code is passed to the Operations group to deploy into the customer-facing environment. Deployment uncovers or otherwise reveals the issues identified in QA, but development resources have already moved onto new projects, so code correction and workarounds devolve onto Ops, who reports the issues to Dev, who identify fixes to be made if time allows. Repeat until the whole thing collapses or the company gets bought by some megacorp like Google or Microsoft.

In the late Oughts and early Teens, the concept of "Developmental Operations" or "DevOps" became popular. The concept was simple: rather than having separate teams, an embedded group of engineers would be responsible for any given development cycle from birth to retirement. Developers would use systemized testing and automated integration to avoid introducing bugs into the existing code, while allowing for new features and fixes to roll out on a nearly-continuous manner. Any issues with a section of code or feature set would be the responsibility of the person or team that developed it, and would be available to identify the problem, correct it, and push the solution quickly. The Continuous Integration / Continuous Development model (also known as the CI/CD pipeline) allowed for small changes to be made rapidly, discreetly, and with minimal disruption or exposure to the user base.

This concept, of course, fell apart almost immediately upon implementation in the real world.