DEVOPS and DEVSECOPS, what’s up with those?
I have a wish to demystify what these two new paradigms, DevOps and DevSecOps, are.
The reason why I use this term is because they are in fact, a collection of practices, which are not precise and without a exact implementation methodology. This is part of the reason for its success. It’s about implementing things almost insidiously. Essentially, to make it so that it becomes part of our daily lives without apparent clashes.
Here at Emyode, this translates into a focus of effort that covers three important aspects of the digital transformation and what these paradigms propose. Either the “people” dimension, the process dimension and the tool or “product” dimension. Also referred to as “people, process and tools”.
What DevOps is not
First of all, I’d like to address a very important point. You don’t call an individual a DevOPS. Certainly, there are people who work well seated between operational operations (OPS) and implementation teams (DevOPS). But both DEVOPS and DEVSECOPS have the will to integrate into the teams and not to create new subdivisions. It’s a very sexy job, make no mistake. To do automation, scripting and infrastructure maintenance via code is certainly very useful. However, it’s just one more link in our value chain.
Don’t rely on me, look instead for the broad definitions of the term and you’ll see that what all these definitions have in common is that they break down operational and functional silos, not create a new one.
Indeed, one of the main principles is that of dividing up common interests. Rather than throwing the work done into the hands of someone uninformed about the creative process, it is better to have someone who knows the product and its manufacturing process. This makes this individual a much more efficient person to welcome the completed work of his colleague and to support him more adequately.
“With a specialist such as the one mentioned above, we risk becoming dependent
of his skills and in fact to have given him the keys of our kingdom.
Thus creating a single point of Failure, which I assure you is undesirable.
It represents an antithesis of the DevOps movement and, in addition, the DevSecOps movement.”
Jean-Paul Lizotte, DevOps Practice Leader at Emyode
DevOps, DevSecOps and its People
You could imagine the industrialization of a process. But as mentioned above, it will be important to consider the human dimension of this change. If we want it to last, we must first of all have people who have a certain conviction of the values that this movement will bring.
It is indeed a digital transformation, a reinvention of what we do. People, no matter what anyone says, will be equipped with new processes and objective measures to analyze performance gains. Rest assured: it is not about bringing in microscopic analysis of work, but about being able to derive the gains from implementations, good ideas or initiatives. But we’ll get back to that.
DevOps, DevSecOps and its Processes
Let’s be clear, processes are at the service of the people who use them. And not the other way around. They are in place to encourage the good use of the “rest” (the tools), but the fact remains that we want the processes to be adapted to the needs of our people. For instance, as my favorite program manager puts it so well: “Processes exist and will be abused by users, but we shouldn’t have processes that abuse our people”. And he’s absolutely right about that. Otherwise, people will find a way to get their way, by any means necessary. And to hell with processes.
DevOps, DevSecOps and its Tools
Without wanting to sound silly, in technology, it is often too easy to end up using a hammer when you needed screwdriver. Making wise choices in terms of tool selection is often better considered by its potential users than technologists. Therefore, it goes without saying that those who will industrialize processes must make a choice that is “need-driven”, rather than for the enthusiasm of being on the cutting edge of technology. We will rather favour the maintenance and the good use of the tools first. Otherwise, we risk having a mismatch between the use and the acquisition cost, if not the operating cost of these tools. Long story short: latest isn’t necessarily the greatest.
What’s the point?
Finally, it is important to have an idea of why these “movements” are necessary and what they are not. Let’s see what these paradigms are trying to address.
In our current series, we will look at some of the issues and possible solutions.
I will try to put them into the different dimensions of people, processes and tools. But to tell you the truth, I’m not very fond of spending a lot of time on tools. The truth is that as soon as we have people well focused on the right activities, the means and governance to put these things in place, the selection of tools becomes almost natural. Moreover, that’s where things evolve often too quickly to follow. What is true technologically speaking, is not always true the next week. But I’ll try to illustrate some of it.
So, what of the two paradigms DevOPS and SecDevOPS (which is synonymous for DevSecOps), of which we still can’t agree on the name?
What the two have in common is first of all the desire to merge the typical concerns of each department (development-security-operations and/or development-operations). As explained above, bringing together these traditional operating silos has beneficial consequences.
At Emyode we say “more projects, faster and more savings”. This slogan is propelled by DevOps. In addition to the fluidity of the realizations, the added value of the achievements is the reduction of risks and costs. But also the increase of the general level of satisfaction (customer and employee), the velocity and quality of the product. Admittedly, this does not fall into our laps. But it is the goal, the destination and not the means to get there. Finally, on this specific subject, you can’t have quality without security, which is why I don’t like to talk about DevOps alone.
However, to be perfectly honest, as an industrialized people, we are way behind on this front. In Europe and even in other parts of North America when we compare ourselves, we are late in adopting this way of doing things. So I have to tone down the way I push these principles, at the risk of losing the interest of my audience. I think it’s important to mention that it’s not because I don’t understand them. But the fear of being buried by the size of the Herculean task of transformation. Let me reassure you in both cases, it is not so. In my last blog I spoke about making this operationalization manageable to mitigate the risk, and managing to go ahead anyway.
You have to take a step-by-step approach, be a little cyclical and have a little vision.
As we say “baby steps” in our vernacular.
To be continued…
In our next articles, I propose to clear up the distinctions between DevOps and SecDevOPS and what they are trying to address together. We will see the main steps of a possible “roadmap”. The guide or GPS of our approach to successfully implement a DevOps/SecDevOps.
Stay tuned for our next episode!