DevOps as a function largely emerged as a reaction to businesses requiring a much more adaptable IT environment – there was a consensus that IT needed to be more fleet of foot in order to compete. To achieve this a major overhaul of IT procedures was required, which essentially culminated in the digitalization of IT – whereby manual processes became more automated. The bottom line for many organizations was that IT needed to be more flexible.
This change in attitude really began with the commercialization of the Internet in the late 90s. However, the strategy really accelerated in 2007 following the economic crash when many businesses recognized that in order to get through the doldrums, they had to become more innovative. This led to greater IT automation and once this process had started there was no turning back.
Therefore, the crash was very consequential for the relationship between business and IT. For the last eleven years there has been a demand from business for IT to be much more responsive and able to change much more quickly. It was the development teams which took up the challenge to change the dynamics and role of the IT department – no longer could it be seen as just a back-end function, it now needed to be proactive and revenue generating. There have been three significant changes in DevOps that are worth highlighting.
Firstly, there was a widespread adoption of agile development practices which is primarily about how to develop software and how to speed up the delivery of creation changes into the production environment. Secondly, DevOps incorporated automation into the process of change delivery. So, you have much faster development, complemented by the automation of the delivery.
Thirdly, if you accept the previous two changes, the next logical step is that development and operations teams should not be so segregated.
Historically, operations team took care of the environment and DevOps managed development, meaning they worked independently of one another. It was assumed that changes were relatively rare and predictable and delivered discretely into production environments. But, with the advent of agility and automation, it was no longer possible to keep these two groups separate. They have been brought together in terms of practice, interaction and even in terms of sharing technology.
“To this day there is a Failure in DevOps to Fully Understand the Difficulty in Managing the Production Environment”
Was there resistance to this coming together? Absolutely. IT operations resented the close interaction with development and to this day there is a failure in DevOps to fully understand the difficulty in managing the production environment. DevOps believe it to be a relatively straightforward, low-level task. Also, the DevOps perspective on infrastructure is very myopic, they tend to be only interested in the specific patches of infrastructure that is relevant to any particular project they are working on.
This logic does not take into account that no application is isolated. In reality, the application is living in an environment of shared resources. You can’t just worry about an individual applications effectiveness of consuming resource, you have to query the impact that application has on other applications and services running in that production environment.
So, for development teams in general we are dealing with a degree of cultural resistance and naivety, which culminated in operations focussing on the protection of its own infrastructure against the incursion of the DevOps teams. The bottom line is that because of mutual misunderstandings, DevOps remains to this day largely siloed – there is not much Ops in DevOps. The linkage that needs to happen hasn’t in truth been forged.
“Here is the Opportunity for AI or AIOps Technologies”
How does automation feed into this relationship? As we know there are many steps that need to be undertaken for a new module or application to be moved from the development environment into the real-world production environment. Historically, these steps have largely been done manually, today automation takes the human out of the process. And here is the opportunity for AI or AIOps technologies like Moogsoft. The automation path from development to production can be executed in a far smarter way.
For example, if you have algorithms that are able to take data from the production environment and understand the current disposition of resources within that environment, you can ensure that the new application or change being delivered has sufficient resources to support itself, whilst not starving other applications of resource. That can be achieved via automation.
From my perspective there are two stages to the automation process. Firstly, there is the automation of the path from development to production which includes activities like pattern discovery, anomaly detection, causal analysis – all are features of the AIOps toolkit, but in this case applied primarily to resource allocation and timing decisions around the delivery of new components into the production environment.
Secondly, what happens when the new element is actually in the production environment? Let’s consider that we have vastly accelerated the number of changes being delivered into the environment, it is no longer a matter of three changes a week it’s more like three thousand a week. In addition, we have increased modularity, ephemeralness, and IT systems are now more distributed, so it becomes nigh on impossible to predict with a high degree of certainty what the impact of a new change on a production environment will be. Therefore, you need to have a technology in place which will rapidly analyze what the presence of this element means, and to quickly provide diagnostic back to production or IT operations on how to deal with negative repercussions.
Due to increased data volumes, both development and operations teams require an analytical and diagnostic tool to compensate for their loss of ability to predict what’s going on. In this scenario AIOps technologies become a necessity – without a smart filter DevOps loses control and their ability to action events is severely restricted, which in turn slows down the development cycle. If the initial desire was an adaptable IT environment, then new AI technologies must be deployed to ensure this strategy remains commercially feasible.