I like these definitions, I think a lot of orgs have their own "versions" of that based on their specific environments/culture. I am part of an Ops team where most of us are from a systems/network/security background and are maintaining the infrastructure (dev and prod) in AWS using a mix of cloud native and legacy tools (lots of EC2's and some EKS). So are we SRE or DevOps? I would say something in-between. What are your thoughts on "Platform" teams (not DevOps/SRE but providing a PaaS and respective tooling)? That could be another topic for a video :).
The problem is, from my perspective, that we do not have clearly defined terms, yet we use them all the time. That brings confusion since we might be talking for a long time and not understand each others because we have different associations with different words and acronyms. For example, shortwhile ago I have a very complicated discussion with a team that tried to convince me that new microservices should all be in a monorepo. I was strongly against it only to discover (a few hours later) that those are not microservices but a monolith split into interdependent services (distributed monolith). The problem was not whether it is a set of microservices or a monolith, but that we had different associations with the word "microservices" so we came to different conclusions, only to agree a while later once we got on the same page about the subject we're talking about. I think it's similar with SREs and DevOps. It's not whether one model is better than the other (that would be a different discussion), but whether we have the same understanding what those words mean so that we can have a productive discussion. I just realized that I probably went completely off the topic so I'll stop here. Platforms are going to be my focus starting today (partly because my new job is mostly focused on platforms) so your suggestion comes at just about the right time :)
@@DevOpsToolkit I completely agree. DevOps in our specific org is just a new name for systems admin in the cloud. Now whether the practices we follow truely embrace a DevOps mindset is a different story :). Same goes for Platform, it means a different thing to different people. For some it's Kubernetes and for others it's a layer above that (or something else that nobody understands)
I stumble on to your UA-cam after checking out too many UA-cam about the difference between DevOps Vs SRE. Your one of the definition: System Engineers who can write the code is spot on. Great video with easy to understand explanation. Thanks for your video.
Feel free to suggest any other topic that might be interesting. I can't guarantee when I'll be able to work on it (the TODO list is growing faster than I can manage). Nevertheless, I promise that all suggestions will be covered before my retirement :)
@@DevOpsToolkit Ah, surely. I can imagine what that list will look like :) Something I'll love to see is your best practices for running (& troubleshooting) production systems on Kubernetes. I've seen a lot of your videos and I'm not sure if you've done this one. If yes, maybe point me in that direction. Also, about the TODO list, I have some suggestions haha. I'll send you a DM on Twitter. Thanks :)
@@krishnadaskp21 I disagree. Traditional prod support people know software engineering. It's just additional tools and mindset change which are required. Most of the companies already rebranded support analyst roles as SREs and giving trainning programs.
DevOps is managers way to get 2 people for the one price, DevSecOps 3, DevSecDBOps well goes on CIODevSecDBOps, CEOCOOCIODevSecDBOps is a single person startup.
I think that's very true in practice, but not necessarily how SRE was born in Google. Over there, the idea was to use development skills to solve operational problems. But, as you said, when it got adopted by other companies, the adopters were often ops people without development experience.
True but i think we overthink this in some ways we divide it way to much like devops is what needs to be done sre is how. letme tell you if someone knows how something is done he or she will have brilliant ideas on what actually needs to be done. all im saying is that sres are smart and it is good to give them goverance and especially if your goal is to break up silos letting them have access to product information and be a part of decision and creating the devops culture will only be beneficial.
Great video as usual Viktor, thanks. I think this time I disagree a bit with you. Well, for me there is no such thing as a DevOps Engineer. Although I usually classify myself as one since people understand better what I do. I think DevOps is a culture applied to a team and not a role. Maybe I'm like someone who doesn't want to accept the reality, where people started using DevOps Engineer to classified people with more focus on the infrastructure. I mean, by the book the definition is about team culture but the general perception of the definition is something totally different. So maybe the definition just changed. Also, your definition of a DevOps engineer is a mix of team culture with technical tasks. Doesn't that means that we are somehow with difficulties defining something that really does not exist or is a DevOps Engineer someone like a Scrum Master, ie., with some focus on the team methodology and coaching?
I completely agree with you that there is no such thing as a DevOps engineer. If I made the impression in the video that there is, that was a mistake on my part. I believe that DevOps is mostly about breaking silos between devs and ops and forming self-sufficient small teams capable of managing a full lifecycle of an application (or more). That means that the teams need to be small (anything bigger than 8-10 people is not a team but a school reunion) and that they need to have collective experience to do everything from figuring out what should be done next, to running it in production. I'll need to re-watch the video and make sure that I do not give an impression that there is something like a DevOps Engineer...
@@DevOpsToolkit I just re-watched the video and indeed you never talk about "DevOps Engineer". I misunderstood or simply assumed that the comparison was between the two. Sorry for the confusion. Anyway, things are clear now and I'm happy with that :)
@@andrepires5251 There is no need for "sorry for the confusion". Most people think in terms of DevOps Engineer and most job offers are something along the lines of "we are hiring DevOps engineers". A significant part of the world think of it that way and, in my opinion, is ruining the idea behind DevOps.
@@DevOpsToolkit Yeah, DevOps Engineer is just a catchy name Operator v2. More questions for you this time about SRE: so in a DevOps team you see SREs being part of that team, as a guy with more expertise with Infrasture and supporting on that activities? Because, in the video, you said that SREs are limited to production and not caring about Integration or the staging environment. I supposed that I was an SRE but I'm not only focused on production but also staging and the CI. So my role is... Software developer? We are a small team, without having anyone only focus on production and monitoring so far.
@@andrepires5251 SREs main objective is to keep the whole production system (not an individual app) in a healthy and responsive state. If SREs care about staging, integration, etc., that's still not their main preoccupation. On top of that, SREs tend to be involved with app teams but that's mostly in order to ensure that whatever is delivered to production is not going to mess it up. Normally, that involvement is bigger with new apps and, as we gain confidence, that involvement keeps dropping and, eventually disappears. From that perspective, SREs are similar to QA (at least in how I see it). Devs write tests, not QA and there is no need to have many (if any) dedicated testers. Still, in bigger organizations, having a few "experts" in testing is useful mostly so that they can "teach" devs how to bake quality into a product from the start. Their involvement with product teams is to ensure something through know-how, rather than to do something. Similarly, SREs are not (or should not) be in charge of deploying anything, but keeping prod. systems healthy and helping others create products that will not mess up everything. Nevertheless, all that applies to larger orgs. In smaller companies, roles are often mixed and we all do what needs to be done so there is nothing wrong if an SRE works on, let's say, a staging environment.
SRE (Site-Reliability-Engineering) vs. DevOps (DevelopmentOperations) ... sounds like the old mantra as Eric Raymond has described it in his famous paper "The Cathedral & the Bazar" ... SRE as the old school Cathedral following its traditional waterfall-development-cycle ... vs. ... DevOps as the Bazar following the new mantra "release early, release often!" ... Adressing the systemic failure mechanism that it is impossible to avoid software bugs ... so make all the early adopters out there in the open source community part of your test strategy ... ;-)
Interesting analagy and I agree to some extent. In my opinion; and where we kind of agree, SRE is the first step to adopting agile as corporations shift from years of having silos between I&O and service delivery and cannot fully grasp how to change to DevOps (culturally and organizationaly). Most companies adopt "DevOps" teams (they miss the point of DevOps) and the teams somewhat resemble SRE. Rarely do they ever fully shift to Devops (culture and organization)
General terms maybe. Yet many organizations it’s software engineering experts that understand systems. Expert in all of them. I’d thing more SREs start in software and shift right initially and then shift back left later after automation is built. Devops is a practice for everyone including SREs. SRE is an actual job
You're right that it is more common for SREs to start in software than in operations. Both types of experience are required but it seems to be easier for a dev to jump into ops than the other way around. P.S. That was a generalization that does not apply to all, but is based on my limited experience and observation :)
Are you SRE and/or DevOps? How do you relate what you are doing with what the video explained?
I like these definitions, I think a lot of orgs have their own "versions" of that based on their specific environments/culture. I am part of an Ops team where most of us are from a systems/network/security background and are maintaining the infrastructure (dev and prod) in AWS using a mix of cloud native and legacy tools (lots of EC2's and some EKS). So are we SRE or DevOps? I would say something in-between. What are your thoughts on "Platform" teams (not DevOps/SRE but providing a PaaS and respective tooling)? That could be another topic for a video :).
The problem is, from my perspective, that we do not have clearly defined terms, yet we use them all the time. That brings confusion since we might be talking for a long time and not understand each others because we have different associations with different words and acronyms. For example, shortwhile ago I have a very complicated discussion with a team that tried to convince me that new microservices should all be in a monorepo. I was strongly against it only to discover (a few hours later) that those are not microservices but a monolith split into interdependent services (distributed monolith). The problem was not whether it is a set of microservices or a monolith, but that we had different associations with the word "microservices" so we came to different conclusions, only to agree a while later once we got on the same page about the subject we're talking about.
I think it's similar with SREs and DevOps. It's not whether one model is better than the other (that would be a different discussion), but whether we have the same understanding what those words mean so that we can have a productive discussion.
I just realized that I probably went completely off the topic so I'll stop here.
Platforms are going to be my focus starting today (partly because my new job is mostly focused on platforms) so your suggestion comes at just about the right time :)
@@DevOpsToolkit I completely agree. DevOps in our specific org is just a new name for systems admin in the cloud. Now whether the practices we follow truely embrace a DevOps mindset is a different story :). Same goes for Platform, it means a different thing to different people. For some it's Kubernetes and for others it's a layer above that (or something else that nobody understands)
Great overview. Thank you
I stumble on to your UA-cam after checking out too many UA-cam about the difference between DevOps Vs SRE. Your one of the definition: System Engineers who can write the code is spot on. Great video with easy to understand explanation. Thanks for your video.
I appreciate that!
The 'What' and the 'How'.
Thanks, Victor!
Feel free to suggest any other topic that might be interesting. I can't guarantee when I'll be able to work on it (the TODO list is growing faster than I can manage). Nevertheless, I promise that all suggestions will be covered before my retirement :)
@@DevOpsToolkit Ah, surely. I can imagine what that list will look like :)
Something I'll love to see is your best practices for running (& troubleshooting) production systems on Kubernetes.
I've seen a lot of your videos and I'm not sure if you've done this one. If yes, maybe point me in that direction.
Also, about the TODO list, I have some suggestions haha. I'll send you a DM on Twitter.
Thanks :)
Adding "troubleshooting Kubernetes in production" to the TODO list and waiting for the DM on Twitter :)
SRE to me sounds like old school production application support + production ops support to avoid failure or identify the failure before it occurs.
Kind of. Traditional prod app support does may not have the software engineering knowledge to build reliability into a product. SREs do.
@@krishnadaskp21 I disagree. Traditional prod support people know software engineering. It's just additional tools and mindset change which are required. Most of the companies already rebranded support analyst roles as SREs and giving trainning programs.
Thank you for the great explanation!
That was great! Thank you.
System engineer that knows how to code.. That's make perfectly sense out of the rest.
DevOps is managers way to get 2 people for the one price, DevSecOps 3, DevSecDBOps well goes on CIODevSecDBOps, CEOCOOCIODevSecDBOps is a single person startup.
That is unfortunately often true. The only advice I can give in those cases is to run away.
I like your style. Thanks for the interesting video.
Thanks for watching!
while it may sound stupid here's my take: DevOps Engineers are developers that do DevOps, while SREs are Operation Staff that do DevOps
I think that's very true in practice, but not necessarily how SRE was born in Google. Over there, the idea was to use development skills to solve operational problems. But, as you said, when it got adopted by other companies, the adopters were often ops people without development experience.
True but i think we overthink this in some ways we divide it way to much like devops is what needs to be done sre is how. letme tell you if someone knows how something is done he or she will have brilliant ideas on what actually needs to be done. all im saying is that sres are smart and it is good to give them goverance and especially if your goal is to break up silos letting them have access to product information and be a part of decision and creating the devops culture will only be beneficial.
sre is the one who accomplishing devops philosophy
Great video as usual Viktor, thanks. I think this time I disagree a bit with you.
Well, for me there is no such thing as a DevOps Engineer. Although I usually classify myself as one since people understand better what I do. I think DevOps is a culture applied to a team and not a role. Maybe I'm like someone who doesn't want to accept the reality, where people started using DevOps Engineer to classified people with more focus on the infrastructure. I mean, by the book the definition is about team culture but the general perception of the definition is something totally different. So maybe the definition just changed.
Also, your definition of a DevOps engineer is a mix of team culture with technical tasks. Doesn't that means that we are somehow with difficulties defining something that really does not exist or is a DevOps Engineer someone like a Scrum Master, ie., with some focus on the team methodology and coaching?
I completely agree with you that there is no such thing as a DevOps engineer. If I made the impression in the video that there is, that was a mistake on my part.
I believe that DevOps is mostly about breaking silos between devs and ops and forming self-sufficient small teams capable of managing a full lifecycle of an application (or more). That means that the teams need to be small (anything bigger than 8-10 people is not a team but a school reunion) and that they need to have collective experience to do everything from figuring out what should be done next, to running it in production.
I'll need to re-watch the video and make sure that I do not give an impression that there is something like a DevOps Engineer...
@@DevOpsToolkit I just re-watched the video and indeed you never talk about "DevOps Engineer". I misunderstood or simply assumed that the comparison was between the two. Sorry for the confusion. Anyway, things are clear now and I'm happy with that :)
@@andrepires5251 There is no need for "sorry for the confusion". Most people think in terms of DevOps Engineer and most job offers are something along the lines of "we are hiring DevOps engineers". A significant part of the world think of it that way and, in my opinion, is ruining the idea behind DevOps.
@@DevOpsToolkit Yeah, DevOps Engineer is just a catchy name Operator v2.
More questions for you this time about SRE: so in a DevOps team you see SREs being part of that team, as a guy with more expertise with Infrasture and supporting on that activities? Because, in the video, you said that SREs are limited to production and not caring about Integration or the staging environment. I supposed that I was an SRE but I'm not only focused on production but also staging and the CI. So my role is... Software developer? We are a small team, without having anyone only focus on production and monitoring so far.
@@andrepires5251 SREs main objective is to keep the whole production system (not an individual app) in a healthy and responsive state. If SREs care about staging, integration, etc., that's still not their main preoccupation. On top of that, SREs tend to be involved with app teams but that's mostly in order to ensure that whatever is delivered to production is not going to mess it up. Normally, that involvement is bigger with new apps and, as we gain confidence, that involvement keeps dropping and, eventually disappears. From that perspective, SREs are similar to QA (at least in how I see it). Devs write tests, not QA and there is no need to have many (if any) dedicated testers. Still, in bigger organizations, having a few "experts" in testing is useful mostly so that they can "teach" devs how to bake quality into a product from the start. Their involvement with product teams is to ensure something through know-how, rather than to do something. Similarly, SREs are not (or should not) be in charge of deploying anything, but keeping prod. systems healthy and helping others create products that will not mess up everything.
Nevertheless, all that applies to larger orgs. In smaller companies, roles are often mixed and we all do what needs to be done so there is nothing wrong if an SRE works on, let's say, a staging environment.
SRE (Site-Reliability-Engineering) vs. DevOps (DevelopmentOperations) ... sounds like the old mantra as Eric Raymond has described it in his famous paper "The Cathedral & the Bazar" ...
SRE as the old school Cathedral following its traditional waterfall-development-cycle ... vs. ... DevOps as the Bazar following the new mantra "release early, release often!" ...
Adressing the systemic failure mechanism that it is impossible to avoid software bugs ... so make all the early adopters out there in the open source community part of your test strategy ... ;-)
Interesting analagy and I agree to some extent. In my opinion; and where we kind of agree, SRE is the first step to adopting agile as corporations shift from years of having silos between I&O and service delivery and cannot fully grasp how to change to DevOps (culturally and organizationaly). Most companies adopt "DevOps" teams (they miss the point of DevOps) and the teams somewhat resemble SRE. Rarely do they ever fully shift to Devops (culture and organization)
General terms maybe. Yet many organizations it’s software engineering experts that understand systems. Expert in all of them. I’d thing more SREs start in software and shift right initially and then shift back left later after automation is built. Devops is a practice for everyone including SREs. SRE is an actual job
You're right that it is more common for SREs to start in software than in operations. Both types of experience are required but it seems to be easier for a dev to jump into ops than the other way around.
P.S. That was a generalization that does not apply to all, but is based on my limited experience and observation :)
first
nice