One of the prime motivations for switching processes to a DevSecOps approach is reducing the cost to deliver functionality. As a result, in this post we discuss how DevSecOps contributes to delivering new functionality in a cost-effective way.
It is a known fact that engineers are expensive - they require a salary, time off, sick time, and the list goes on. Of course, at Zaden, we believe engineers are worth the expense but when it comes to solving problems that can be solved by computers, an engineer’s time is much more expensive than a computer’s time. With modern techniques, tools, Infrastructure-as-Code (IaC), and Configuration-as-Code (CaC) we lessen the need for engineers to manually set up and configure servers, software infrastructure, product deployments, and more. Now that we have tools that make automation easier, a better investment of engineers’ time is to automate the setup and configuration. Not only is this cheaper, but it’s reproducible by any engineer with a basic understanding of the tool(s) - not just the one who wrote the automation. Because automation is a core part of DevSecOps, you can simultaneously drive down costs and time while making your software products more reliable, maintainable, and resilient.
Another primary focus of DevSecOps is leveraging short feedback loops. Instead of taking several days, weeks, or even months to execute any one part of the Software Development Life Cycle (SDLC), such as Development, only to pass it off to QA who will take an additional several days, weeks, or months for testing we choose to shorten the time frame between these processes - usually to several times per day! How is this possible? A big clue is mentioned in the last paragraph - automation. An effective use of automation is Continuous Integration/Continuous Delivery (CI/CD) pipelines that, among several other things, run a suite of automated tests that are developed in concert with the code. This test suite ensures that changes to the system can be made without breaking previously implemented functionality (also referred to as introducing a regression into the system) and, if a regression is introduced, it can be fixed almost immediately. This clearly reduces costs (and risk) by greatly shortening the gap between when a regression is introduced and when it is found. If the regression was introduced minutes ago, it’s much easier and faster to fix it than if it were introduced weeks ago, for example, because the change is fresh on the developer’s mind.
While these are clear examples of ways that DevSecOps reduces costs during the SDLC, this is not anywhere close to an exhaustive list. Additional cost-saving properties of DevSecOps include (but are still not limited to): enforcing maintainable code through static analysis and quality checking tools, continuously checking for security vulnerabilities so that they can be addressed early in the development process rather than having a zero-day vulnerability, and more.
Comentarios