DevSecOps is an enterprise software development approach that encourages an agile relationship between Development and IT Operations teams. Increasingly, large organisations are embracing DevSecOps practices to become more innovative and agile, while those that haven’t are finding themselves under pressure to keep up with increasing competition and the speed of change.
However, advancing to DevSecOps is no easy feat. The change can be unsettling for teams, taking them from their comfort zones and posing numerous challenges during the transition process. In this article, we discuss five of the more common challenges we encounter working with clients.
1. The Move from Monolith to Microservices
Most organisations use a monolith: a server-side application logic that follows front-end, client-side logic and background jobs defined in the same, large code base. In a monolith application, when developers make any changes or updates, they need to build and deploy the entire stack, hence builds take long and functional/performance testing needs to be performed across the entire stack, which is time-consuming.
In contrast, DevSecOps is about continuous delivery and microservices. However, breaking down the monolith application into several small microservices comes at a cost. A monolith can be complicated; it is not always easy to break down into smaller services. A seamless transition will only happen if DevSecOps Teams have well-defined processes in place that include automation, configuration management and continuous delivery, to be able to cope with the increased operational workloads that microservices bring. In addition, team members should have their roles well-defined within the teams and all individuals should take ownership of deployments.
With well-defined processes and roles in place, organisations can begin the transition to daily or even hourly deployments. Using an intermediate application design, teams can ease the transition to a microservices approach.
2. Dovetailing Devs and Ops
Companies working with a monolithic application tend have a disconnect between the development and operational teams. Ownership of the code is passed on from one to the other at the point of readiness and delivery. DevSecOps , as the name implies, aims to combine the two functions, integrating ownership at each stage of the software development cycle.
The shift to DevSecOps can be challenging for companies used to the traditional structure. Development of new skills and transfer of knowledge is essential between the two groups. Training and support during the initial transition stages is essential, not only to make sure new releases don’t suffer, but also to ensure that engineers are well-equipped and confident to take on the new structure. A change in mindset comes hand-in-hand with the shift to DevSecOps , which can be one of the most challenging things for developers and operational engineers who are accustomed to the older way of working.
Through training and experience, over time, all members of the team can be individually equipped to tackle development and successful deployment of their work. Until then, presence of an Ops expert is desirable, not only to train the team but during the initial stages of transition, to ensure uninterrupted releases.
3. Excessive Focus on Tools
There is another challenge that companies need to consider when moving to DevSecOps . Teams tend to get carried away with the new technologies before even starting with DevSecOps . Teams may spend a lot of time on tools that may be unsuitable for them, and at times teams may not have the required knowledge to use the tools, resulting in time loss and delays or even incorrect setup of tools. Selecting the wrong toolset can be fatal for the transition to DevSecOps .
What teams really need is to take a step back and formulate the right processes for themselves. The right process will define the right tools they should be using, and in so doing help the team to quickly come up to speed with them, saving valuable time.
4. The Clash of the Toolsets
Development and Operations have different priorities and likely the two camps are using different toolsets, albeit for similar purposes.
Neither team is likely easily convinced to discard either of their tools, which presents the potential for conflict. In general, we're all resistant to change, especially when it threatens to disrupt the status quo.
Typically, Dev and Ops need to evaluate and select the most appropriate toolset for the newly formed DevSecOps team. The process could either result in starting off with a new toolset or just using some existing ones. Avoid rushing the selection process as this could lead to environmentally incompatible tools.
5. Automated Testing
Test Driven Development or TDD, is a test-first development approach which is well suited to DevSecOps . By including testing as part of the development pipeline, in case of a failed test, developers can pinpoint and resolve the issues easily, in the end ensuring that their work meets the requirements and reducing risks being passed on to the final product.
DevSecOps favours the practice of continuous development and deployment; for smooth, risk-free production releases, it is essential that the testing stage of the software development cycle is automated.
Integration testing of the whole product is vital in any development cycle. Processes can be put in place to automate performance testing with timely (ideally daily) runs as and when changes are deployed to pre-prod environments. By adopting TDD and eliminating bugs at a feature level, the risks of failure at the integration level can be minimised. Post-test analysis can also be automated using scripts and tools to consolidate results and draw out appropriate metrics. Thresholds need to be set accurately to make sure performance is not surpassing acceptable levels. For the same purpose, the use of baselines is also crucial; historical data/ test results need to be accessible and compared against to ensure that performance remains consistent, or even observe improvements when expected.
Evolving to DevSecOps wholly will take time, and given the teams combat these challenges in a strategic manner, following these new practices can prove extremely beneficial to businesses, allowing them to keep up with ever-changing market demands.
