One of the terms that people often find confusing is SRE and DevOps. People often ask, should I hire a DevOps Engineer or a Site Reliability Engineer? What is the difference between SRE and DevOps and which one do I need? In this post, I attempt to shed some light.

Site Reliability Engineering (SRE) is the application of software engineering principles to operations tasks. The main difference between ops and site reliability engineering is that SRE automates tasks that have historically been done manually by ops teams.

While DevOps requires developers to share the burden of running and operating their code, as well as on-call responsibility, it doesn't assist the DevOps team enough to improve the resilience or reliability of their system. This is where site reliability comes in.

But how is SRE similar to DevOps? Or are SRE and DevOps the same thing?

Similarities Between DevOps and SRE

DevOps and SRE are complementary practices aimed at improving the quality of the software development process and application resilience.

DevOps is a set of guidelines that define what needs to be done to unify software development and operations. On the other hand, SRE is a subset of DevOps that implements those guidelines or principles in a narrower scope. If DevOps was an abstract class, SRE is the concrete class.

For example, while DevOps promotes a culture of automation, SRE practices implements a culture of automation by identifying sources of manual work in Operations and codifies (automates) them.

DevOps advocates a culture of measurement by measuring performance and implementing quick feedback loops. SRE embraces measurement by measuring toil and collecting Service Level Indicators (SLIs), Service Level Objectives (SLOs), and fulfilling Service Level Agreements (SLAs) for better system reliability.

SRE identifies manual work by measuring toil. According to the Google SRE book, toil is operations work that is automatable, tactical, devoid of enduring value, and manual or requires inputs from a human operator.

‍

DevOps advocates embracing failure and leveraging them as a valuable learning tool. SRE on the other hand understands that 100% reliability is impossible to achieve, therefore SRE treats errors as probable. Rather than aiming at 100% reliability, SRE defines an error budget. An error budget is like a budget for time – it’s how much time you’re willing to let your systems be down.

To sum it up, DevOps and SRE are similar in many ways, rather than being competing practices, they both compliment each other and can co-exist to help you deliver reliable and quality software.

How DevOps is Different From SRE

Although DevOps and SRE are similar in many ways, they’re different.

DevOps promotes efficient development of software from ideation to delivery –a cultural practice on how everyone- your developers, ops, stakeholders should be engaged in working the right way with a focus on delivering values to customers incrementally and continuously.

On the other hand, SRE embodies these practices plus a more streamlined way of measuring availability and reliability. I like to think of SRE as a discipline that implements DevOps.

SRE applies software engineering to operations and focuses mainly on managing operations after the software is deployed. It majorly concerns itself about the stability and availability of the environment where the software runs.

DevOps is much bigger than a role. It’s a way of working, a culture that must be embraced by the entire organization. It reaches deep into your organization, involving everyone who has a stake in the collaborative process.

An engineering team that practices DevOps would ideally have different sets of people with different skill-sets collaboratively working to achieve a common goal. An SRE team may consist of people with operations knowledge and understand how to leverage software engineering approaches to tackle operations problems.

Structuring your SRE Team

For a small company, it can be hard to justify the need for SRE at the beginning. One way to start is by allocating some engineering resources to SRE practices. Depending on your size, you might find some engineers who have a knack for operations and automation.

Such folks could be your SRE champions helping to advocate SRE across the org. Take note as the team’s scope and services covered could grow without bounds turning to what’s known as Everything SRE or the Kitchen Sink team. Hence this is the preferred approach to establish the team, as neither has the scope of SRE-related tasks grown beyond a certain level nor has the team grown big enough to justify creating a full-fledged SRE team.

As your product team grows, you could have tens of product teams with each responsible for different parts of your application. Oftentimes, some tasks are common to each team to ensure the service is reliable, has proper monitoring, CI/CD pipelines, permissions, and more. One way to tackle reliability issues with such a setup is to have a full-fledged team dedicatedly focusing on behind-the-scenes tasks making the product team’s work available, faster, and reliable. Such teams are often referred to as infrastructure or platform teams in some organizations.

Another approach is to embed an SRE in the product team. In this approach, the site reliability engineer works hand-in-hand with the development team usually for a fixed period or through the lifetime of a project. This approach is often crucial if you’re changing to a new architecture or building a new product with technologies new to the development team and you want to start an SRE function or scale the implementation. If not managed well, embedding SRE in product teams could lead to a lack of standardization between teams or divergent practices.

Structuring teams around the approaches described in the post have their respective strengths and weaknesses. But one important thing to note is that an SRE team is not a product team with people coming from varying backgrounds. It’s a mix of engineers and IT operation specialists. Google, where SRE originated from, has a mix of 50% engineers with software backgrounds and 50% of engineers with operations backgrounds.

We’ve discussed 3 possible ways to form and engage SRE in your org, it’s important to assess which one is right for your unique situation. You should keep in mind that DevOps and SRE aim to bridge the silos between teams. And whichever approach you take, you should ensure practices do not re-erect the walls.

Conclusion

In this post, we’ve explored the differences and similarities between Site Reliability Engineering and DevOps. DevOps and SRE should not be viewed as two mutually exclusive entities, rather a complementary practice that can co-exist to make you deliver high quality and reliable software.