The Rise of DevXOps: Extending the DevOps Culture Requires Wisdom and Caution

This article is featured in the new DZone Guide to DevOps: Implementing Cultural Change. Get your free copy for insightful articles, industry stats, and more!

Over the last few years, we've seen the emergence of a new type of discipline in the DevOps landscape. I call it "DevXOps". A DevXOps discipline is one that's established to fill a gap left unaddressed by general DevOps practices.

One of the DevXOps disciplines that's getting a lot of attention these days is DevSecOps. DevSecOps has come about because security has been, for the most part, an outlier in the day-to-day software development lifecycle (SDLC) process. While it's true that security is and always has been a paramount concern for all within the enterprise, most security practices take place outside of the software development process. Many, if not most, security practices are concerned with keeping bad actors from getting into the environment and ensuring a company complies with industry standards and regulations such as those dictated by PCI-DSS and GDPR. As such, most of the attention given to security matters comes downstream in the SDLC in the forms of auditing as well as testing to determine environment security.

All of this is good; however, auditing and downstream testing leave a gap. If the practice of DevOps has taught us anything, it's that you cannot test or audit better security into a product or process. Testing and auditing will only reveal a shortcoming that should have been addressed earlier on in the process.

The DevSecOps movement came about by folks who wanted more emphasis put on securing features and processes at the onset of development, not afterward. According to cybersecurity expert and DevSecOps advocate

Ben Strother, CISSP:

"The difference between DevOps and DevSecOps is that DevSecOps puts greater focus on reducing risk by adding data protection, continuous compliance monitoring, code analysis, threat modeling, vulnerability assessment, and security training into the mix."

The DevSecOps community promotes a set of best practices and publishes tools that make its philosophy apply to the real world needs of the enterprises operating at web scale. The organization is actively working to extend security into the fabric of the automation and continuous deployment practices emblematic of modern DevOps.

Another DevXOps practice that's emerging is DevTestOps. The DevTestOps movement has come about to give test practitioners and testing activity a central role in the DevOps culture. According to Lisa Crispin, Test Advocate and Author at mabl:

"DevTestOps is about building a DevOps culture in which testing activities and testers are given a central role in the software development lifecycle, from the beginning, and throughout the process."

DevTestOps fills in the gaps in testing that have been left unaddressed when implementing fully automated, continuous testing at a large scale in cloud environments. DevTestOps focuses on extending the promise of comprehensive testing and automation by better accommodating the increasing complexities of distributed applications intended to run on the internet at web scale. The Internet of Things and ephemeral, serverless computing are pushing the limits of traditional testing paradigms, both manual and automated. The new thinking is that cloud computing requires an approach to testing that is essentially cloud-based too. The operational phrase is, "Run on the cloud, test on the cloud."

In addition to making testing more cloud-based, DevTestOps promotes incorporating artificial intelligence into general testing practices. In other words, applications that use AI need to be tested by automation that uses AI.

There's a good argument to be made that just about any aspect of DevOps can benefit from special attention. The rate of technological change is so fast these days that no one part of DevOps can remain static. Ongoing improvement must happen in order for DevOps to stay viable. If special communities need to emerge as a subset of DevOps in order for the necessary improvements to occur, then so be it. Yet, while the DevXOps pattern provides benefit, it can also incur risk.

In DevOps, the core operational unit is a single team that is made up of people from all walks of life in the SDLC. In DevOps, a team is completely accountable for all aspects of the product or service under its purview. If the product or service has a shortcoming, it usually means that the team has a shortcoming. Saying that the developers did not do their job or QA fell short is a "blame mentality" that should be avoided when practicing DevOps. No one person made the software. The team made the software and thus is responsible to make sure it works as expected.

If we're not careful, a DevXOps initiative can undermine team unity. As more DevXOps movements emerge from the DevOps landscape, one can imagine conflicts occurring in which a proponent of a particular DevXOps subset — for example, DevSecOps — accuses a DevOps practitioner of not being "DevSecOps enough" — thus, the need for caution.

Creating specialties can create divisions in an enterprise that run the risk of building walls that put some on the inside and others on the outside. In order for the DevXOps pattern to be an effective way to bridge gaps and make improvements in the practice of DevOps overall, we must make sure that any special community that emerges is one that is open and accepting of others. Becoming part of a DevXOps community should require nothing more than embracing the mission, following the best practices, and learning the skills necessary to make a meaningful contribution.

To my thinking, any DevXOps initiative should be short-lived. You can think of any DevXOps initiative as an operational pull request into the main branch of DevOps overall. Once its work is done, when the best practices have been established and its tools become commonplace, the DevXOps specialty should be absorbed into the parent. Otherwise, we run the risk of the branch becoming a fork. Forks, by nature, take on a life of their own and can lead to fragmentation of a community. The last thing that an enterprise embracing DevOps needs is a war of conflicting approaches that essentially solve the same problem. Remember, the fundamental feature of DevOps is the cross-functional team that works together in a unified manner. Fragmenting a team in any way has serious consequences.

The DevXOps pattern has great potential benefits provided the given instance of the pattern makes a significant improvement to the DevOps culture overall and builds bridges that bring people together. The value of a specialized DevXOps community is that it allows experts to gather together to solve complex problems that are beyond the understanding of most. Conversely, a DevXOps initiative can run the risk of fragmenting the community from which it emerged should dogma exceed its sense of mission. DevOps is about teams working together in a unified manner. Any instance of DevXOps that comes along will do well to support a team's unity, not distract from it.

This article is featured in the new DZone Guide to DevOps: Implementing Cultural Change. Get your free copy for insightful articles, industry stats, and more!