I recently had an interesting discussion with a client around DevOps. The client felt that for DevOps to happen they need to remove all barriers, security checks, etc., provide full admin right on runtime and infrastructure to the developers and hope the best. Then they will really benefit from this thing.
I took the opposite position and my client seemed to be a bit . . . shellshocked. DevOps is not the mythical thing that dissolves all borders and afterwards all will work. DevOps is an animal with stringet rules that frequently depend on the underlying tool chain. The tool chain depends on how you develop software.
In this blog entry I will explain why I say that.
The term DevOps was conceived in 2009 with the aim to express that things work best if developers and administrators are not enemies. Shortly afterwards a small number of best in class enterprises demonstrated teams where they had brought developers into the position to design, develop, deploy and operate both software & infrastructure. To achieve this teams would need to be managed almost as if they were a close religious group sharing common beliefs into uptime and customer service. The basis for this to succeed was not freedom but rules that need to be followed meticulously. Rules for developing software, testing software and deploying & operating software.
At thsi time, on DevOps conferences you met people telling how the increased responsibilities led to de-layering, the removal of inconvenient stumbling blocks and enrichment of their lives. Just about the same people you met in the first Linux conferences back in 2000 where there was always a session telling people that developing software will enrich their lives to an extend that we can soon uninvent money.
The fact that the first DevOps tools were geared towards systems management and expressing systems/system changes as code only contributed to the client’s confusion.
Five years later, around the year 2014, things took a turn. Larger enterprises had recognized that a DevOps approach where they would integrate teams and manage them semi-religiously would not work for them. DevOps started to become all Dev using the CI/CD pipeline (Figure 1) and a focus on automation as the key to increase efficiency and streamlining software development and deployment. As along as automation works no one really cares any more whether they have unified teams that enrich their lives or not.
In essence you have two sets of automation that are linked to each other:
In this context IT infrastructure operations are providing an environment on that the chosen toolchain is supported and running. The SLAs are on this environment. That is the demarcation line. Decisions need to be made as to what a release is and when new software(components) are deployed. Deployment servers such as Puppet or Octopus offer a number of options for this that include traceability features such as who deployed what, were they authorized, etc..
An exception can be (but do not need to) environments that are based on microservices. Microservice environments can use micro service routing platforms, such as vamp.io that make testing and operation possible on the same production platform. The name for this is canary testing. Also here IT infrastructure operations has the role to ensure that the underlying platform and required tools are running, patched, etc..
It is of course not all black and white and structures and processes are thinkable that are a compromise between the two positions. However, the assumption that DevOps is this mythical thing that dissolves all structures to let the magic happen is based on a misunderstanding of DevOps. Hope I helped to make this clear.