Insights for Organisations

SRE Vs DevOps: The Best Solution for Your Business

Paul Brown
04.01.23

In the last few years DevOps has disrupted the software development lifecycle. According to a recent report, the global DevOps market was valued at USD 6.78 billion in 2020 and is projected to grow to USD 57.90 billion by 2030. The figure highlights the growing demand for DevOps as a means for businesses to optimise the time to market for new products and services, whilst ensuring greater stability of operations, and safer business continuity.

DevOps facilitates collaboration and communication between developers and the operations team where building, testing and releasing software can happen rapidly and reliably. Under a DevOps model, companies can:

  1. Reduce organisation silos
  2. Accept failure as a natural part of the process
  3. Implement gradual change
  4. Leverage tooling and automation
  5. Measure everything

Site Reliability Engineering (SRE) SRE evolved independently from DevOps as a means to build, maintain and run production systems at scale. SRE deals with implementing the product developed by the development team while reducing the level of incidents and improving stability and reliability. The 2022 LinkedIn Jobs on the Rise list includes SRE among the 25 fastest-growing job titles with the highest global demand throughout the past five years. It appears the SRE practice will continue to gain adoption as a method to support higher availability, reliability and improved digital customer experiences.

Seth Vargo (Developer Advocate at Google) and Liz Fong-Jones (Site Reliability Engineer at Google) provide an interesting insight on the SRE vs DevOps debate: ‘if DevOps is a philosophy, SRE is a prescriptive way of accomplishing that philosophy’.

But is there a difference between the two? Let’s find out.

Difference between DevOps and SRE

Whilst there are some overlaps in job roles within DevOps and SRE, there are differences in some key functions. Here are four main distinctions between DevOps and SRE:

1. Objective

The primary objective of DevOps is product development with Continuous Integration/Continuous Delivery (CI/CD) and to ensure timely release. Developers wants to build features and products and ship them as quickly as possible to customers. However, SRE’s main objective is the system’s stability and reliability. Operators are responsible for the system not going down. So, in this sense DevOps and SRE are two opposing ideas. Developers want to move fast, whilst operators move slowly.

2. DevOps focuses on ‘What’, SRE focuses on ‘How’

Seth Vargo explains, ‘DevOps is like an abstract class or interface in programming whereas SRE is a concrete implementation of that class.’ DevOps provides a list of ‘what’ needs to be done whereas SRE demonstrates ‘how’ to implement them.

For example – reducing organisation silos is one of the five pillars in the DevOps model. However, SRE shows us how to achieve this. Site Reliability Engineers reduce organisation silos by sharing ownership with developers by using the same shared set of tooling across the organisation. By leveraging a single set of tools for production systems we have software developers and SREs contributing at the same time and you can start building high-performance, reliable tooling that facilitates project completion.

3. Team structure

DevOps teams typically comprise of a group of professionals with very specific and pre-defined roles like – product owner, software developer, release manager, QA Engineer etc. On the other hand, SRE teams are made up of engineers who have a combination of operational and development skills.

4. Process Flow

A DevOps team has a perspective of the development environment to put changes from development to production. On the other hand, SREs have a perspective of production, so they can make suggestions to the development team to limit the failure rates despite the new changes.

FDM’s DevOps training programme

The FDM DevOps programme is an 11-week course comprising carefully designed modules that target specific areas of learning in the code, build, test, release, deploy, operate and monitor pipeline. The course is intended to provide comprehensive training in the methodologies, principles and strategies of DevOps.

The FDM DevOps programme is split across nine modules, each covering a key functionality under the broader remit of DevOps. These include:

  1. Professional Skills – a combination of key professional skills including report writing and presentation skills, written and verbal communications and the fundamentals of collaboration and teamwork. The foundation module also introduces GDPR (General Data Protection Regulation) and Cyber Security – both critical elements of a DevOps project.
  2. SQL
  3. UNIX
  4. Agile/ Scrum
  5. Software development
  6. Automation testing
  7. Infrastructure and cloud technologies
  8. IT operations and information security
  9. DevOps and CICD

Consultant Insight

Xavier Vella is an FDM consultant presently placed with a large Australian Financial Services institution. Speaking of his experience within the DevOps space, he says:

‘Currently working with a large financial services client, I see DevOps as the most integral cog in the technology space – maintaining a healthy platform through monitoring and analysing data, automating processes and clear communication allows for a consistent approach to collaboration across the business. Since starting my placement, I have gained exposure to large scale cloud platforms and DevOps tools such as Google Cloud Platform, Kubernetes, Kong, New Relic, Terraform, CodeFresh and more recently Istio. I look forward to further advancements in the space and continuing to play an important role in software development and deployment.’

To Sum Up

The main difference between DevOps and SRE is the difference in focus. Whilst the primary concern for DevOps is delivery speed, SRE focuses on reliability. However, Class SRE implements DevOps. As Seth Vargo and Liz Fong-Jones explain: “DevOps and SRE aren’t two competing methods, but rather close friends designed help break down organizational barriers to deliver better software faster.”