Devops vs SRE | Difference Between Devops and SRE

Devops vs SRE | Difference Between Devops and SRE

In today’s Article, first we will understand what is Devops?

Why do you need it and also the Devops life cycle then we will understand what is SRE and why do you need it?

Once that is done, we will basically understand the differences between Devops and SRE.

Now without any further delay let’s begin with this comparative analysis.

What is Devops?

What is Devops?
What is Devops?

You must have heard about Devops a lot.

There’s a lot of Devops roles, developed clouds roll and AWS Devops.

So, a lot of jargon surrounding this one particular world.

Let me begin by giving you some details into why Devops was born in the first place.

Initially when software development was done there was a lot of problem with respect to the development team and the operations team.

What do I mean by that?

There are people who create these features the software that you see.

There are some people who are responsible in creating those softwares and there are some people (other people) who are responsible for hosting, it maintaining it and making sure that it is available to all of the users everywhere.

Now the problem with this was the simple fact that the Dev and the Ops team they used to function individually (like apart from each other).

So that led to a lot of clashes because the development team always wanted to push a lot of new features.

Whenever you write a single line of code also to a new developed feature it exposes it to a lot of bugs that’s why operations team did not prefer that we move at such a pace without testing and probably going through everything.

So, there’s a lot of clash between the development and the operations team.

That is when Devops came into the picture.

So, Devops is a software development methodology which basically improves the collaborations between the development and the operation teams by using various automation tools.

Now these automation tools are implemented through various stages which are called as a Devops life cycle.

When they found out that they have this problem between the development and the operations team that we are not able to function at the most prime efficient level that we can.

There is a lot of constraint with respect to the environmental differences and a lot of different problems like testing and integration a lot of problems are there with the development and the operations team.

That’s why someone decided that we need a certain set of methodologies some certain ideas some tools something that we follow.

This is the pattern that we will follow that will develop and integrate the relationship between the development and the operations teams.

Hence the entire product that you are building and that software that you are building the end result will be very seamless.

Probably bug free and it will be much better for everyone who is involved.

May it be development team. the operations team or the end users or the customers who are using your software.

That is why Devops was implemented.

So, Devops is a methodology.

It’s not one particular technology.

It’s a set of ideas or principles are collaborated with some automation tools which are designed in such a way that you can bring in all of those factors together.

Now, there is a lot of different things which are involved in Devops.

So, you have from pillars and Devops which goes like far beyond.

So, there is continuous development. Some of them I have given below.

  • Continuous form of development
  • Continuous testing
  • Continuous integration
  • Continuous deployment
  • continuous monitoring

So, Devops metallurgy believes that we constantly build on the software we constantly test whatever we have built.

If it is working properly then we check for the integration with the features that we have developed on the new environment if everything is working and properly and integration.

Whenever these things are created, we constantly deploy everything and we do constant monitoring of these tools.

So, everything is being monitored in Devops.

That is one of the methodologies or the pillars of concepts behind Devops.

How Devops Works?

How Devops Works?
How Devops Works?

How does Devops look like in the software development architecture or in the flow?

So, this is what the overall view looks like when you are talking about Devops.


Continuous Development

You have continuous development where our development is always developing and there is version control system which is responsible for integration as well.

And when the integration is done it is doing constant deploying and there is testing server and there are production servers.

There are two different kinds of servers.

You do not directly make a code and you push it to your customers.

You test it out first.

There is continuous testing involved.

Once it passed the continuous testing section and there are some feedbacks on the testing server.

They will monitor and they will do a lot of different things

Let’s say does not surpass all the tests then those tests are given as a feedback through the monitoring (This is not working properly)
.

Developer has to again change things and make it interactive and everything should work together.

It should be bug free and once it absolutely in their opinion that okay this is something that we can push out to the customers then you push it to the production server and that is where you have everyone working.

If this is an overall view of how it looks like on a software development architecture wise but talking about if you have to put it into words this is what it will look like.

So, you have:

  • Plan
  • Code
  • Build
  • Test
  • Release
  • Deploy
  • Operate
  • Monitor

So, you have these ideologies and you can see where there is continuous development.

So, you have in the planning and coding phase you have continuous development in release and deploy there is continuous deployment there is operator operate and monitor that is continuous monitoring and you are testing while building and testing.

All of this is done together at the same point of time and that brings through the continuous integration idea.

Devops is an idea where you have all of these things being done constantly.

This is done by leveraging with a lot of tools which are out there.

You have various different tools to remove the environmental dependencies. to remove the integration problems and to remove monitoring problems.

All of these tools they come together and they help you plan a seamless software development idea.

So that is what Devops does.

What is SRE?

What is SRE?
What is SRE?

(Around 2000) Someone in Google realized that Devops as good at it as it is there is something else that can be done right.

So, there’s a lot of different ideas which were flowing.

In Google, they form up with this idea called as an SRE.

Now SRE is a different job role altogether.

So, let’s start with what is SRE?

SRE basically stands for Site Reliability Engineering.

Basically it is a software engineering approach to operations where an SRE team uses software as a tool to manage systemsm solve problems and automate the operation tasks.


