Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

SRE vs. DevOps: Any Common Ground?

DZone's Guide to

SRE vs. DevOps: Any Common Ground?

Learn about the history of site reliability engineering and where it shows similarities and common ground with the realm of DevOps engineering.

· DevOps Zone ·
Free Resource

Discover how you can reduce your Kubernetes installation from 22 steps to 1.

Software engineers spend significant amounts of time seeking to streamline software development and production. This endeavor results in constant changes that can cause software and performance defects which continue to consume even more time and productivity.

This imbalance has created the necessity for constant care and maintenance of the development pipeline. And teams turn to many methodologies to seek the answer for monitoring and maintaining the endless software application tasks that occur.

Over the years the two methodologies IT teams are turning to the most to improve performance and quality are DevOps and Site Reliability Engineering. So, how do the two compare on paper for the best outcome?

What Is Site Reliability Engineering?

Site Reliability Engineering (SRE) is a process engagement that commissions software developers to own the continuous daily operation of their applications in development. It is what happens when a software engineer is requested to design an operations team.

History of SRE

The SRE concept began in 2003 and was a Google initiative. Google was experiencing growing pains in their attempts to scale to the company that we know them to be today. One of the most contentious challenges the business faced was to support large-scale systems and also keep the development of new features going consistently.

To attain their goal, Google developed a new type of software engineering team with dual purposes. The team’s target was to support the introduction of new features while maintaining Google systems. SRE was the initiative that allowed the company to fulfill this goal and its advanced significantly outside of Google too. SRE teams are constructed with two main categories in mind:

  1. Hiring software engineers “who know enough about programming languages, data structures and algorithms, and performance to be able to write software that is effective.”
  2. Building a team which consists of a “50-50 mix of people who have more of a software background and people who have more of a systems engineering background.” From an interview on SRE with Ben Treynor, VP of Engineering.

SRE endeavors to bridge the gap between the operations team and development team. Where the development team may focus on fast production, the operations team may focus on measures to prevent production blowing-up. SRE comes in to harmonize the two different views.

Pros and Cons of SRE

Pros of SRE

  1. SRE bases product creation on the environmental conditions imposed by the customer. This aspect helps to optimize production costs as well as customer satisfaction.
  2. Utilizing availability and reliability concepts helps to minimize failures and reduce time wastage. Unanticipated shortcomings usually cost customers their time, and the organization spends resources to resolve these failures.
  3. SRE seeks to maximize throughput and minimize operating expenses. It works towards eliminating downtime through deploying predictive and preventive maintenance programs.
  4. Use of SRE techniques helps minimize the time and resources impact of trying to eliminate early feature failures.
  5. Reduced failures translate into fewer spare parts, minimized distribution system costs, service labor costs and storage cost for spare parts.

Cons of SRE

  1. It is not easy to find suitable site reliability engineers as the hiring bar is set so high regarding coding and system engineering skills.
  2. Since SRE is a new and unique discipline, there is limited industrial information on how to build and manage an SRE team.
  3. It requires strong management support to direct the team away from their usual practices and adopt full, unorthodox SRE approaches.

What Is DevOps?

It is a cultural framework in which the value of collaboration between the development and operations staff is embraced throughout a product or service development lifecycle. It is a methodology that changes people’s perspectives on work and values the diversity of skills within a team.

DevOps encourages the implementation of intentional processes that speed up the rate at which a business gain returns. It measures the effect of technical adjustments as well as social and cultural changes in the work environment.

Pros and Cons of DevOps

Pros of DevOps

  1. DevOps primary goal is to drive topline benefits around enhanced experiences and revenue opportunities. The methodology seeks to improve the cultural environment and the flow of work in the technology value stream with the output of upgrading product/feature quality and customer satisfaction/end-user experience.
  2. DevOps breaks down the silos that hierarchical organizational models create by eroding the barriers between development, operations, and testing teams.
  3. The practices align business goals with information technology. Every effort initiated is formulated to shorten feedback loops, achieve continuous improvement, and deliver according to customers’ needs.
  4. DevOps enables and speeds up business performance. IT teams are transformed and encouraged to deliver innovation which helps achieve business outcomes.
  5. DevOps has brought about digital transformation. It embraces technological innovations that enhance customer experience and employee’s productivity.

Cons of DevOps

  1. DevOps is not a smooth implementation for new teams to adopt. Beginning a DevOps transformation introduces new challenges to an organization and may be unfit for a particular work environment.
  2. The benefits of DevOps are realized over a long period of time and change. Hence, the process requires patience.
  3. DevOps associates with profound cultural changes. It can be difficult for people to drastically change the new normal and resistance is often encountered.

What Is the Difference Between a Site Reliability Engineer and a DevOps Engineer?

  • A site reliability engineer is accountable for monitoring applications or services after deployment to establish where automation is necessary to enhance a system’s health and availability. She or he assumes the role after the design work of a software developer.
  • On the other hand, a DevOps engineer is responsible for executing the development automation vision from the very beginning. The DevOps engineer’s role is visible from project start to fruition.

The DevOps and SRE share common ground in the development process. The DevOps engineer takes a top position to craft culture and a system that automates tasks delivery in the development process. SRE serves as a compliment to DevOps as it embodies the philosophies of DevOps. It accomplishes DevOps by measuring and achieving reliability in a more prescribed manner.

DevOps reduces the gap between software development and software operations. Through engineering, SRE prescribes how to succeed in the various DevOps practices. Both of these disciplines fulfill a similar set of goals and include eliminating team barriers to deliver a better product. The two share a common ground in their complementary organizational goals and can work in accordance with each other.

For more on DevOps, don’t forget to check out the start of our DevOps Handbook Synopsis!

Download the Kubernetes cheatsheet to learn more about easy it is to run Kubernetes on any infrastructure with Mesosphere DC/OS

Topics:
sre tools ,sre ,devops ,devops adoption ,devops automation testing

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}