You are looking for DevOps jobs.

In job boards, you find many postings for DevOps Engineers. And some more postings for Site Reliability Engineers.

Are thy the same or different? Let's check it out.

A brief history of Site Reliability Engineering

Benjamin Treynor Sloss at Google coined the term Site Reliability Engineering (SRE), and established the first SRE team at Google in 2003.

As you already know, the DevOps movement started around 2007.

Site Reliability Engineering was invented nearly 5 years before but got public attention only after the DevOps movement.

What was the reason?

In 2003, engineers at Google were trying to solve a unique problem.

Google's business was growing exponentially. And their computing infrastructure was growing on par. Like all other companies at the time, Google employed Sysadmins for IT operations.

But it was not very efficient.

Google's products were some of the pioneering SAAS (Software as a Service) offerings in the market. The SAAS business model demands high feature velocity - quickly ship new features to the market and evaluate how users respond. And Google needed to do this at scale.

This was competing with the Sysadmin approach to operations. To add more to the problem, Google's computing infra was big - so big that no other company on the planet was operating computing infra at the scale Google was doing. So, Google's problems were unique.

Without industry sources to draw any insights from, the engineers at Google came up with their own solution - Site Reliability Engineering.

What is Site Reliability Engineering (or how Google defined Site Reliability Engineering)

The creators of Site Reliability Engineering realized that the Sysadmin way of operations was inefficient because it relied too much on manual work. It was not the best way to do software operations at scale. It could never meet Google's demand on feature velocity.

The engineers at Google perceived that the answer to these problems was to automate everything in software operations.

So they created an operations team (called the SRE team) with software engineers who also possessed Sysadmin skills to a certain level. Theses software engineers quickly got bored with the manual operations work that was assigned to them.

They had the capacity to automate this manual work by writing software. Driven by well defined KPIs, the SRE team at Google created software that transformed Google's software operations to a highly automated model.

Site Reliability Engineering vs DevOps

The DevOps movement started around 2007 to address a burning problem in software teams - the siloed working approach of developers and IT operations. The result was a new methodology for developing software.

The DevOps methodology emphasized on creating harmony among the developers and operations teams via involvement and collaboration. Software teams around the globe embraced DevOps and it proved to be highly effective.

The DevOps methodology defines a set of practices for developing software. But it does not mandate how you implement those practices. Take Continuous Delivery (CD) for an example. CD is a key DevOps practice. But DevOps philosophy does not define how to do CD. It's up to each software team to figure out how to implement CD in their context.

Site Reliability Engineering shares many goals with DevOps. Site Reliability Engineering also defines how Google operates their software. On the other hand, DevOps defines a methodology and leave out the implementation to software teams.

You can think of Site Reliability Engineering as Google's implementation of DevOps.

Adoption of Site Reliability Engineering in other companies

After the initial implementation in 2003, the engineers at Google refined their concept of Site Reliability Engineering through many years of practice.

As software industry started adopting DevOps there emerged many discussions and forums about DevOps implementations at various organizations. Google's engineers may have absorbed a lot through these and further refined their Site Reliability Engineering implementation.

In 2016, Google engineers who contributed to the development of Site Reliability Engineering published the SRE book compiling their findings and insights.

As more information about success of Site Reliability Engineering at Google began flowing through software industry, many other companies also started incorporating Site Reliability Engineering.

But, software teams have different requirements and challenges. So the implementation of Site Reliability Engineering at the other organizations was never a carbon copy of Site Reliability Engineering at Google.

What you would see in these software teams is a mix of DevOps practices sprinkled with Site Reliability Engineering as and according to their requirements. And that's perfectly OK.

Site Reliability Engineer vs DevOps Engineer (should I care about the title)

Now we come to a key point.

Over the years, software teams have been interchangeably using the titles DevOps Engineer and Site Reliability Engineer to identify the personnel in their operations teams.

A closer look at the way of work in these software teams reveal that the use of the title DevOps Engineer or Site Reliability Engineer has nothing to do with how much Site Reliability Engineering practices that they have incorporated.

Software teams are free to adopt DevOps or Site Reliability Engineering according to what works for them. There is no governing body (there's no requirement also) for either DevOps or Site Reliability Engineering. So, there's also no governance for the use of the titles DevOps Engineer or Site Reliability Engineer.

In job boards you will get postings for DevOps Engineers and Site Reliability Engineers. Those titles are well... just titles. Those titles by no means indicate how much Site Reliability Engineering the team has incorporated into their operational practices.

So, should I care about the job title DevOps Engineer vs Site Reliability Engineer?

In most cases, you don't have to.