Evolution, Revolution, or Neither?
The DevOps trend continues, but I still don’t know how I feel about it. Actually, maybe I do since I subconsciously wrote the term “trend” when thinking about it.
The ultimate goal of DevOps is to improve the speed and quality of software development. It advocates using automation at each phase and aligning the pre- (development) and post- (operations) deployment teams via short development sprints. It’s a culture movement and practice that reaps the benefit of improved communication and involvement of all team members in one integrated process. It’s a Venn diagram where the intersection of software development, quality assurance, and operational maintenance is given a new name: DevOps.
The alignment of developers and operations personnel should foster low latency, closed-loop communication. This helps increase the frequency of deployments, which helps to service customers faster. An additional benefit is that DevOps promises to avoid the all-too-common Development vs. IT battles that arise when the development team tosses applications over the proverbial wall only to have the operations team find it doesn’t work in production… and then the blame game begins: Development teams declare “it worked in our staging environment; you must have deployed or configured it incorrectly” and IT shouts back “go build it so it actually works in the real-world.”
Thinking about this and talking it through with team members here at Security Innovation gave me flashbacks to the 1990’s when I was working at Rational Software and talking with my boss Sam. I quite literally had the exact same conversation with him when discussing how our products would solve the exact same problems… in precisely the same way! We even wrote books and created a “new” software development process that embodied these characteristics. It was called Rational Unified Process (RUP), an iterative software development framework that heavily leverages automation, shares work items across all teams, and streamlines communication from inception through deployment.
Agile, eXtreme Programming, continuous integration, The Microsoft SDL, and a number of other process methodologies were also built on the same premise – faster sprints versus marathons, using automation wherever you can, aligning team members and sharing assets, blah, blah, blah.
Some people are hyping DevOps as revolutionary. To me it feels like a minor evolution at best.
Before you think I’m just here to beat up DevOps, let me mention that I love the idea of smaller sprints to improves quality and time-to-market. I also am a big fan of automation and streamlined communication amongst team members. Who isn’t?
The promise of DevOps bringing down organizational barriers hasn’t yet materialized (any more than other “movements” had already) – but it is certainly far from a reality for security. Building security into the development tool chain and strategically implementing security automation are requirements for breaking down these walls. In addition, shared organizational responsibility between application teams and security with executive sponsorship is necessary— without everyone having a stake in the secure SDLC initiatives will fail to deliver. DevSecOps has an added layer of complexity because many organizations have security teams that are separate from both development and IT operations.
The speed at which applications must be brought to market, coupled with the need for more secure code, will have the industry continue on this DevSecOps path. And most likely, when the next paradigm shift occurs, there will be another Buzzword (DevSecOps is a mouthful!) The core tenants of culture shift involve teams being more respectful and knowledgeable about one another.
Development & Operations, is a duo that have been tasked with building and deploying secure software since the invention of software. So if creating a buzzword is what it takes to get the two groups to feel they’re united in a common goal, then I’m all for it. But let’s call a spade a spade: we’ve been making incremental improvements as to how software should be built for decades as we learn from mistakes and respond to a market pressure that will never go away. I again recall something my former boss, Sam, said to be around 2000, “We’ve been telling folks how to build quality software for 20 years… and nobody has listened to us yet.”