This text has been translated from Google Translate.
In the IT world before DevOps, there are Devs on one side and Ops on the other. There is a wall between the two. Some throw .jars like concrete blocks over them, others throw bugs at them to fix. And that's when they don't throw bricks directly at each other.
**DevOps is tearing down this wall. **
So to destroy it, we start by reworking the organizations. Put Devs and Ops in the same room, and make them love each other, or at least work smart together.
One of the first topics is the allocation of responsibility for prediction. Usually it is the Ops who are on call and who get up at night to fix errors. Now Devs can also be "On call". They are responsible for the behavior of their code in production. And that makes them think about it from the start. In general, it encourages them to make code more efficient, and more durable.
And then in a second time the tools arrived. And now DevOps is especially when Devs have tools to do without Ops on a daily basis. We are talking about deployment and continuous integration, but not only.
Because now that Ops are free from all-day release tickets, they can do other things. And they will above all make continuous improvement. We're going to adopt a whole bunch of good practices: friction logs, observability, infra as code...
SRE (Site Reliability Engineer) is a word that was popularized by Google employees. To put it simply and without being reductive, we can say that DevOps is a movement, while SRE is a specific method of DevOps.
If you want I asked the question in detail to Quentin Adam, the answer is on Youtube:
When we look at the salary of Devops on WeLoveDevs we can see that there are several groups or platoons.
First of all, it's because there is a difference between a Dev who has DevOps skills and a person who is responsible for DevOps in the company.
Besides, is DevOps really a profession? In the strict sense of the term, a person whose job description is DevOps should only be in charge of the adoption of DevOps in the company. But most often, DevOps have in their scope an obligation and means for the availability of DevOps tools.
As DevOps is a transformation of the company, we find this profession in consulting companies and it is very logical!