DevOps-Is it becoming Continuous billing?

DevOps is walloping up IT shops and like it or not, all have to roll along in the great DevOps marathon.  We all have to be cognizant of this upcoming wave and consider aligning our expertise and operating model to this world.

Everyone have their own interpretations and way of using DevOps to solve their business problems (like, 'I don't like this fella, lets DevOps him'). Let me share on whats DevOps need to be doing. I am heavily colored by experiences with projects that took too long and fell out of end user's favor and I acknowledge that there could be more than one use cases for DevOps.

Objectives

1.  DevOps originates from need for agile infrastructure where Development team and  Operations collaborate.

2. Quick releases and reduce time to go to market. This I believe was not one of original goals but a natural outcome as conflicts diminish thus reducing the need for paperwork and process. It may also be an outcome of market demand of doing things better, faster and cheaper.

Current State

'Automation' driven DevOps conveys message of quick and rapid releases to production and everyone has to tag onto bandwagon and participate in short sprints. Quick automated testing, performance testing, security testing etc. They are considered automated because they are triggered from Jenkins. Then there are System administrators who are forced to be assume sobriquet of DevOps. They do little bit of code writing for resource provisioning, alerts etc to enable them to add Dev. Many developers complain being saddled with admin activities which is a distraction. Release management, software configuration management folks have found a respectable umbrella to work under to deliver outcomes which are appreciated.

Challenges

We need to reflect back on original goal of reducing developer Admin conflict and how that relates to cheaper, faster and better. 'Faster' is indeed an outcome possible due reduction in conflicts, automation of CI/CD and change in way we develop applications.  However, when it comes to 'cheaper' and 'better', there is still no business justification because no metrics capture Dev-Ops conflict. I am sure there are heartburns but that gets internalized and thanks to heroics of players involved things do move along. I have had opportunities to work in some of best places with defect  detection efficiency as high as 99%. Yet when I spoke to Ops team they complained about hundreds of patches/CRs they had to do. I was one of rare people to go and ask Ops team how our software was doing. DevOps should have helped.  We may not have this issue for now but as DevOps gets mainstream the business justification challenge will arise. The issue with 'faster' dimension is that it will be achieved in greater part through scope reduction. That said quality dimension has to reflect through. Taking 'bug' fast to production is not an achievement. Screening for bugs at speed is not something that is mainstream.

Other Challenges

There is other dimension shining through with vendors claiming that DevOps is something they were waiting for eternity and their 'shift-left' proposals will help catch issues early. Studies show catching defect early is six times cheaper etc. This adage has been around for ages but it did not become mainstream. In instances that I noted Continuous Integration had become  continuous billing exercise. Whatever is done in monolithic-Waterfall model, chunks of those are done exactly same way in each cycle/sprint. It is auto triggered by Jenkins and yes there is dashboard but its no good if no actions come out of it. Citing examples of Performance testing, executing a test every day for each new build is good if it were to really run by itself and build is functionally stable enough. Given the functional instability earlier in lifecycle the priority is functional stability and rightly so. As long as we keep doing whatever we were doing earlier, like developer building code and tester executing test cases we will not have DevOps. Creating a new silo DevOps for CI/CD tool ain't DevOps either. If DevOps is about collaboration and bipartisanship I am yet to see who is moving from respective silo roles.

A Better Way

A better way in my mind is enabling 'speed' along with quality. For example compile time checks could be driven by rules set by Ops team. Tickets 'auto-matching' to development defects to get to leaked defects etc. I have little faith in humans shedding respective roles and it should not be intention either for us to have perfect versatile chef serve exotic meals to guest and follow-up with exemplary ChaCha session to entertain them. In a better way, team does play additional roles but AI is what drives to glue team together and help operate at speed.