I'm Liz, a Site Reliability Engineer, or SRE, at Google.

And I teach Google Cloud customers

how to build and operate reliable services.

SETH VARGO: And I'm Seth, a Developer

Advocate at Google focused on infrastructure and operations.

And Liz and I are here to settle things once and for all.

Which is better, DevOps or SRE?

LIZ FONG-JONES: Whoa there, Seth.

Hold on a second.

I'm not sure you're really looking

at this in the right way.

But first of all, maybe we should clarify some things.

What do you think DevOps is?

SETH VARGO: So that's a great question, Liz.

Back in the day, operators and developers

had a lot of contention.

Developers used to throw their code

over the metaphorical wall, and operators

were responsible for keeping that code running

in production.

Operators had little understanding of the code

bases, and developers had little understanding

of operational practices.

But developers were concerned with shipping code,

and operators were concerned with reliability.

This misalignment often caused tension

within the organization.

LIZ FONG-JONES: So if I understand you correctly,

you're saying that the developers were

responsible for features, and the operators

were responsible for stability, meaning the developers wanted

to move faster to get their features out faster

and the operators wanted to move slower to keep things stable?

I could see how that would cause a lot of tension.

SETH VARGO: Exactly.

So DevOps is a set of practices and a culture designed

to break down those barriers between developers, operators,

and other parts of the organization.

I break DevOps down into five key areas.

First, reduce organizational silence.

By breaking down barriers across teams,

we can increase collaboration and thorough put.

Second, accept failure as normal.

Computers are inherently unreliable,

so we can't expect perfection.

And when we introduce humans into the system,

we get even more imperfection.

Third, implement gradual change.

Not only are small, incremental changes easier to review,

but in the event that a gradual change does

make a bug in production, it allows

us to reduce our mean time to recover,

making it simple to roll back.

Fourth, we need to leverage tooling and automation.

And fifth, we need to measure everything.

Measurement is a critical gauge for success.

And without a way to measure if our first four pillars

were successful, we would have no way of knowing if they were.

So, Liz, you've been an SRE at Google for over 10 years now.

Do you think any of the way that I described DevOps aligns

with your experience as an SRE?

LIZ FONG-JONES: It's sounding very familiar.

Because, if you think about DevOps as a philosophy,

SRE is a prescriptive way of accomplishing that philosophy.

So if DevOps were an interface in programming language,

you might almost say that SRE is a concrete class that

implements DevOps.

Let's take a look at how that is.

So, Seth, when you talked about eliminating

organizational silos, what I thought about

is the fact that we share ownership of production

with our developers.

And we use the same tooling in order

to make sure everyone has the same view and same approach

to working with production.

When you talked about accepting accidents and failure

as normal, what I thought about is the fact that--

similar to many DevOps practitioners--

we have blameless postmortems, where

we make sure that the failures that happen in our production

systems don't happen the exact same way more than once.

And we accept the failures as normal by encoding

a concept of an error budget of how much the system is allowed

to go out of spec.

And then third, we talked about making gradual changes.

And when you said that, I thought about the fact

that we canary things, that we roll

things out to a small percentage of the fleet

before we move them out for all users.

And then fourth, when you talked about leveraging

tooling and automation, what I thought about

is the fact that we try to eliminate manual work

as much as possible.

So we measure how much toil we have,

and then we try to automate this year's job away.

And then fifth, when you talked about measuring everything,

I thought about exactly that measurement

of measuring the amount of toil that we have

and measuring the reliability and health of our systems.

SETH VARGO: I really like that.

Class SRE implements DevOps.

We should get that on a shirt or something.

But just like a class in a programming language,

there might be additional functions or methods

that don't necessarily correspond to that interface.

Or the class might implement multiple interfaces.

Do you think SRE is like that?

LIZ FONG-JONES: I absolutely think

that's the case because of the fact

that SRE doesn't do things in the exact same way

that other people that implement DevOps elsewhere

might want to do.

So we'll talk a little bit more about those differences,

such as how exactly SLOs work, which

are a very specific concept that we implement in order

to make SRE successful.

SETH VARGO: Great.

Well, that settles it, then.

It turns out that DevOps and SRE aren't two competing methods,

but rather close friends designed

to help break down organizational barriers

to deliver better software faster.

Thank you, everyone, for watching.

Please be sure to check the description

below for more links, and don't forget

to subscribe to our channel.

Stay tuned for our next video, where

we will discuss the differences between SLIs, SLOs, and SLAs.