When considering the mysterious definition of DevOps, you’ll often see statements like:
Hang on a minute. What about quality, security… compliance?!
DevOps is not new. The term has been around for nearly 10 years and the concept has been around for decades. To quote a friend, Daniel Breston: “I was doing DevOps in the seventies, we just didn’t call it that.”
However, there are still some misconceptions around how quality, security and compliance fit in with with DevOps, and this is where DevSecOps comes in.
At its core, DevOps is a process of transformation and continuous improvement, and this is where I’d like to begin.
I have taken an unconventional journey towards DevOps. I started in 24×7 operations and worked backwards through the delivery lifecycle: Ops Support, Service Owner, Environment Manager and Architect. Notice the glaring omission there? Dev, that’s right. I’ve never been employed as a developer, although outside of work I have done voluntary work as a developer.
Let’s take this back to basics. When I am doing my voluntary work, I am the business analyst, the architect, developer, tester, and of course if it breaks, I am the operator. This effectively removes the bureaucracy and hand offs that exist in the industry, and my feedback loops are instant. It breaks; I fix it. It’s blue and supposed to be orange; I change it and verify (test). Simple, right?
Now not for one second am I suggesting that large organisations should expect everyone to do everything. In fact, far from it.
What I am saying is, you should start to blur the lines at a team level. Co-locate the middleware person with the architect and maybe even the business analyst to start with. You’ll soon see that the person receiving the work starts to look at the person who is inputting to that work. As the lines start to blur, knowledge will slowly start to be shared. Why? Because the person receiving the work can influence the timing and quality of the input they are receiving before it’s delivered.
For your next step, perhaps add the monitoring expert in there as well. They’ll be able to influence the logging level and parsing to ensure suitable error messages are captured upon failure right at the time the code is being created.
Hopefully you’ll be picking up by now that building a DevOps capability into your business is not simply a matter of flicking a switch. Tools are easy to spin up, and processes and controls easy to define, but culture and mindsets are a different matter.
I could write a book – more than one – on cultural change, but they’ve been written before. So here is my ultimate tip: cultural change is easiest (though not easy) in a safe environment for the people being asked to change. Safety comes in many forms, of course. It often depends on the person – let’s not forget we are talking about people here, not robots. It comes down to leadership, reassurances, stability, and more.
For me, it was the ability to see a future for myself where I was adding value and being challenged. Everyone is different, driven by different goals.
DevOps enables your teams to go faster – but that doesn’t mean degrading quality. Far from it! What it does mean is taking a different approach.
Gone are the days of waiting until the end of a lengthy development and test cycle to do a ‘pen test’, only to be told you can’t release. It’s too late, too expensive!
Why not deal with security issues before release? Address them before test cycles. In fact, push the fix right back into the development phase. It’s easier, safer, faster and cheaper to fix in development.
Let’s bring it all together. Don’t pass security issues forward, just as you wouldn’t pass forward a functional defect. Move security to be synchronous with your faster DevOps delivery cycles.
Born is DevSecOps.
DevSecOps was the subject of a recent webinar by Clearvision and Sonatype, part of our ‘Enterprise at Scale‘ series.