DevOps vs SRE | Difference Between DevOps and SRE | SRE Vs DevOps | Intellipaat

[Music] hey guys welcome to this session by intellipad in this session we're going to do a comparative analysis of devops and site reliability engineering or commonly called as sre and before moving on with this session please subscribe to our channel if you haven't already so that you don't miss our upcoming videos and also leave a like to our videos if you enjoy our content now let's just take a quick glance at what we're going to do in this particular session first we'll understand what is devops why do you need it and also the devops life cycle then we'll understand what is sre and why do you need it once that is done we'll basically understand the differences between devops and sre and that would be the end of this particular session guys so now without any further delay let's begin with this comparative analysis so what is devops so you must have heard about devops a lot right so there's a lot of devops roles developed clouds roll aws devops so a lot of jargon surrounding this one particular world so let me begin by giving you some uh details into why devops was born in the first place so initially when software development was done uh there was a lot of problem with respect to the development team and the operations team what do i mean by that so 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 and 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 and 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 so 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 you know most prime efficient level that we can and 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 like okay we need a certain set of methodologies some certain ideas some tools something that we follow okay this is the pattern that we will follow that will develop and integrate the relationship between the development and the operations teams and hence the entire product that you are building and that software that you are building the end result will be very seamless uh and 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 uh there is a lot of different things which are involved in devops right so you have from pillars and devops which goes like far beyond so there is continuous development so they believe that it should be a continuous form of development continuous testing continuous integration deployment and monitoring so devops metallurgy believes that we constantly build on the software we constantly test whatever we have built and 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 and whenever these things are created we constantly deploy everything and we do constant monitoring of these tools so everything is being monitored in devops so that is one of the methodologies or the pillars of concepts behind devops so how does that look like in the software development architecture or in the flow so this is what the overall view looks like when you're talking about devops so 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 is production servers there are two different kinds of servers you do not directly make a code and you push it to your customers right you test it out first so there is continuous testing involved once it passed the continuous testing section and there are some feedbacks on the testing server of they will monitor and they'll do a lot of different things and if it let's say uh does not surpass all the tests then those tests are given as a feedback through the monitoring okay this is not working properly developer has to again change things and you know make it interactive and you know 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 so 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'll look like so you have plan code build test release deploy operate and monitor right so you have these uh 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 and all of this is done together at the same point of time and that brings through the continuous integration idea so devops is an idea where you have all of these things being done constantly and this is done by leveraging with a lot of tools which are out there so you have various different tools to remove the environmental dependencies to remove the integration problems to remove monitoring problems so all of these tools they come together and they help you plan a seamless software development idea right so that is what devops does so what is sre so uh in around 2000 someone in google realized that okay 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 and 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 so sre basically stands for site reliability engineering so basically it is a software engineering approach to operations where an sr team uses software as a tool to manage systems solve problems and automate the operation tasks so basically si takes the tasks that have been historically done by the operation teams often manually and instead of giving them to engineers or op teams who use software or automations to solve these problems and they do it themselves and manage the production environment what do i mean by that so 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 you know 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 and 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 so he understands both the sides of the picture so you put this guy in the software development team and this guy can solve all the problems that were being initially being uh you know addressed by the operation team and 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 a lot of uh 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 just a quick info guys test your knowledge of devops by answering this question which of the following is a devops tool a get b jenkins c docker d all of the above comment down your answers in the comment section below whoever gets the correct answer will win 5 000 points in intellipaat wallet subscribe to intellipack to know the winners now let's continue with the session so sri teams are basically responsible for how the code is deployed configured and monitored as well as the checks 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 so this guy is responsible for all of the different factors which are in between the software as well as the operations team so this guy has to be having a background where he has knowledge of both of these domains to do all of these tasks and it's a very specific kind of role in every different team of the job of the sre so how does he do that like so how do you go about doing all of these things so 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 so they check it across these things called sla sli and slo which basically stand for uh service level agreements and then there is service level indicators and then there are several level objectives so what you do is basically you have different three different ideologies about how your system should be to the end user right so uh you have that kind of an agreement so you put your objectives and you said okay i can have this amount of down time or this much error i have been allowed and you do that as an service level objective and then there is a service level indicator okay this is the thing which is supposed to be our end point and 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'll be paying money to the uh the third party so you play the third party okay you're using my services what i'll do is if i get let's say more than 30 of the downtime for every down time that i'm like for every minute or every second or whatever the clause may be 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 is a myth they don't 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 so you plan for the failure you accept this feeling and you work around it for example um let's say there are a lot of different kinds of fears and it depends on how you define that failure right there are some features which may go unnoticed to your end customers as well so let's say there was a downtime of one micro second right okay nobody will notice this but your 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 amount of failures which is accepted now either what the ideology of asari says that's that devops is that okay 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 but what siri says is that we don't need that we don't 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 and it basically removes time and efficiency so let's say if i find the amount and the money and the energy that i'm putting into eliminating that one micro second of the problem which is which goes unnoticeable i do eliminate that problem but the amount of money that i'm putting in that is of no value to me because nobody was actually noticing it it wasn't something which was actually valuable to my industry but i did eliminate the problem but the money invested in doesn't 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 right okay guys a quick info if you're looking for an end-to-end training in devops intellipaat provides a complete devops certification training and those details are available in the description box below and you can check it out now let's continue with this session so let's move on and compare these two terms very quickly so what is devops and what is sre so let's start with the approach to solving the problem so devops believes in reducing the organization slows what do i mean by that so uh organization syllabus basically stands for a process or any kind of uh methodology where uh the systems which are involved are working independently so devops believes that we can remove these uh independently working system we can integrate them together and it does it through leveraging some tools right so that is the idea of devops 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 uh responsibilities as well so you 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 so that is the basic approach to the problem of sre and devops how do they approach the problem of you know removing the problem between development and the operations team the next thing that we do is dealing with failures now in devops failures is accepted as normal right because they are continuously testing there is a testing environment you do everything you accept the features and you continuously work in eliminating it whereas 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'm going to be accepting whereas in devops you try to test out everything in the devops environment sorry testing environment and 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 next one is implementing features well as devops believes in implementing gradual change as i mentioned before right 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 slowly and steadily and then you push it to the production server so that is the idea that was believed by the devon of steam in the initial stages because the operations team couldn't keep up with the features which the dev team was pushing and the more you write the more number of features you push in the more you make it a vulnerable to bugs of different kinds right so every piece of line you write in a code is a potential bug a lot of people say that but having said that so that was the idea so they wanted to make this change of number of features that they are pushing out very gradual so that you want to test out everything and then you push it to the environment so that the end user doesn't face any kind of a downtime whereas the sre says that you have to balance it out right you cannot be pushing so many features and bringing down time to your customers where let's say if i'm 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'll be like okay that that's not working out right you don't want that but at the same time you cannot be taking like a year year and a half for producing some products so you people are waiting for the product to be out there you are or the feature to be out and you are taking too much time in implementing it so people get frustrated and uh they become you know they want to hurry the process they want the future so there is this balance between the the features that users expect you to put out and the reliability they expect of your software as well so srd believes that we should move quickly reduce uh by off by 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 so you won't put out you will put out a lot of features but you will keep in mind about the failure so 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 next one is the methodology devops versus sre the methodology the difference is the devops believes in leveraging tools and automations right so you have two separate teams stills but what you do is you have one set of team they are working with leveraging the automating tools which are out there so you use different similar kinds of environment whereas sre relies on the site reliability engineers or the sre within the development team to remove the communication and the workflow problems so instead of leveraging tools and automation tools and or different tools which are out there you depend on people and you depend on sharing the uh 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 uh 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 whereas sre believes that operations is 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 and 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 just a quick info guys test your knowledge of devops by answering this question which of the following is a devops tool a get b jenkins c docker d all of the above comment down your answers in the comment section below whoever gets the correct answer will win 5 000 points in intellipaat wallet subscribe to inter pack to know the winners now let's continue with the session so with that we have come to the end of uh the comparison so let's quickly have them summarized as to what our conclusion is so the conclusion being the 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 right 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 uh 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 so i showed you the pipeline initially so that pipeline of production server testing server and goes through continuous integration and testing 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 and 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 so 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 so i think these two things are not that much different they are looking to you know reach to the same goal but uh if you think about it sre is the way that you implement devops right so you implement devops through that so basically what you are looking out for here is that your devops team can also 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 uh 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 more smooth so that's that so how to get started so we've learned about what is devops and what is sre what if you wanted to get started with devops so we at intellipaat we understand that an investment in knowledge always pays the best interest that's why we provide a lot of free content in the form of blogs and youtube tutorials and you can find out a lot about lot of different technologies like devops sre and aiml on our blogs and our youtube channel as well we post long tutorials up to 11 hours on our youtube channel and we have detailed blogs on our blog page as well so if you are interested you can go check them out but if you are someone who is looking to get trained by us who who wants uh you know to be able to ask their doubts in a one-on-one session are being taught by a live instructor who is an industry expert and wants project works and lab exercises and practice and you know follow a guided uh path along the way then what i would recommend is going and checking out our website we do provide training for various different technologies which are out there so you can go check them out as well if you are interested in that with that i think we have come to the end of this session so if you have any questions about this session or any other session that we have had the numbers are on your screen so you can reach us out on there or you can write to us at sales at the reading telepath dot com other than that you can put your comments down below and we'll be happy to assist you okay guys a quick info if you're looking for an end-to-end training in devops intellipaat provides a complete devops certification training and those details are available in the description box below and you can check it out

Channel: Intellipaat

Views: 6,485

Rating: 4.9359999 out of 5

Keywords: Devops vs SRE, Difference Between Devops and SRE, SRE vs Devops, Site Reliability Engineering vs Devops, Devops, Amazon Web Services, Site Reliability Engineering, Comparison Between Devops and Sre, Comparison Between SRE and Devops, How Devops is Different than Sre, Devops Tutorial for Beginners, Devops Tutorial, Devops for Beginners, Intellipaat DevOps, intellipaat

Id: P3-VULjUNR4

Length: 21min 24sec (1284 seconds)

Published: Mon Jan 25 2021