Differences between Site Reliability Engineer Vs. Software Engineer Vs. Cloud Engineer Vs. DevOps Engineer

Introduction

As the IT field has evolved over the years, different job roles have emerged leading to confusion over the differences between Site Reliability Engineer Vs. Software Engineer Vs. Cloud Engineer Vs. DevOps Engineer. For some people, they all seem similar, but in reality, they are somewhat different. The main idea behind all these terms is to bridge the gap between the development and operation teams. Even though these roles are correlated, what makes them different is the scope of the role. In this blog, we are going to explore that difference.

What is Software Engineering?

The traditional role of a software engineer is to apply the principle of engineering to software development. This includes the use of programming language to create, analyze and modify the existing software and design and test the user application. A person doing the job of software engineer usually has a bachelor's degree in science or software engineering and has experience in computer systems and languages like Python or C or Go or JavaScript, etc. This is how the typical day of a software engineer looks like:

• Analyze the user requirement
• Do coding based on those requirements
• Perform maintenance tasks and integrate the application with the existing system
• Doing Proof of Concept(POC) on new technology before implementing it
• Executing and developing the project plan

So at a high-level a software engineer’s role is to architect applications, develop code, and have processes in place to create solutions for customers.

Now you understand who is a software engineer and what their role is. In the next section, let's try to understand the difference between Software vs. DevOps engineers.

Software Engineer vs DevOps

Back in the day, Software Engineers and Operations had a lot of contention. Software Engineers pass their code to the system admin, and it's the system admin's responsibility to keep that code running in production. The Software Engineer had little knowledge of the operation practices, and System Admin had little knowledge about the codebase. Software Engineers were concerned with shipping code, and System Admin was concerned about reliability. On the one hand, Software Engineers want to move faster to get their features out more quickly, whereas System Admin, on the other hand, wants to drive slower to keep things reliable. This kind of misalignment often caused tension within the organization.

Here enters DevOps, a set of practices and a culture designed to break down these barriers between Software engineers, System Admin and other parts of the organization. DevOps is made of two words of Dev and Ops, namely Development and Operations, and it's the practice to allow the single team to manage the entire application development lifecycle, that is, development, testing, deployment, monitoring and operation. They achieve that by frequently releasing small changes by using continuous integration and continuous deployment.

For more info about continuous integration and continuous delivery, please refer to:

https://en.wikipedia.org/wiki/Continuous_integration

https://en.wikipedia.org/wiki/Continuous_delivery

DevOps is broken down into five main areas:

• Reduce Organization Silos: By breaking down barriers across teams, we can increase collaboration and throughput.
• Accept failure as normal: Computers are inherently unreliable, so we can't expect perfection, and when we introduce humans into the system, we can expect more imperfection.
• Implement gradual changes: Not only are small incremental changes easier to review, but if a gradual change introduces a bug in production, it allows us to reduce the mean time to recover and make it simple to roll back.
• Leverage tooling and automation: Reduce the manual work by automating as much as possible.
• Measure everything: Measurement is a critical gauge for success, and without a way to measure if our first four pillars were successful, we would have no way of knowing if they were.

DevOps vs SRE

If we think of DevOps as a philosophy, Site Reliability Engineering(SRE) is a prescriptive way of accomplishing that philosophy. So if DevOps were an interface in a programming language, then SRE is a concrete class that implements DevOps. In DevOps, when we talk about eliminating organization silos, SRE shares ownership of production with developers. SRE uses the same tools as DevOps to ensure everyone has the same view and exact approach to working in production. SRE has a blameless postmortem in accepting incidents and failure, which ensures that the failure that happens in production doesn't have to be the same way more than once. SRE accepts the failures as normal by encoding a concept of an error budget of how much system is allowed to go out of spec. SRE follows the philosophy of Canary release in terms of gradual changes, where the release changes only a small percentage of the fleet before it's been moved to all the users. In terms of tooling and automation, the main idea is to eliminate manual work as much as possible. For measuring everything, SRE measures the health and reliability of the system.

As an SRE, you must have a strong background in coding, but you should have the basics covered on Linux, Kernel, Network, and computer science.

