Qualys: How to be cool with DevOps
The Computer Weekly Developer Network asked, is 2018 the year of the DevOps backlash?
Well, it was only meant to be an open question, a hypothesising supposition, a point of informed speculation that might lead to an informal pub discussion at best.
But, as is often the way with these things, the industry has taken it as a clarion call for commentary and deeper analysis… and who are we to turn down the opportunity for deeper inspection of the DevOps state of the nation?
First among a small group of spokespeople invited to deconstruct modern DevOps is Chris Carlson in his role as vice president of product management at cloud security, compliance and information services company Qualys.
Carlson writes as follows…
All processes and technologies have a hype cycle, growing pains and detractors even as they become mainstream and common place – DevOps is no exception.
DevOps drives much more value than software development methodologies like Agile, because DevOps extends beyond and spans much more than just the development function in any given organisation.
DevOps extends very much into operations, of course it does [that’s why it’s called DevOps], but also and just as importantly, DevOps extends its influence into business strategy, competitive strategy, financial strategy, product management, release planning, customer service, even employee recruitment and retention.
While manual actions can be used to add new capabilities into a DevOps process initially (like performing vulnerability assessments during the development phase so that insecure applications are not released into production) – over time, those manual actions tend to be performed less or ignored entirely. Only by automating the manual action and integrating it into the end-to-end DevOps pipeline can it be sustainable.
As with any (new) process utilising (new) technologies in a different fashion, the ‘cultural transformation’ is as important as the tool or process transformation.
Being cool with DevOps
All stakeholders, constituents and consumers need to have bought into the approach, process, tool usage, metrics, monitoring, feedback and continual improvement. Doing DevOps because it’s new or cool will create more failures cases that don’t necessarily prove that DevOps is not successful or valuable.
Successful DevOps – and DevSecOps – implementations aren’t only driven top-down by executives, but also can be bottom-up driven by practitioners to create incremental and continual improvements in existing development and operational processes. Even top-down initiatives need a successful cultural transformation for successful DevOps/DevSecOps projects.
While an organisation can have a successful initial DevOps project without cultural transformation, the likelihood that the success and benefits are sustaining becomes much lower. There is a lot of excitement to try new processes that get buy-in at the beginning, but without continual organisational support (or automation), it’s natural for people to fall back to the old ways of doing things.
Tactics, strategy, objectives
The metrics of successful DevOps projects are more tangible if they are driven by [intelligent tactics that lead to well composed] business strategy and objectives.
Development teams becoming more efficient in a vacuum might save some costs within that one department, but successful business initiatives fulfilled by a successful DevOps implementation drives revenue and market share increases for the organisation as a whole.
Cyber issues (information risk management) becomes even more important in DevOps than improvements in isolated standalone development methodologies. If a development organisation goes Agile but still uses waterfall methods to build, package and release its business applications, there are still check points for IT security to assess, evaluate, and approve new code prior to implementation to production.
DevOps accelerates the release of applications into production that can completely bypass IT security assessments.
This is where DevSecOps becomes even more important – not as a way to slow down DevOps to force in or bolt on security – but rather a way to seamlessly build in security into the fabric of the DevOps people, process, and tools.
Dude, be cool, this is DevOps. Image: Qualys