SRE vs DevOps: What’s the difference?

We asked 9 engineers, developers, and system administrators to tell us what they think the definitions of SRE and DevOps are and how responsibilities are split between the two. 

It’s an enlightening look at what it actually means to work in production operation management and the expectations around some of tech’s most coveted positions.

In this article you are going to find out: 

Let’s see how these 9 experts answered our SRE vs Devops questions. 

One SRE in the hotel business told us that to him, SRE is “an implementation of DevOps” and “what happens when you ask a software engineer to design an operations function. Essentially, its aim is to find and deploy automated approaches to work previously carried out by an ops team.”

According to him, SREs are software engineers with a skillset focused on deployment, configuration management, monitoring, and metrics. “The SRE team is not solely responsible for these areas - they also provide a bridge to the developer team to ensure that the whole team can deliver a product/system that is updated, managed, and monitored effectively.”

This collaborative approach between the SRE and the developer teams was also shared by another engineer who said that SREs “are ‘leased’ to feature teams to bootstrap them with operational best practices for running live services and to help upskill the teams and provide additional on-call coverage in the process.”

To some, it’s all about passion and vision. An SRE in the e-hailing business thinks that SREs are “strong platform/cloud engineers with a good background in reliability engineering and a passion for ensuring that the Product (not production) is ALWAYS available, stable, and performant whilst understanding and enabling fast reliable releases to production.” 

Mohamed Magdy Shokry, a Senior Software Engineer at Nokia shares a similar view, calling an SRE an “integration expert with a wide background in most modern and old technologies that has excellent architecture vision for company solutions.”

Some answers, however, leaned more to the practical, less human side of the industry. According to one SRE, the role implies knowing about “tools and processes that ensure that a system/platform/solution and its architecture is running as expected and providing the right functionality.”

Now that we’ve covered what an SRE is, we need to also think about their responsibilities. An SRE in the hotel industry says Site Reliability Engineers are responsible for the “availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of an environment”. This means they should check each metric and ensure that they are at the appropriate level for the product/business. 

According to him, SREs also “work to find automated responses when these areas are not correct - and in the meantime manage an operations approach to resolving incidents”. 

His thoughts are also shared by another engineer who believes it’s SREs responsibility to “build more resilient services, and improve incidence detection and response time”.

At the same time, another SRE explains that his job is to “work extremely closely with Software Development Engineers to build the foundations and ‘teach them to fish’ - know when to be hands-on and hands-off.” And last but not least, that SREs should “innovate, innovate, innovate”.

A developer in the e-hailing business defines DevOps as“a culture that aims to use technology to bring development and operations together in a harmonious, trusting, open way”. It’s“a way of working that helps ensure that all non-technical requirements and functional requirements are met in an Agile manner”, another developer agreed.

According to a DevOp in the hotel industry, there are 5 pillars of DevOps: 

To summarize, DevOps is “a set of principles and practices that aim to improve time-to-market while maintaining high quality”. 

If we were to compare this definition to that of SRE, we’d notice that DevOps is about “what” needs to be done, while SRE focuses on “how” this can be done, meaning finding the right tools and methods. SREs also encourage shared responsibility and making sure everyone has the same goal and vision.

The DevOps movement began because developers would write code without trying to understand how that code would work into production and, as a consequence, the operations team would struggle to keep applications up and running. A set of best practices was needed to reduce the gap between software development and software operation. 

However, DevOps didn’t explicitly define how to succeed, and that’s why the SRE concept was introduced by Google (who first developed it to meet its own internal needs). SRE incorporates the philosophies of DevOps but has a much more descriptive way of measuring and achieving reliability.

According to one developer, DevOps should “bridge the gap between development and operational concerns, help prepare dev teams to take on ops responsibilities (i.e. ‘you build it, you run it’) or engage with stakeholders to create an environment where ‘uptime’ is a shared responsibility and not just the responsibility of one team”.

At the same time, DevOps shouldn’t be a role. Instead, it “becomes a decision about whether you place all the responsibility within the development team, or you enhance that team with specialists focussing on these areas who also look to provide automated tooling and other support to the development team” another developer confirmed. 

Similarly, a DevOp in the ride-sharing business thinks DevOps is not a team nor a job title. “SREs work to enable a DevOps culture that MUST be embraced from the Exec down and touch all areas of the business”.

If we were to name a few DevOps responsibilities, they would be:

As you can see, SRE is clearly defined, along with a setlist of expectations. When it comes to DevOps, on the other hand, definitions and perspectives differ from organization to organization. Also, the general perception seems to be that DevOps is more of a methodology than a fixed role.

However, no matter whether you’re an SRE or DevOps, one thing is clear – a cloud management and automation tool such as Bunnyshell can help you put your infrastructure on autopilot. 

And with an innovative solution like the Site Reliability Robot, you can instantly detect server conflicts and their root cause through in-depth insights that show a specific course of action.

By lowering the complexity of deploying applications and automating maintenance and monitoring, this type of solution saves time that can be better spent on improving your product/service. 

Don’t believe us? Get in touch and let us show you how we can help you.