If you want more content like this, subscribe to my YouTube channel! youtube.com/clouddevengineering

Titles in the engineering space are a funny thing. They're important, but they're not important. The importance of a title comes from the salary/job you can get, for example, someone with a DevOps Engineer title gets paid pretty well. However, the title doesn't mean the person with "DevOps Engineer" on their resume is any smarter or more advanced than someone with "systems administrator" or "systems engineer" on their resume.

The point is, titles are an odd form of justification.

Arguably the oddest one of all is DevOps Engineer vs Site Reliability Engineer (SRE).

What are the differences? Is one better than the other? What does it all actually mean?

In this blog post, you'll learn about the differences between SRE and DevOps.

Title Janga

Titles are like Janga. Constantly changing, evolving, and the playing field is always being altered. One wrong move and we'll have ourselves a DevGitSecurityKubernetesDockerNetworkingCloudTerraform Engineer.

The hottest titles right now to have on your resume are DevOps Engineer and SRE. Why? Because it's what the world thinks, or appears to think that they need right now.

When you break it down and read between the lines, a company is typically looking for:

• Cloud experience
• CICD experience
• Some container and orchestration experience
• Infrastructure-as-Code/Configuration Management experience
• Scripting experience
• Monitoring and troubleshooting experience

When you look at the list above, you may be thinking to yourself wow, that's a lot. The answer is yep, it is.

The reason why is because being an SRE or a DevOps engineer isn't an entry-level position. It takes years to collect all of the skills needed and to use them the proper way.

The idea is to break down the job description and not care about the title. If you see an SRE role that looks more like a Systems Administrator, it's probably not the best environment to be in. Don't be fooled by the titles.

The SRE

You'll hear debates about this topic a lot in the SRE space - should we follow Google's definition of an SRE?

The answer is yes for a few reasons:

• Google created the SRE, which means they definitely know what the role should be.
• Google has constantly strived for perfection from the SRE role and has succeeded.
• The definition is really spot on and it works.

So, what's an SRE?

An SRE is someone who thinks about infrastructure from the lens of a Software Engineer/Developer.

In the not too long ago past, developers cared about getting features out and shipping code, whereas infrastructure people cared about keeping the systems stable. The two biggest fights amongst the groups were the systems only have issues when new code is introduced and the systems can't handle the new code changes.

These were all valid arguments because both were true. With that, the SRE title was born.

An SRE is someone who understands the infrastructure all the way down to the operating system bits. They know how systems work and how to keep them efficient. They have to know that stuff because code runs on those systems, and the only way for code to run efficiently is by having systems that are up and operational.

Systems can be anything from bare metal to virtual machines to EC2 instances in AWS to virtual machines in Azure to Kubernetes to Serverless services in any public cloud. A system is anywhere that code is running.

A few key job responsibilities of an SRE are:

• Monitoring systems
• Monitoring application performance
• Fixing on-call issues that may occur. This means figuring out why the issue occurred and fix it.
• Conduct blameless post mortems
• Write code for automation and create internal tools primarily in Python, Go, and using Infrastructure-as-Code.
• All of the DevOps duties (CICD, automation, etc.). The idea is to use automation to make everything repeatable.

The DevOps Engineer

In the previous section, The SRE, you probably thought to yourself a lot of that overlaps with what DevOps is, and you're absolutely correct.

With that being said, what is DevOps?

DevOps is a subset of SRE. They typically do a fraction of what an SRE does (in an organization that's using the SRE title properly).

A DevOps Engineer is typically someone that's hired to do a lot of CICD, deploy code, and automate system creation. The unfortunate thing about a DevOps Engineer is that they're typically on a completely separate team than the developers.

The question becomes so how do they know anything about the code they're deploying?

That's a battle that many hardcore engineers and developers have constantly. Pretty much what it comes down to is the simple fact that there are a lot of tools on the DevOps tool belt and a lot of developers are there to write code and plan the way an application will look. They really don't have the time to also handle the 10-15 different DevOps-related tools. Because of that, is why we have the DevOps Engineer title today.

A few key job responsibilities of a DevOps engineer are:

• CICD
• Infrastructure-as-Code
• Automation
• Cloud management
• Scripting

What Direction Should You Go In?

The question of which direction you should go in is one that no one can answer for you, but there's a pretty easy way to find out which.

The answer is simple - don't put too much emphasis on the title when you're searching.

What you want to do is look at the job description. Why? Because the hiring world is extremely confused right now about what an SRE or a DevOps Engineer actually is. There's no definition that everyone is following, which is why you'll see job descriptions that are completely different from one another.

What you should really be doing is look at the job description and see if it lines up with what you want to be doing and what will be beneficial for your career. If the title is DevOps, cool. If the title is SRE, cool. It doesn't really matter because when you're looking for a new job or to go out on your own and consult, no one really cares about the title you had. They care about the job responsibilities you've done.

Interested in learning more? Check out how you can contact me for consulting and advisory services! https://michaellevan.net/advisory_services/