I remember a few years back (sometime around 2004 or 2005, when I was with BMC Software) we started to notice an interesting little trend. We were having conversations with CIOs and other managers of IT on the Operations side who were articulating pains related to the lack of visibility over the applications they were tasked with managing. At the time, these needs were focused on addressing resolution and root cause analysis of performance and availability problems in applications.
The conversation was more or less like this:
- An application is built on the Development side of IT
- The application is thrown over the fence to Operations
- A problem surfaces while operating the application
- The Ops teams lack the appropriate visibility over the app to solve the problem
- Traditional management frameworks do not help: the infrastructure “looks green” (i.e. the database is ok, the app server is ok, etc.)
- A significant amount of time is spent figuring out where the problem is as opposed to fixing the problem (which is frequently easy to do once the location of the problem is identified)
We then started to think about what type of software would be required to “close the gap” between Operations and Development/Test groups. For one, we started to think about solutions for Application Discovery. I clearly remember a conversation with the CIO of a major financial services company who lamented how he really “did not know what apps he had.” We also started to think about solutions for Transaction Management to provide Dev and Ops groups a common view of transactions, as experienced by the end user, across the stack, with various degrees of instrumentation based on the severity of the problem (from tier-level instrumentation data to server data all the way down to instrumentation data about classes and lines of code in a Java or .Net app. There were a number of other parts to the solution: central configuration management, incident management, automatic problem resolution, automated run books for Ops, etc.
It wasn’t until a year or more later that I had the realization that we were solving some of the symptoms, and not the real problem. The real issue was that there had never been a formal definition of the interface between Dev and Ops. While ITIL and other IT management processes had been coming out of the Ops side, the problems really only became apparent or more pressing as Dev teams embraced XP, Scrum, or other Agile development processes, starting to put pressure on whatever minimum and mostly manual interface existed between a Dev org and its Ops counterpart.
What is that interface between Dev and Ops like? In many cases, it is an undocumented process of actions, automation, tasks, documents, emails and IMs that flow between members of the Dev team and members of the Ops team. The interface is also high-stress. It never quite works perfectly, maybe because it is highly undocumented, reactive, and manual, or maybe because Developers continue to push the envelope with more frequent releases into an organization like Ops that thrives on stability. More importantly, the interface between Dev and Ops is not managed, mainly because the two orgs have not defined what needs to be managed or measured (the actual releases). It is possible that there is a language barrier in place that contributes to the problem. People in Ops talk about terms like SLAs, QoS, uptime, availability, etc., whereas Devs talk about classes, modules, web services, APIs, etc.
It seems that the interface between Dev and Ops is also an afterthought. At the very least, it probably is for many on the Dev side, which does not seem to be proactive about engaging their Ops counterparts until very late in the development process. But I think it is also a problem on the Ops side, which has stereotypically never been as proactive at reaching out to the Development org and inquire about release plans and needs.
The DevOps movement, which aims at establishing a closer relationship between Development and Operations, is the realization of a solution that was only ideas a few years ago. With better established processes, more visible release plans, better defined automation of tasks, and a better view of the infrastructure required to run the application, DevOps has the potential to unify two of the most important arms of software development by establishing the policies and procedures. and the tools for release management, change management, configuration management, among other. That is all good. But just the fact that the term “DevOps” has triggered a conversation between previously separate and many times antagonistic sides of the software process is great progress.