Nine Trends That Are Influencing the Adoption of Devops and Devsecops in 2021

Over the past few years, DevOps and DevSecOps have revolutionized the way that many firms approach software development and management. The terms have become so frequently used, in fact, that they have become a euphemism for well planned and executed software development.

While it’s important to recognize the value of both DevOps and DevSecOps, however, they are not one-size-fits-all, monolithic, permanent paradigms. Instead, both approaches are developing within themselves, and what DevSecOps looks like this year may be quite different from next year.

In this article, we’ll take a look at that ongoing development – isolating and explaining nine key trends that are driving and changing the adoption of DevOps, DevSecOps, and a number of related approaches to development and management.

1. The rise of DevOps

First up, we’d be negligent if we didn’t mention by far the biggest trend in DevOps and DevSecOps at the moment – the fact that both approaches have exploded in popularity over the last few years. 

The reasons why the approaches have become so popular are well known to most developers and managers – not only do they provide a more integrated way of managing cybersecurity risk, but they can also (and slightly counter intuitively) make development processes and teams far more agile. 

This is because DevOps effectively spreads required tasks between both operational and development teams. With less people working, the more efficient they can be. 

Despite the challenges of adopting these approaches, the potential gains to be made are generally seen as justifying this risk. For most development teams, this will first mean moving to a DevOps process, and then later evolving DevOps into DevSecOps.

Beyond the operational gains that can be made during this transition lie a number of other advantages. One of the often overlooked effects of just how widespread DevOps has become is that, for many developers, it has become the default way of working. According to open source contributor and DevOps expert Barbara Ericson of Cloud Defense, “DevOps has suddenly become so ubiquitous in software engineering circles that you’ll be forgiven if you failed to realize the term didn’t exist until 2009...DevOps extends beyond the tools and best practices needed to accomplish its implementation. The successful introduction of DevOps demands a change in culture and mindset.”

This trend is only likely to continue in the future, and could make it difficult for firms to hire talented developers if they are lagging behind on their own transition to DevOps.

2. Monolith to microservices

Now, let’s turn to the technical trends that are driving DevOps adoption, and will continue to define its future in the years to come. At the broadest technical level, the transition to DevOps is accompanied by a parallel transition aware from monolithic architectures, and toward those that are composed of a network of smaller, more agile components.

There are several ways in which this general trend is manifest in practice. The rising popularity of containerization – which we will come to shortly – means that deployment of software is now generally handled via container hierarchies. At a broader level, these new architectures are symptoms of a broader shift away from centralized servers and systems and towards microservices – a way of designing software applications as suites of independently deployable services.

This trend has not been without its critics, and can often present as many challenges for organizations as opportunities. But with more robust and mature approaches to multi-cloud security management continually being developed, the general direction of travel here seems inevitable.

3. Cloud as default

The move toward microservices and containerization has also helped to accelerate a related trend, and one that has now been running for almost a decade – developing and managing software in the cloud as the default approach. In fact, for many younger developers, it might sound strange that this is a “trend” at all. Haven’t we always strived for data transparency, except where they need an extended level of protection?

Well, no. Back when DevOps was first being developed as a coding and management paradigm, one of the major headaches of planning the transition to it was building cloud services that could be efficiently and safely accessed by teams with widely different needs – developers, operations staff, and even customer service departments. Now that a number of well-designed services exist to meet this need, we can plan software that runs on the cloud by default, but this is a consequence of the success of the DevOps model, rather than a prerequisite to its emergence.

4. Kubernetes

At a more specific level, the influence of containerization on the ongoing development of DevOps and DevSecOps is difficult to overstate. And for most firms, containerization means one thing – Kubernetes. 

The popularity of Kubernetes, alongside Docker as part of a containerized infrastructure, is directly related to some of the shifts that we’ve detailed above. In fact, containers have become so crucial to the kind of decentralized, massively parallel approaches now used for software development that it’s difficult to imagine DevOps without them.

This is because Kubernetes facilitates the building of an infrastructure based not on centralized control, but instead on a carefully overseen creative anarchy. Most DevOps teams now allow even junior members of their teams to make what would’ve been regarded as large changes to active software repos, but containerization means that these changes are backed by continuous detection, which ensures it is significantly faster for teams to manage updates and upgrades.

In the most extreme implementations, in fact, Kubernetes and container management systems can reduce the need for operations teams to manage software shipping at all. As platform teams run the stack, individual teams have the permission and isolation they need to ship as they see fit. This is generally referred to as a ‘NoOps’ scenario, and appears to be gaining in popularity as automation becomes more sophisticated and easier to deploy. 

5. Agile infrastructure

Though these movements toward flexibility are most familiar as part of the software development lifecycle, it’s worth remembering that they have their routes outside this discipline. The desire for real-time flexibility in production processes can be traced, in fact, to similar trends in industrial and manufacturing design that have been decades in the making.

In the industrial and manufacturing fields, designing flexible infrastructure has long had a name – the “Agile” approach. This approach highlights the importance of highly robust, highly connected, and yet relatively inexpensive infrastructure. It also taught large manufacturing companies the value of many of the characteristics of software companies – collaboration, organization, diversifying skill sets to achieve resilience, rapid iteration and self-improving work processes.