To sum up, SRE and DevOps are not two competing methods but close friends designed to break down organizational barriers to deliver better and faster software. Both of them intend to keep the application up and running so that the user is not impacted. On the one hand, SRE is more applicable to production environments (as it's the combination of software engineering plus system admin). In contrast, DevOps is more for non-production environments (sometimes in production). Their main task is to keep the environment up and running and automate as much as possible.

For more info, please refer to the following link:

https://sre.google/workbook/how-sre-relates/

What skills does DevOps or SRE Need?

These are some of the technical skills companies are looking for when hiring DevOps or SRE.

• Operating System Fundamentals: This mainly includes Linux as most of the server market is dominated by Linux(Only a handful of companies use Windows as a server in the production environment).
• Programming Skills: This is one of the must-have skills as you want to automate as much as possible, and the only way you can achieve that is using a programming language. Most engineers use Python or Shell for automation, but where speed is the key, GO language is the ultimate choice.
• Networking Knowledge: As most companies migrate to the cloud and most of the heavy lifting is done by the cloud provider, you should have basic networking knowledge.
• Cloud Knowledge: As mentioned earlier, as most companies migrate to the cloud, you should be familiar with at least one cloud provider like AWS, GCP, or Azure.
• Standard Tools: This is job-specific, but with the current industry trend, you should be familiar with all the modern DevOps tools like GIT, Jenkins, Docker, Kubernetes, Terraform, and the list goes on and on. As mentioned earlier, this is job-specific and depends upon the current project requirement and scope.

So in the modern context, an SRE/DevOps engineer is a software engineer whose focus area is infrastructure and operations. They take care of the operational tasks and automate it, which in the past was taken care of by the operations team, often manually.

Cloud Engineer

SRE and DevOps is standard practice, whereas the Cloud Engineer role is specific to the cloud, e.g., AWS, Google Cloud, Azure, etc. Cloud Engineer role is delivery and optimization of IT service and workload running in the cloud. The advantages of using cloud in your organization are:

• Cost: As the number of public cloud providers increases and with the cutthroat competition, the organization benefits from it as all cloud providers try to slash their offering prices to compete.
• Maintenance: Also, the companies using the cloud need not worry about maintaining an expensive onsite network or system architecture. Instead, they can collaborate with the cloud service provider to get support for all servers and networking needs.
• Scalability: Using the cloud has other advantages like getting infinite storage and processing power; but obviously, it incurs costs.

Cloud Engineer roles can be specific to architecting (designing cloud solutions), administration (making sure the system is up and running all the time), or development (coding to automate cloud resources). Some of the responsibilities of a Cloud Engineer will be:

• Migrate on-premise application to the cloud
• Configuration of resources and components like security, databases, servers, etc.
• Deploying the application in the cloud.
• Monitoring the application in the cloud.

Types of Cloud Engineers

There are three main types of cloud engineers:

• Solution Architect: The role of Solution Architect is responsible for migrating organization applications to the cloud. They are responsible for the design and deployment of cloud applications and cost optimization.
• Cloud Developers: Cloud developer is responsible for developing a cloud-native in the cloud. They are responsible for developing, deploying, and debugging applications in the cloud.
• SysOps Engineer: SysOps engineer role is similar to the system administrator, and they are responsible for deploying and maintaining the application in the cloud.

A cloud engineer needs to combine SRE/DevOps/Software engineer in an ideal situation but specialize in Cloud Services. But in reality, there is still a skill shortage in the cloud field. Cloud Engineers specialize in one area, either they are good developers, or they know cloud services well. Due to this hindrance and skill shortage, some companies resist moving to the cloud and still have the workload running in the on-premise data center. The only way to fill this gap is for companies to train their employees in all aspects. Cloud engineers need to grasp programming skills and vice-versa.

Wrapping Up

Whatever practice you are following in your organization, the main idea is to break the silos, increase collaboration and increase transparency. Any practice you are following needs to find an innovative way to develop better and reliable software. As the IT field progresses, these practices will continue to evolve, and new roles will be born.

Squadcast is an incident management tool that’s purpose-built for SRE. Your team can get rid of unwanted alerts, receive relevant notifications, work in collaboration using the virtual incident war rooms, and use automated tools like runbooks to eliminate toil. Start now for Free.