What’s the difference between SRE vs. DevOps? You could argue that it’s largely a matter of semantics, and that in practice SREs and DevOps engineers fill the same basic roles.
Nevertheless, there are some distinctions—even if subtle ones—between DevOps and SREs. They may seem unimportant given that these two types of roles largely share the same values and practices, but the reality is that, at the end of the day, SREs and DevOps engineers address different needs. Understanding those differences is key to ensuring that your IT teams operate as efficiently as possible.
What is SRE?
Site Reliability Engineering (SRE), or site reliability engineer, refers to the use of software engineering principles to help maintain and manage IT systems.
At least, that’s the gist of the SRE definition from Google, the company that has popularized the concept over the past few years. As Google puts it, the point of SRE is to “treat [IT] operations as if it’s a software problem.” Here’s how Ben Treynor, VP of Engineering at Google, describes the role:
“SRE is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise, and banking on the fact that these engineers are inherently both predisposed to, and have the ability to, substitute automation for human labor.”
This idea is innovative because, traditionally, there was a large divide at most companies between IT operations staff, whose main role was maintaining software, and a software engineer, whose main role was writing software. Not only did these two groups do different types of work, they also approached problems in different types of ways. Software engineers tended to focus on using code to solve all problems, whereas IT operations was more accustomed to using a wide array of various tools—monitoring software, configuration management tools, access-control frameworks, and so on—to manage the day-to-day operations of software systems.
The SRE trend helps to explain why concepts like infrastructure as code (IaC) and declarative configuration management have become popular approaches to IT system deployment and management in recent years. These practices are ways of using code and the principles of software engineering to manage IT processes that traditionally would have been executed using different tools and methodologies. They also happen to be approaches that lend themselves well to automation and scalability, which are values that SRE teams prioritize.
What Is DevOps?
DevOps, as the term implies, is about bridging the gap between development and IT operations. DevOps is a combination of development, quality assurance (QA), and operations, together with related best practices and methods. The goals of DevOps are to:
Shorten the software development life cycle (SDLC).
Improve responsiveness to market needs.
Speed the delivery of products to market.
DevOps implies a continuous communication cycle. The continuous part means that building, testing, and deploying releases must be automated to some degree. The goals of automation are to:
Shorten the market delivery time of a product.
Improve the quality of the release.
Shorten the time between the releases.
Reduce mean time to repair (MTTR).
Traditionally, development teams, QA staff, and operations departments were siloed, and weren’t aligned to support automation or achieve such goals. The effort would require working together and helping each other with their assigned tasks. It would require learning new skills. For example, QA would have to learn scripting and operations would have to learn automation.
The core idea behind DevOps is essentially the same idea that drives SRE: It’s about making overall IT operations more reliable and efficient by allowing software engineers (or developers, who are basically the same thing in most contexts) and IT operations staff to collaborate more closely.
Like SRE, DevOps prizes automation and scalability. Methodologies like IaC commonly feature in DevOps conversations, although DevOps also has some techniques, like continuous integration/continuous delivery (CI/CD), that are not closely associated with SRE.
SRE vs. DevOps
At a high level, then, when comparing SRE vs. DevOps, these approaches share similar goals and broadly similar methodologies. But there are important differences between SRE and DevOps:
Role played by developers: SRE uses a developer’s mindset and tooling to solve the problems of IT operations. For example, by establishing error budgets and golden signals, teams can seek to improve service levels. Thus, in SRE, most things are done from a software engineer’s perspective. In contrast, DevOps is more about combining the skillsets of developers and ITOps engineers, rather than using the former to supplant the latter.
DevOps culture vs. implementation: Generally speaking, DevOps tends to focus more on cultural goals and priorities than on specific implementational processes. There are no specific tools you need to use or approaches you have to follow in order to “do DevOps.” There is no specific script to follow for doing SRE, either, but SRE overall offers more rigid prescriptions about how to solve problems, and which types of tools to use, than does DevOps.
Organizational structure: In most cases, DevOps doesn’t replace existing developer and IT operations departments or roles. Companies may hire a few DevOps engineers to help guide DevOps, but they don’t replace all existing IT roles with DevOps engineers. In contrast, the SRE role tends to be seen as a way to replace at least IT operations. (This is a generalized statement and there are certainly exceptions, but overall, SRE involves greater change to organizational structure.)
Extension to other IT roles: DevOps has spawned a slew of offshoots that extend the DevOps concept beyond just development teams and IT operations. Now, it’s common to hear talk about DevSecOps, for example, which applies DevOps to security, or QAOps, which brings QA engineers into the DevOps fold. The SRE concept, meanwhile, hasn’t seen this type of expansive use.
Is There a Real Difference between DevOps and SRE?
The above notwithstanding, it can be hard to fully explain the difference between SRE and DevOps. Some observers have argued that the differences are not substantial or consistent enough to be meaningful. Others might contend that the definitions of SRE and DevOps, as well as the approaches companies take to embrace the concepts, vary so much that it’s not really possible to offer a universal definition of either term in the first place, let alone clearly spell out how they are different from each other.
There is merit to those points of view. Still, I do think that, by and large, there are some subtle but significant differences between the way SRE and DevOps are used. The concepts are not interchangeable, and companies seeking to bring the greatest value to their IT strategy can benefit from both strategies.
SRE helps in a practical and implementational way to streamline IT operations using methodologies that were previously applied only to software development. Meanwhile, DevOps promotes thinking at a higher level about ways to make the overall IT organization more efficient and automated without restricting companies to a narrow set of tools or methodologies.
Ultimately, then, there is value in treating SRE and DevOps as distinct concepts and embracing both for the unique value they provide.