Now, the influence seems to be moving in the opposite direction. Software developers are now finding that industrial designers have plenty of experience with IoT networks, in particular, and have developed approaches to designing hardware infrastructures which are able to keep these systems both agile and safe. 

6. End-user automation

The promise of DevOps is not limited to making the job of developers and operations staff easier, though. By bringing both teams together into one unit, it’s also hoped that communication between them will be made much more efficient, and the processes that inherently involve both teams will also be more effective.

For most firms, the most critical collaborative process which requires input from both teams is shipping software. This is why, over the past few years, we’ve seen the emergence of a new family of automation tools that aim to make release and deployment of new software much easier. An example would be reference code scanning tools that automate the usually manual activities that accompany code delivery. The promise, here, is that the technical process of releasing new software (or updating existing software) can be completely automated.

This doesn’t mean, of course, that development or operations teams will not be involved in releasing software. But it does mean that these teams can focus on what’s important – ensuring that software meets consumer and managerial requirements – rather than the technical details of how it is going to be shipped.

7. Resilience, not protection

Although DevOps and DevSecOps were primarily developed as managerial solutions, they are also having knock-on effects on the way that software companies approach cybersecurity at a philosophical level.

As we’ve previously pointed out, incident management in the age of DevOps is radically different from the kind of crisis management that occurred before it. In the days when new iterations of a software package were shipped (and sometimes literally sent on a ship!) once a year, developers had time to rigorously test each release for security vulnerabilities, and often many months to fix those that they had overlooked.

That is no longer the case, but that need not be a bad thing. Because of the rapid release schedules that the DevOps era has ushered in, many security analysts now see their job as providing resilience to software, rather than protection per se. Instead of the unrealistic expectation that every security vulnerability can be patched, many DevSecOps teams now work on the assumption that every piece of software will be vulnerable, and focus on protecting other pieces of software from the consequences of this.

8. Advanced malware and APTs

The move toward distributed clouds, microservices, and cloud-first software development has made the best DevOps teams much more flexible than traditional approaches to software development and management. It has also, however, come with significant challenges.

The most direct of these has been the rise of advanced forms of malware, often deployed by APTs, that are able to take advantage of the distributed nature of modern software development architectures. According to cybersecurity expert Ludovic Rembert of Privacy Canada, malware remains a major risk for software today, “Sometimes, malicious software is bundled into a software package that appears benign. Frequently, these programs are downloaded from the Internet, and they may include software made by third parties...while some of these websites are legitimate websites that are being attacked by a nefarious party, other websites are created solely for the purpose of infecting computers with malicious software.”

Furthermore, some of the more advanced types of malware are able to intercept data being passed between the various components in distributed cloud systems, undermining their security.

This is one reason, of course, why teams that have long worked with DevOps approaches are now transitioning to DevSecOps, and why for many organizations it will make sense to transition from “waterfall” approaches directly to DevSecOps – as long as the transition is carefully planned, bringing security teams into the development and maintenance process can make software far more secure. This can only be achieved, however, if security is taken seriously as infrastructure is designed, rather than attempting to impose this at a later date.

9. AI and ML

Last but definitely not least, we have AI and ML tools. Though DevSecOps teams are still working out how to use these at scale, it seems all but inevitable that AI will eventually have an enormous impact on DevOps.

What this will look like in practice is still a little unclear, however. On the one hand, it could be that the advanced automation that AI and ML tools can provide will allow many teams to forget the Ops in DevOps altogether. In this imagined utopia, operations will be entirely handled by AIs, and developers will be free to mark code for release without having to deal with the complexities of actually implementing it.

If that sounds like a fantasy, that’s because it probably is. Though AI and ML tools certainly show promise when it comes to taking the repetitive “leg work” out of  software management, they will not eliminate it altogether. Instead, operational teams are likely to become managers of automated management systems, rather than being automated away.

The Future

So there we have it – the key trends driving development of DevSecOps. 

Or, should we say, the various types of DevSecOps. Because, when it comes to assessing what’s next in DevOps, we are immediately faced with a problem: there are as many different forms of the practice as there are firms using it, and each of these is developing according to its own logic.

Nevertheless, it’s still just about possible to see where software development will move in the future, and that’s how we’ve described it above. It will be more agile, less centralized, and more automated. And ultimately, for both development and operational teams, that’s great news. 

About the Author

Sam Bocetta is a former security analyst, having spent the bulk of his as a network engineer for the Navy. He is now semi-retired, and educates the public about security and privacy technology. Much of Sam’s work involved penetration testing ballistic systems. He analyzed our networks looking for entry points, then created security-vulnerability assessments based on my findings. Further, he helped plan, manage, and execute sophisticated "ethical" hacking exercises to identify vulnerabilities and reduce the risk posture of enterprise systems used by the Navy (both on land and at sea). The bulk of his work focused on identifying and preventing application and network threats, lowering attack vector areas, removing vulnerabilities and general reporting. He was able to identify weak points and create new strategies which bolstered our networks against a range of cyber threats. Sam worked in close partnership with architects and developers to identify mitigating controls for vulnerabilities identified across applications and performed security assessments to emulate the tactics, techniques, and procedures of a variety of threats.