No, SRE Is Not the New DevOps – Unless It Is – InApps Technology 2022

If you start typing “DevOps vs.” in your search engine, you’ll probably see that “DevOps vs. SRE” is one of the top queries that people search for. But so are terms like “is SRE DevOps?”

If Google autocomplete is to be believed, then, there is a fair amount of uncertainty out there about what, exactly, the SRE role has to do with DevOps. Some see SRE and DevOps as distinct concepts, while others apparently think that they mean more or less the same thing.

Understanding what SRE has to do with DevOps, and the extent to which the two concepts differ, is important for thinking about the way we manage software lifecycles today. This article offers perspective on both of these issues.

What Is SRE?

SRE, which stands for Site Reliability Engineering (or, sometimes, Site Reliability Engineer), is an approach to IT operations that prioritizes the tools and methodologies common to software development.

In other words, instead of approaching IT tasks (like application deployment and monitoring) using conventional IT strategies (like manual deployment), you use code-based automation tools (like Infrastructure-as-Code solutions) that would feel more “native” to a software engineer.

What Is DevOps?

DevOps, meanwhile, can be defined in different ways, but most definitions boil down to the idea that DevOps is a philosophy that promotes collaboration between developers and IT teams.

DevOps also goes hand-in-hand with certain methodologies (like Continuous Deployment/Continuous Delivery) that are not as closely associated with SRE.

Comparing SRE and DevOps

At a high level, then, SRE and DevOps both emphasize (at least in part) the core idea that developers should play a more prominent role in IT operations work. However, when you look more closely at the two concepts, certain differences emerge.

The History of SRE and DevOps

One of those differences is the historical evolution of the two concepts.

Conceptually speaking, SRE is an older idea. It originated in 2003 inside Google, which thought the idea was so powerful that it created a mini-site dedicated to SRE, complete with several full-length SRE books.

DevOps is a bit newer. It dates to around 2008 (the exact timeline is a bit murky) and took several years after that to begin hitting the mainstream. Also, unlike SRE, the DevOps concept didn’t have the weight of Google behind it.

The slower pace at which the DevOps concept took root is reflected in these Google Trends graphs:

The distinct historical origins and narratives of SRE and DevOps reflect the fact that they are different concepts. To suggest that SRE is simply an extension of — or a “next stage” in — DevOps is very wrong from a historical perspective.

Continuousness and DevOps

Another difference between SRE and DevOps is the role that “continuousness” plays in each concept.

The idea that processes — whether application development, testing, deployment, or monitoring — should be continuous is part and parcel of DevOps. Granted, most DevOps processes are not literally continuous, but a central goal of DevOps is to make processes as consistent and steady as possible.

The SRE concept certainly doesn’t disavow continuous processes; in fact, it encourages them implicitly in most ways. But continuousness is not an explicit goal.

It might sound as if DevOps has simply turned “continuous” into a buzzword and SRE has not, but there is more than semantics at stake here. The difference in terminology matters because there is a lot of specific tooling that goes along with continuous processes in DevOps. In order to “do” DevOps, you’ll be relying on continuous integration servers, test automation, release automation suites, and so on. In contrast, the workflows associated with SRE don’t necessarily require the kind of continuous automation toolset that powers DevOps — although they are by all means compatible with it.

Dev vs. Ops

Finally, perhaps the greatest difference between SRE and DevOps is that, in SRE, the developer perspective is the predominant one. In general, SRE is all about taking tools and concepts that make sense to developers and applying them to IT operations.

In contrast, DevOps generally tries to make developer-IT Ops relations more of a two-way street. It is less about imposing developers’ tooling and ways of thinking on IT engineers, and more about making sure that both groups understand each other’s problems and methodologies so that they can support each other more effectively.

In fact, some developers would have you believe that DevOps is “killing the developer” by placing them in IT Ops roles, using IT Ops tools and methodologies. I have yet to see similar complaints about SRE harming developers, probably because SRE privileges the developer mindset more than DevOps does.

Why None of This Matters (but Kind of Does)

To conclude, it would be very hard to make the case that SRE represents the next stage of DevOps, or that the two concepts mean exactly the same thing. They don’t, and they haven’t since they originated in different historical contexts.

On the other hand, there are few totally remarkable differences between SRE and DevOps. There may be some nuances within the thinking behind each idea, as well as the terminology and (to a lesser extent) tooling associated with it. But it’s hard to argue that there are fundamental conceptual distinctions, beyond the somewhat different ways that they treat developers.

This is to say, it’s probably not worth worrying too much about the differences between SRE and DevOps. Both are malleable concepts whose meaning lies largely in the eye of the beholder.

Nonetheless, what is worth worrying about is making sure to embrace the modernization ideas behind both DevOps and SRE. Whether you choose to believe that one is better than the other, or that both are equally valuable, understanding and acting on the automation and best practices that they encourage is what’s really important.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Torq.

Feature image via Dreamstime (supplied by sponsor).