Over the past decade we’ve seen a movement away from traditional, siloed software and application development towards a new approach called DevOps. What is DevOps? It’s an approach to application development that involves software development and IT operations working together to shorten the development cycle and produce more effective software more efficiently.
Now, we’re seeing an additional evolution of the DevOps model towards something called DevSecOps, which takes the DevOps model and adds security to the mix. But why is there so much evolution and change in software development? Why are less stove-piped and less siloed development approaches necessary? And why is security now becoming a part of the process?
To understand that we need to first understand what the development process looked like in the past.
Two teams, one mission, no coordination
Before widespread DevOps adoption, the process of developing software was done in stages, with the development team working on an application within a test environment for what could be months on end. The operations team would only get involved once it was time to deploy the program.
In this environment, developers were effectively taking completed software and “chucking it over the In this environment, developers were effectively taking completed software and “chucking it over the wall” to the operations team. If that operations team was lucky, the software was accompanied by instructions for deployment, but those were often long, unclear, or otherwise difficult to execute on. The end result was frustration and suboptimal software deployment and performance all because of an invisible wall that existed between two teams that were working towards the same goal but doing so separately.
After months of hard work, developers would end up seeing a product that wasn’t running as it was designed, and operations teams would argue that they had to overcome flaws in the design to get it to work outside a test environment.
In the end, a rigidly staged production strategy in which a package is chucked over the wall from developers to operations would lead to delays. It would also result in problems that had to be worked out in the late stages of production, and produce unnecessary friction between teams. However, while it wasn’t optimal, it still worked. Until it didn’t.
The assembly line accelerates
All things change – including software and application development. Over time, changes and advancement in how software is structured and built led to an acceleration in software development and resulted in new versions and updates to software happening more frequently. Much of this was driven by the adoption of smaller, more granular and thus easier testable services, even microservices, which enabled developers to change a single part of an application or system independently and quickly.
Much like Lucille Ball in the chocolate factory, this process could not keep up with the pace that was coming to be expected. A system that was flawed to begin with was suddenly straining to keep pace and was destined to break down.
By breaking down the barriers between the development and operations teams, DevOps helped to solve this problem.
Under the DevOps approach, teams with a stake in the end product get together and share requirements earlier in the process. Automation and self-service are employed to enable developers to easily access the resources that they need for Agile application development. And collaboration between the two teams ensures that potential later stage problems are solved earlier while they are more manageable.
For example, the operations team can make sure that its stability and reliability standards are met from the start of a project and don’t have to be re-engineered into it when it comes time to deploy it. Simultaneously, developer teams have their requirements laid out as they go about building the program.
When implemented correctly, DevOps gives teams a more holistic view across the whole production cycle, which leads to software that can be produced with a higher degree of availability and reliability.
However, for all the benefits that this approach to producing software yields, it is not enough for development and operations teams to move all of their requirements further to the left of the cycle, just as it is not enough for software to be produced quickly and reliably. In today’s cybersecurity threat environment, security requirements—alongside those of development and operations—need to be baked into the production cycle as early as any others.
