DevOps is not a job title, and here's why:

First of all, to understand what DevOps is and what it's not, we have to take a step back and remind ourselves how the SDLC (Software Development Life Cycle) worked in the past.

In short, there was a Development team that, after successfully implementing and running a project in local development environments, would "throw the code over the wall" to the operations team, consisting of IT admins and network engineers, responsible for delivering the product to the market with the help of other departments.

The real challenge was that the developers weren't held accountable for what they delivered and the reliability and scalability of the solution. This led to infinite tension between the development and operations teams, often resulting in shipping delays and financial losses.

Around 2009, this problem, along with the complexity of applications and infrastructure, was addressed with the creation of a DevOps culture. Developers were encouraged to closely cooperate with the operations team and take full responsibility for the delivered solution/software. This meant ensuring that the code was reliable, thoroughly tested, and that the solution was scalable. On the other hand, the operations team had to ensure a robust infrastructure and a smooth deployment/shipping process.

As you can probably already tell, DevOps is not merely a job title or a specially created team. Thinking about DevOps as just a distinction between developers and some special DevOps role is detrimental, just as it was in the past.

DevOps is a way of creating an organizational culture – a culture of cooperation and communication. It's about taking responsibility for what you build and cultivating the right mindset. Working together as one team towards a common goal will lead to great success.

Moreover, DevOps influences the application lifecycle throughout its plan, develop, deliver, and operate phases. Each phase relies on the others, and the phases are not role-specific. In a true DevOps culture, each role is involved in each phase to some extent.

*** Because of huge system complexity and wide range of tools needed to deliver software to the end users the separate DevOps and SRE roles started to be introduced alongisde DevOps concept and overall culture.

*** I recommend the book "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win" by Gene Kim, Kevin Behr, and George Spafford. It provides great insights into how the DevOps culture and mindset work within an organization.