Definition of DevOps
The integration of developer and operation teams with a goal to shorten the development life cycle in conjunction with delivering features, fixes, and updates frequently and in close alignment with business objectives. The ultimate goal is faster time to market for new features and quicker fixes.
There are two very different view-points in the DevOps debate over whether it is a viable and achievable option for the enterprise. For our debate, one stems from thinking DevOps is an Evolution and one thinking it is more of a Revolution.
Ed’s Take - DevOps Evolution
Some people are hyping DevOps as revolutionary. To me it feels like a minor evolution at best.
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 battle 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!”
A Simple Rehash of an Old Idea
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.
A Far Cry from Reality for Security
Before you think I’m just here to beat up DevOps, let me mention that I love the idea of smaller sprints to improve 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.
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 me around 2000, “We’ve been telling folks how to build quality software for 20 years… and nobody has listened to us yet.”
Roman’s Take - DevOps Revolution
I disagree that DevOps is the evolution at best, and tend to think of DevOps as more of a revolutionary practice. Implemented properly it will lead to success across the whole organization for the benefit of the customer. But DevOps cannot only be dependent on the right people and tools, a culture of collaboration and agility is mandatory. Can that agile mentality really be applied to larger corporations?
In an ideal situation developers and operations work collaboratively in a way that produces solutions that not only meet customer expectations but also those of the company with fast deliverables and attention to detail. A DevOps mentality also fosters the opportunity to make changes and improve upon errors quickly.
There are certain universal truths about DevOps that stem from experiences learned through other creative endeavors, and are quite simple ideas: the biggest disappointment is expectations; you don’t know something is good until you try it; life is what happens while you are busy planning it.
The DevOps Success Mindset
The goal of implementing a DevOps mindset is to reduce time to market, and to take into account unexpected events in an agile and responsive way.
Let’s face it, software development is harder than it looks! There is a gap between what the “customer” thinks they want, what the market needs and what is deployed in production at the end of the dev cycle. Time is NOT your friend here. Waiting 4 months to show the product to the “customer” just to find out how big the gap is, is not a good thing. Waiting 8 months for market validation, just to see how big that gap is bad. Rinse and repeat equals disaster.
The ideas behind more of a DevOps mentality offer the opportunity to test solutions that will reduce gaps, release early and often, offer the customer and the market an opportunity to try things, get feedback and actually respond to the feedback in a productive manner, and build on top of the feedback. With the agile mindset, teams can be more flexible, pivot and change quickly as the market dictates.
Of course, the traditional ideas behind planning and foresight are still relevant and necessary but the idea behind a DevOps structure is to be able to respond in a productive and meaningful way to garnish positive results for all involved.
Just for Startups?
There is the idea that DevOps works best at startups. My first job required me to take on the role of essentially, (term was yet to be coined) a DevOps engineer.
Our environment was agile, we spent a lot of time with the customer. We released often, and we broke things with rather frequently! But the point was, we moved the product forward at a great speed as a result.
We still needed to plan, to have a road map for releases and features but the ingrained ability to be agile, to be curious and come back with solutions that benefited the customer were real assets we garnished from working in this kind of environment.
Can the DevOps Mindset Apply to Big Corp?
Then I moved onto working for larger corporations where processes were embedded into even more processes without ever questioning their existence or attempts of improving them. The “if it works, don’t fix it” mentality was prevalent. There were planned release every 4 months like clockwork. Multiple sign-offs and approvals had to be factored into the timeline. Things still broke, just less often, and in my opinion, this caused complacency, nothing was ever improved upon.
I strongly believe that you can take DevOps startup mentality and superimpose it on “big corp.’ This of course is not a new idea. We scale things all the time with today’s new technology.
Scaling the agility of a startup into large enterprises is the main premise behind DevOps and I strongly believe it is achievable and beneficial.
DevSecOps – The integration of Security with DevOps
Regardless of what side of the debate we argue, we can both agree that security is an integral part of this new development process and security is everyone’s responsibility.
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. Building security into the development tool chain and strategically implementing security could essentially lead us to agreement. Of course, shared organizational responsibility between application teams and security, with executive sponsorship is necessary, without everyone having a stake in security, SDLC initiatives will fail to deliver.
If we can make development, security and IT operations work together to make more secure software, because all teams are well versed in security practices, then who cares what we call this thing.
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 regardless of how or what we call it.