DevOps vs SRE

DevOps and SRE, are they the two sides of the same coin?

Both approach aim to bridge the gap between development and operation teams, then how are they different?

In most companies both titles co-exist in the same space, and both are an essential part of the development process. Let’s deep dive in both of them.

DevOps

In 2006, Amazon’s CTO Werner Vogels described the company’s approach: “You build it, you run it.”

After that, Amazon’s developers had started to deploy and run their applications and services end to end. And so, DevOps was born.

Before DevOps was implemented, development and operation teams worked as two independent squads. Development writes code and throws it over the wall to operations whose job it is to deploy that code, with all its dependencies and configurations, and keep it running. Operators lacked sufficient understanding of codebases, and developers lacked sufficient awareness of operational procedures. The differences and lack of communication between these teams often impacted the quality of application. DevOps came into the picture to solve the issue of conflict between developers and operators in organizations.

Gartner describes DevOps as “ DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and it seeks to improve collaboration between operations and development teams.”

The main role of the DevOps team is to solve the development problem, build solutions to supply to business requirements. DevOps focus on product development with Continuous Integration/ Continuous Delivery.

Implementing the DevOps practices can reduce the friction between Development and Operations teams, improve collaboration and eliminate silos between developer and IT operations teams across a business.

The DevOps process has the following goals in mind:

• Accelerate the delivery of products to market.
• Shorten the software development lifecycle.
• Break down silos.
• Leverage automation.

Site Reliability Engineering

SRE stands for Site Reliability Engineering or Site Reliability Engineer. SRE was invented and popularized by Google. Like DevOps, it was a cultural shift. DevOps teams don’t necessarily have someone specifically dedicated to developing systems that increase site reliability and performance. That’s where a site reliability engineer (SRE) comes into the picture.

SREs are responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning of their service(s). The principle behind SRE is that using software code to automate oversight of large software systems is a more scalable and sustainable strategy than manual intervention. After originating at Google in 2003, the concept spread into the broader software development industry. According to SRE best practices from Google, site reliability engineers can only spend a maximum of 50% of their time on operations — and they should be monitored to ensure they don’t go over. The rest of their time should be spent on development tasks like creating new features, scaling the system, and implementing automation.

The responsibilities of a site reliability engineer:

• Automation anything repetitive.
• Systems design and support.
• Process improvement.
• Change and release management, including CI/CD.
• Designing for and implementing observability.

DevOps compared to SRE

Although there is some overlap in the job roles of SREs and DevOps, there is wide segregation of functions.