SRE

SRE vs DevOps – Competitors or Friends

More and more teams at Swisscom are using Site Reliability Engineering (SRE) to fulfil the expectations of our customers and users. But wait! Didn't we count on DevOps to bridge the gap between Dev and Ops, and to achieve a high quality of our software in production? Is SRE just the new buzzword on the market and used to attract talents? In this blog, the Swisscom's DevOps teams want to create a common understanding regarding the positioning of SRE in relation to DevOps and show how we see SRE at our Software department in Swisscom. Let's start with some theory of DevOps and SRE:

Michael Ludwig, Tribe Chief
12 August 2020

DevOps

The DevOps movement began because developers would write code with little understanding of how it would run in production. They would throw this code over the proverbial wall to the operations team, which would be responsible for keeping the applications up and running.

DevOps emerged as a culture and a set of practices that aim to reduce the gaps between software development and software operation.

However, the DevOps movement does not explicitly define how to succeed in these areas.

In this way, DevOps is like an abstract class or interface in programming. It defines the overall behaviour of the system, but the implementation details are left up to the author.

Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE) is a term (and associated job role) coined by Ben Treynor Sloss, a VP of engineering at Google.

SRE is a job role, a set of practices Google found to work, and some beliefs that animate those practices. If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes.

«SRE is what happens, when you ask a software engineer to design an operations function.»

Ben Treynor, vice president of engineering at Google

How SRE concretely addresses DevOps

SRE embodies the philosophy of DevOps but has a much more prescriptive way of measuring and achieving reliability through engineering and operations work. In other words, SRE prescribes how to succeed in the various DevOps areas. For example, the table below illustrates the five DevOps pillars and the corresponding SRE practices:

So, in a way, class SRE implements interface DevOps.

DevOps <-> SRE Differences

Yet there are significant differences as well. DevOps is in some sense a wider philosophy and culture.

DevOps is relatively silent on how to run operations functions at a detailed level. For example, it is not prescriptive around the precise management of services. It chooses instead to concentrate on breaking down barriers in the wider organization, which has much value, too.

SRE, on the other hand, has relatively narrowly defined responsibilities and its remit is generally service-oriented (and end-user-oriented) rather than whole-business-oriented. As a result, it brings an opinionated intellectual framework (including concepts like error budgets to the problem of how to run systems effectively. Although SRE is, as a profession, highly aware of incentives and their effects, it is in turn relatively silent on topics like siloization and information barriers. It would support CI (Continuous Integration) and CD (Continuous Delivery) not necessarily because of the business case, but because of the improved operational practices involved.

Or, to put it another way, SRE believes in the same things as DevOps but for slightly different reasons.