The battle of DevOps and SRE

Are you a DevOps Engineer or a Site Reliability Engineer? Let us try to tear the question apart :)

DevOps is a set of practices that automates the processes between software development and IT teams. This is to enable them to build, test, and release software faster and more reliably. It builds a culture of collaboration between teams that historically functioned in relative silo’s. The promised benefits include increased trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.

According to Wikipedia, “Site Reliability Engineering is a discipline that fuses aspects of software engineering and applies that to IT operations problems. The main goals are to create ultra-scalable and highly reliable software systems.”

Sounds pretty similar right? That causes most of the confusion. Let us try once more.

DevOps defines the overarching principles of WHAT the developers should expect from Operations and vice versa allowing the groups to see how their work influences the other. DevOps does not define the HOW of this process and this is where SRE comes in.

Some people would define the relationship between DevOps and SRE as that between Agile and Scrum.

Five pillars of DevOps are as follows

1. Reduce organisational silos
2. Accept failure as normal
3. Implement gradual changes
4. Leverage tooling and automation
5. Measure everything

For people who understand coding, this is laying down of the interface or the specification.

SRE attempts at providing the HOW or an implementation to the above specification.

1. Reduce organisational silos

• Same tooling and techniques used as the development team to reduce the friction between the development and SRE team.
• Allows shared ownership

1. Accept failure as normal

• Define failures with numbers
• SRE quantifies failure and availability in a prescriptive manner using Service Level Indicators (SLIs) and Service Level Objectives(SLOs)
• SRE mandates blameless postmortems

1. Implement gradual changes

• SRE encourages developers and product owners to move quickly by reducing the cost of failure

1. Leverage tooling and automation

• SREs have a charter to automate menial tasks which result in time lost because of repetitive tasks

1. Measure everything

• SRE defines prescriptive ways to measure values
• Believes that operations is a software problem, and defines prescriptive ways for measuring availability, up-time, outages, toil, etc.

Hence to sum it up,

• DevOps is not a role, it is a culture which defines WHAT needs to be achieved. SRE is a role. You can have an SRE professional
• SREs practice DevOps since they are focused on aspects like availability, observability, and scale
• DevOps focuses on WHAT needs to be done before the system is in production. SRE deals with monitoring applications or services after deployment to practice where automation is crucial to improving a system’s health and availability.

Hackernoon, has an interesting quiz to validate if SRE is for you

SRE Compatibility Quiz
Do you like thinking about large scale problems that have a lot of moving parts?
Do you like thinking about how to make large systems more reliable?
Are you okay with working on software that will likely never be overtly seen by an external user?
Do you enjoy looking at a terminal for large amounts of time?
Do you enjoy the process of diagnosing and fixing a problem? If yes, what if the diagnosis involves system level problems that you cannot always see?
Do you enjoy thinking about system information (e.g. disk space, cpu, os, kernel, etc.) and system level functionality (e.g. ssh, proc, cron, swaps, etc.)?
Are you comfortable with the idea of being “on-call” in which you are likely to be in high-stakes scenario where something needs to be fixed?
Are you able to stay calm under pressure?
Do you approach problems in a logical, process-oriented way?
Are you comfortable attempting a problem that has never been solved before?
Are you someone who thinks about how you can make things better?

If you answered yes to at least 8 of these questions, SRE could be a good position for you.

An SRE is a perfect combination between software development and systems knowledge. As per Ben Treynor who coined the term

Typically, we hire about a 50–50 mix of people who have more of a software background and people who have more of a systems background. It seems to be a really good mix.

Hence, it is not about whether your role is that of DevOps or SRE. You would be playing the SRE role following the specifications laid down by DevOps pillars.