You May Also Like: How to Learn Programming Language Fast


SRE takes the tasks that have been historically done by the operation teams often manually instead of giving them to engineers or op teams who use software or automations to solve these problems.

They do it themselves and manage the production environment.

What do I mean by that?

In Devops what we were doing so far is we had a separate dev team, a separate ops team and these people were working independently of each other.

But leveraging different tools to eliminate the differences and the disparity.

Now what Google started suggesting is instead of doing that or even if we are doing that what we can do is we can introduce a new role.

Someone called as an SRE who is a site reliability engineer.

The job of this guy is like this guy has some operations background as well and software development background as well.

So, he is a combination of two.

He, understands both the sides of the picture.

You, put this guy in the software development team and this guy can solve all the problems that were being initially being addressed by the operation team.

This guy can help you out in both domains because he understands what is going on.

So basically, through this guy what we can do is we can eliminate a lot of workflow problems and a lot of operation problems.

We can eliminate a lot of different things because this guy has the knowledge of both of these domains.

So that is what SRE is as an idea.

Role of SRE Team

Role of SRE Team
Role of SRE Team

SRE teams are basically responsible for how the code is deployed, configured and monitored.

Plus, they check for the availability, latency change management, emergency response as well as the capacity management of the service in production.

So, whatever you have services which are running in the production the guy is responsible to see how it is deployed how it is being configured whether or not it is being monitored or how it is being monitored?

Not just that it has to look into the latency change management as well as the emergency responses.

This guy is responsible for all of the different factors which are in between the software as well as the operations team.

This guy has to be having a background where he has knowledge of both of these domains to do all of these tasks.

It’s a very specific kind of role in every different team of the job of the SRE.

So, how does he do that?
How do you go about doing all of these things?

Basically to determine the SRE how it works it helps to determine the new features that being that are being launched.

They test it across few different different metrics if you will.

They check it across these things called SLA, SLI and SLO which basically stand for Service Level Agreements and then there is Service Level Indicators and then there are Several Level Objectives.

What you do is basically you have different three different ideologies about how your system should be to the end user?

You have that kind of an agreement.

You put your objectives and you said okay I can have this amount of down time or this much error I have been allowed.

You do that as a service level objective and then there is a service level indicator (Ok, this is the thing which is supposed to be our end point).

Then you have an agreement with let’s say a third party where you tell them that okay when you are using my software and this you try to keep it a little more flexible because this in this one you will be paying money to the the third party.

You play the third party.

You are using my services what I will do?

If I get let’s say more than 30 of the downtime.

For every down time that I am like for every minute or every second or whatever the clause for this I will be paying you money.

If my software underperforms, I will be paying you money.

So, you try to plan out your software that you are designing and whatever the features that you are building around these metrics rather than seeing if it is working properly.

Because SRE believes that it that 100 reliability of a software is a myth.

They do not believe that 100 reliability will be there for every software.

You do not need that.

What you need is that this kind of failure is it will be there.

You plan for the failure you accept this feeling and you work around it.

For example, let’s say there are a lot of different kinds of fears and it depends on how you define that failure.

There are some features which may go unnoticed to your end customers as well.

Let’s say there was a downtime of one micro second.

Nobody will notice this.

But you’re monitoring your tools will then okay your service went down even if it was for one micro second it did go down right.

So, there are certain number of failures which is accepted.

Now either what the ideology of SRE says that’s that:

Devops is that we have to eliminate that kind of things we have to eliminate that kind of reliability problems that we wanted to be there one hundred percent.

What SRE says is that we do not need that we do not need that kind of the level of reliability.

You need to build out features in such a manner that it crosses the threshold of what is expected out of your software.

It basically removes time and efficiency.

Let’s say if I find the amount and the money and the energy that I am putting into eliminating that one micro second of the problem which goes unnoticeable.

I do eliminate that problem but the amount of money that I am putting in that is of no value to me because nobody was actually noticing it.

It was not something which was actually valuable to my industry but I did eliminate the problem but the money invested in does not make sense because that is the amount of failure that could be accepted.

So, in SRE you build around those feelings you accept federal salaries you build around those factors and you see what can be done.

So that is the idea behind the SRE.


Check out this Main Article For More Info: SRE VS Devops


Devops Vs SRE

What is Devops and what is SRE?

Let’s make a step by step and a complete comparison between Devops and SRE.

Aproach to the problem (In Devops)

Devops believes in reducing the organization slows.

What do I mean by that?

Organization syllabus basically stands for a process or any kind of methodology where the systems which are involved are working independently.

So, Devops believes that we can remove these independently working system we can integrate them together and it does it through leveraging some tools.

So that is the idea of Devops.

Approach to the problem (In SRE)

Whereas SRE says that let’s share the ownership with the developers by using the same tools and same techniques and let’s put one guy in there who will share these responsibilities as well.

You shared the ownership of the entire product instead of having individual people who are just responsible for their particular features you put in people who are responsible for both the end of the thing.

So, they increase the ownership of the product that you are building.

That is the basic approach to the problem of SRE and Devops how do they approach the problem removing the problem between development and the operations team.

Dealing with failures (With Devops)

