Hey there and thanks for stopping by. My name is Bradley Knapp and I'm one of the Product Managers
here at IBM Cloud, and the question that we're going to answer today is what is the difference
between DevOps and SRE? This is a question that I hear on a fairly regular basis,
not just internally, but from external customers as well. And it's one that we'd like to help you
walk through so that you can really figure out what makes sense in your organization and I think
the answer is probably going to surprise you a little bit. Before we get into the video that I
do want to encourage you to like and subscribe, if you think that you're going to enjoy these things
just click on those buttons that way you get notified every time we come out with
something new. So, with that let's get right into the question and the question is DevOps
versus SRE.
And so, as we get into this, I think probably the most important thing to understand
is this isn't a versus question. You don't have to have one or the other. As a matter of fact,
I would argue and I think that many people would agree that SRE is actually an essential component
of DevOps. And DevOps, a good properly implemented DevOps method, leads to the necessity of SRE when
it comes time to deploy. There are two sides of the same coin. And so, that's obviously going to
lead to a little bit of confusion because DevOps is the development methodology, right. That's
it's all about integrating your development teams and your operations teams. It's about
knocking down those silos between them. It's about ensuring that everybody is singing off the same
song book and that's very important. And SRE is in charge of automating all of the things and making
sure that you never go down. There are really two parts of the same group, and so let's look at the
differences, right, because they do have some differences. Probably the first and largest one
is that when we think about our DevOps site over here, right, DevOps is about core development.
The DevOps guys, particularly your developers, they are doing the core development,
they are answering the question "what do we want to do?", they are working with product,
they're working with sales, they're working with marketing to develop design and deploy. What is
it that we do? They're working on the core. SRE on the other hand, they're not working on the
core. What they are working is the implementation of the core, they are working on the deployment,
and they are constantly giving feedback back into that core development group to say "hey
something that you guys have designed isn't working exactly the way that you think that it
is." So, if we were to break that down a little bit more they are helping the DevOps group,
our SRE group is helping the DevOps group to break down even more of those silos. If you
want to think about it this way DevOps is trying to develop the answer to how do we solve this
problem, SRE is saying how do we deploy and maintain and run to solve this problem it's
the theoretical versus the practical, and ideally they're talking to each other every day, right,
because SRE should be logging defects, they should be logging tickets back with development, but
probably most importantly they need to understand that they have the same goals. These groups should
never be aligned against one another. And so, they do have to have a common understanding.
Let's talk about one of the most important parts, right, we're going to talk about failure
because failure is not necessary failure, it's just a way of life. It doesn't matter what you
deploy. It doesn't matter how well it goes, it's going to happen. And so,
when we talk about failure everyone involved needs to understand that there's going to be some level,
right. There is a failure budget, or an error budget, where things are going to go wrong.
And what happens when things go wrong that's what figures out whether or not your organization is
working because your SRE team when it comes to failure, they're going to anticipate it,
they're going to monitor it, they're going to log it, they're going to record everything,
and ideally they can identify a failure before it happens. They're going to have predictive
analytics that are going to say "all right this thing is going to go bad based on what we've seen
before." And so, SRE is responsible for mitigating some of those failures through monitoring and
logging, and doing the preemptive parts, right. So we'll do the monitors, we'll do the logs.
SRE is also going to lead all of your post actual failure incident management, right. They're going
to get you through the incident to begin with and then they're going to hot wash it when it's done.
They're going to lead that RCA, that root cause analysis, and after they have that RCA completed,
and this is the most important part they have to take that RCA data and bring it back
over into dev and get some tickets open. You have to get dev online because you've gotta,
these are the guys who are gonna solve the core problem, some RCAs might be solved by SRE
internally, right. They're gonna spend 50 percent of their time writing, 50 of their time working,
and so some of that problem they may be able to fix directly, but sometimes that's not the case,
right. Our RCA may have found a problem that only dev can fix and that's all right,
that's not a big deal. They're going to get that over here, dev is going to implement,
and then probably the most important part, right, so you're going to get that new feature.
Dev is going to get that pulled together. They're going to get that new feature rolled out
and then they're going to pass that back into SRE and they're going to say "hey
SRE, that problem that we had we got a new feature for you."
And then our guys on the SRE side, what do they do? They then have to take that feature
and they have to figure out how to integrate it into their monitoring and their logging efforts
to make sure that we don't get into another RCA for the same kind of a problem.
So these groups, they are part and parcel of the same bunch. You really can't have one
successful organization without another. And when it comes to figuring out a distinction,
it's not something that you should spend a lot of time with. There are different skill sets,
right. Core development DevOps, these are the guys that really love writing software. SRE is a little
bit more of an investigative mindset, right. You have to be willing to go and do that analysis,
figure out what things have gone wrong, automate all of the things. But there's a lot that they
have in common. Everyone should be writing automation, everyone should be getting rid of toil
as much as possible because we just don't have the time to be doing manual tasks. When we can put the
computers in charge of it, right, computers are not great at thinking on their own, but if you
need it to do the same thing over and over and over again in exactly the same way you can't beat
computing for that. And so, automation is key, you just have a slightly different mindset. DevOps
is going to automate deployment, they're going to automate tasks, they're going to automate feature.
SRE is going to automate redundancy, and they're going to automate manual tasks that they can turn
into programmatic tasks to keep the stack up. And so, you know when we talk about DevOps versus SRE,
that's not the question, the question is how do we build DevOps, how do we build SRE,
and how do we be sure that they are always talking to each other because the institutional knowledge
that SRE has so much of if that doesn't get passed back into your DevOps group. You're never going
to be successful, you're going to have a silo here, and a silo here, and at the end of the day
both of these philosophies core, core component, is getting rid of silos, freeing ourselves from
those silos is what is going to make us all more successful. Thank you so much for stopping by
the channel today. If you have any questions or comments, please feel free to share them with
us below. If you enjoyed this video and you would like to see more like it in the future,
please do like the video and subscribe to us so that we'll know to keep creating for you.