There can be a traditional separation between DevOps and SRE, and the lines can be blurred between the two.
In addition, and depending on the company, DevOps and SRE can mean slightly different things. So what truly is SRE, what are the core principals, and how does it differ from DevOps?
Forty to ninety percent of business costs come after birth or after the creation of something, but most of the effort is put into before something is created. However, what happens after?
That is where SRE comes in. We are Software Engineers who's focus is on that forty to ninety percent, and are cross functionally Software Engineers, but geared towards business objectives, goals, and saving costs.
In the traditional sense, and what Google had in mind when they created the role of SRE, DevOps was to be thought of as a philosophy, and SRE as a prescriptive way of accomplishing that philosophy; implementing the developer mindset, workflows, tools, etc...and applying them to the operations world.
Under this definition, DevOps is like "What to do", and SRE is like "How to do".
However, as mentioned this "traditional" definition of SRE can be blurred with DevOps, and can vary depending on where you go and who you talk to. Since its inception, SRE has evolved to encompass
many different meanings and responsibilities. But, the core principals and reason for its creation, many of which overlap with DevOps, still hold true -
which is to solve the pain point of infrastructure that you continually roll changes out to.
At its core, the objective is to create reliable, redundant, fault tolerant, immutable infrastructure using infrastructure as code and a set of guiding principals, standards, and workflows.
This of course with the understanding of working closely with both developers, and operations.