How many times have you read DevOps as job title? Or a job advertisement searching for a DevOps? Or the desperate search for a DevOps to automate everything?

Well, let’s put some order. Here some examples of what DevOps is not:

• A name for a job, or an operation team
• A person doing everything
• A specification or a product
• The usage of this or that tool
• A kind of magic

DevOps is a set of software-development practices that combines a software development mentality with other functions in the organization. DevOps puts a heavy emphasis on shared responsibilities across all teams throughout the software development life cycle. The edges of job functions soften, as operations team members take on tasks that were traditionally more developer-focused, and development team members do the same. The term DevOps is most commonly associated with development (Dev) and IT operations (Ops), but the approach can be extended to other groups as well, including but not limited to security (DevSecOps), QA, database operations, and networking.

Patrick Debois

According to latest definitions, DevOps is the practice of operations and development engineers working together through the entire service lifecycle, from the design and development process, to production support, including the applications and the systems.

CAMS model

And I think it is useful to introduce the CAMS model to really understand what we mean for DevOps:

• Culture
• Automation
• Measurement
• Sharing

That’s interesting, but what is that for? First, it is the realization it is not simply a technological issue. Or that it is enough to automate everything and we will have implemented DevOps. That’s the opposite.

It is the realization that DevOps addresses a human problem. Automation can accelerate delivery speed, can unblock DevOps benefits, but first of all there is the need to change people’s behavior. For a real improvement, it is useless to automate everything, if at the end you are still going to push into production huge changes, while crossing fingers that there will not be issues in production, and anyway in that case you are going to leave them to oncall people.

That’s not the way it works. First of all, DevOps points on shared responsibilities. Points on changing behaviors. Then, there is the automation as multiplier. But as multiplier, not as the only thing that magically is going to do the trick.

And there are others points to highlight. Measurement is needed to ensure we observe system behavior and we collect proper feedbacks. And we need to measure, to set in place observability and metrics, for what really matters. Measuring what is done, what addes values. That, for example, is not for sure the number of pull requests merged.

And there is the sharing part. Automating is a multiplier. But automation increases compexity, does not reduce it. Requires more specialized people. And requires a proper mindset, avoiding silos. And this requires teamwork, attitude to collaborate and not to compete, and transparency. For sure, it is not at all all a matter of knowledge.

Conclusion

Culture, automation, measurement, sharing, they have to go in parallel. Pushing all the effort on one item… is not going to work. And is not DevOps.