In Devops failures is accepted as normal because they are continuously testing.

There is a testing environment.

You do everything.

You accept the features and you continuously work in eliminating it.

Dealing with failures (With SRE)

In SRE you have a formula for balancing the accidents failures and against the new releases.

So, whenever you are trying to build a new product you have a certain amount of limit.

You pre-plan it.

okay this is the amount of failure that I am going to be accepting.

Whereas in Devops you try to test out everything in testing environment.

You try to fix everything before you push it out.

While doing SRE you think about okay this much failure I can maybe deal with and I can work around those formulas.

So, you work with those formulas.

That is how these two are different in dealing with failures.

Implementing Features (In Devops)

Devops believes in implementing gradual change.

As I mentioned before.

We have a complete pipeline where we have people developing and then they are building and then they are testing and then it goes to again a review phase then you really do the changes that you have profound faulty in the testing phase and then you push it to the production server.


You May Also Like: Best Programming Language To Learn First in 2021


So that is the idea that was believed by the Devon of steam in the initial stages because the operations team could not keep up with the features which the dev team was pushing.

The more you write the greater number of features you push in the more you make it a vulnerable to bugs of different kinds.

So, every piece of line you write in a code is a potential bug.

A lot of people say that.

That was the idea so they wanted to make this change of number of features that they are pushing out very gradual.

That you want to test out everything and then you push it to the environment so that the end user does not face any kind of a downtime.


Implementing Features (In SRE)

The SRE says that you have to balance it out.

You cannot be pushing so many features and bringing down time to your customers.

Let’s say if I am a customer if I am using a software and the website keeps on going down again and again and again and again after some really feature and you will be like okay that that’s not working out right.

You do not want that.

But at the same time, you cannot be taking like a year year and a half for producing some products.

You people are waiting for the product to be out there or the feature to be out there.

You are taking too much time in implementing it so people get frustrated and they want to hurry the process.

They want the future.

So, there is this balance between the features that users expect you to put out and the reliability they expect of your software as well.

So, SRE believes that we should move quickly reduce while creating the features we can move quickly by creating features.

We can create a lot of features but while implementing it the idea behind it would be, we will reduce the failure cost.

That is the idea behind.

We will try to keep the money that it costs us for let’s say the risk to reward feature in here is something which is valuable.

You will put out a lot of features but you will keep in mind about the failure.

You put out the features quickly but you keep in mind about the failures and reducing the cost of failures while doing so.

That is what the ideology is for SRE and Devops.

The methodology (In Devops)

Devops believes in leveraging tools and automations.

You have two separate teams stills but what you do is you have one set of teams they are working with leveraging the automating tools which are out there so you use different similar kinds of environment.

The methodology (In SRE)

SRE relies on the site reliability engineers within the development team to remove the communication and the workflow problems.

You depend on people and you depend on sharing the responsibility for the code that you are putting out and you share the ownership and you work with the problems that is the difference between the methodology.

Then there is another methodology which is there for the Devops and SRE which is Devops believe in measuring everything.

So, they believe in measuring everything which is out there.

SRE believes that operations are software problem as well.

So, what you do is you define prescriptive ways of measuring some particular things like availability of time outages start oil etc.

You measure these particular factors and you work on these particular factors only.

Whereas Devops believe in measuring everything so that is another methodology difference between Devops and SRE.

Quick Comparison Between SRE and Devops

Both SRE and Devops basically work to bridge the gap between the development and the operations team.

They want to deliver service faster in a more efficient way.

The idea is the same to bridge the gap and make everything more seamless and better.

SRE relies on the SRE engineers which is the site reliability engineers within the development team who also have an operations background to remove these problems.

Whereas Devops depends on automation tools and different powers of leveraging different tools which are out there to solve their problem.

So, that is one point of difference.

In terms of code and new features Devops focuses on going through the development pipeline very efficiently.

It believes in going through that pipeline efficiently to put out their products.

While SRE is focused on balancing the site reliability with creating new features.

So, what is the downtime and measuring these factors as I mentioned toil and the uptime and latency.

Also you manage to measure these factors and then you apply features based on that.

Now SRE can help Devops teams whose developers are overwhelmed by operations and tasks and need someone with the more specialized skill with respect to the operations.

What I believe is SRE and Devops can go hand in hand and Devops team can have an SRE personnel in embedded in them and that can smooth things along with both the ways.

I think these two things are not that much different.

They are looking to you know reach to the same goal.

If you think about it SRE is the way that you implement Devops right.

So, you implement Devops through that.

Basically what you are looking out for here is that your Devops team can also have a specialist in SRE a person who knows both dev and ops operations and he has an operations background and the software development background.

He sees someone who specializes with these skills to solve these problems so you can have a guy in there and these two things can go hand in hand and make your entire software development metrology smoother.

Final Words
This is a Basic and an advanced level comparison between SRE and Devops. In Devops vs SRE comparison which one you found the more beneficial. Tell us in the comment section. I hope you enjoy this Deeply researched Content.

admin

I am Blogger and a Website Developer. Student of Information Technology. Working as a Professional Blogger and Web Developer.

Leave a Reply