Generally, to complete a task, you need to know what needs to be done, and also how it has to be done. But which is more important? It’s a bit like that age-old question – “Which came first, the chicken or the egg?”
There’s an equal and opposite argument for both options, and each option needs the other to exist – this is the same concept when you’re talking about DevOps VS SRE.
DevOps and Site Reliability Engineering (SRE) have been co-existing within the software development industry for more than a decade. Externally, they may appear like competitors, where you have to choose one or the other but that’s simply not the case at all. Instead of being rivals, they’re actually two sides of the same coin, a ying and yang style arrangement where they fit in nicely together to make up a whole.
Both DevOps and SRE share the same function of improving the development and release cycles without compromising quality or efficiency, and to be that kind of link or bridge between the development team and the operations team.
Strangely, most companies will see the need for either DevOps or SRE, aware that there is a pretty big overlap in duties and ability between the two. More modern companies will let DevOps and SRE work concurrently, cognizant of the fact that both are integral to the software development process.
What is DevOps?
Before DevOps, the development and operation teams were completely separate and non-interacting entities. Their work processes, goals, and milestones were different, and the lack of communication really hampered the software release timeframe, as well as the quality of the end product. Naturally, this was neither ideal for the company, nor the users buying or operating the software.
Then DevOps happened in 2008. Co-founder Patrick Debois had become frustrated at the constant conflicts between developers and system admins during his time at the Belgian Government, and sought out solutions. Developers would write code with no clue how it would run in production. He attended the Agile Conference, where he was the only attendee at the “bird of a feather” conference presented by software developer Andrew Shafer. The two hit it off and had an in-depth conversation in the hallway, deciding to form the Agile Systems Administration Group which would eventually come up with the DevOps concept – and the rest is history.
The official definition is “a software engineering culture and practice that aims at unifying software development and software operation.” In layman’s terms, DevOps is a cultural shift within the company itself. It’s a focus on what needs to be done as a series of outcomes in order to achieve an efficient and fast flowing development process that merges seamlessly into testing, and eventually into operations. During this macro process, security and reliability is maintained during the transition from the development team to the operations team.
The philosophy is that the teams themselves share responsibilities for both code writing and maintenance, that production is much more efficient when there is less of a flat handover and more of an active role for both. DevOps is a mindset, a culture that breeds collaboration – applying engineering principles to operational tasks. The start to finish life cycle of app development is one continuous process, with post deployment monitoring feeding back into the development cycle.
What is SRE?
Same same, but different. Like DevOps, the aim of SRE is to bridge the gap between the development and operations teams – but it focuses on the how, not on the what. The concept of site reliability engineering has been around a lot longer than DevOps, and works best when deployed as a concurrent system working in parallel to DevOps.
SRE first originated over at Google – one of the big 4 tech companies who are leaders in innovation and trend setters in the tech industry. Benjamin Treynor was a software engineer who found himself in charge of a production team, tasked with ensuring that Google’s websites were available, reliable, and as serviceable as possible. His first order of business was to direct his team of seven to spend half their time working on operations-based tasks so they could get a better appreciation of the software production side of things. This overlapping of responsibilities across the two teams was the foundation of Google’s Site Reliability Team, and the basis for SRE.
As a basic definition, SRE is an approach that brings a software engineering mindset to system administration tasks. The end goal is to reduce the time it takes for a developer to commit to a change, to when it’s deployed in production – while not compromising the quality of the code at the same time.
It’s a software first approach to IT operations, framed by a set of practices that increase system reliability – the most fundamental feature of any application or product. Only when a system is reliable enough, will new features or add-ons be rolled out. There is a great emphasis on tracking results, making discernible improvements on the app’s performance, and automating as many operational tasks as possible.
HOW ARE DEVOPS AND SRE SIMILAR?
So, DevOps and SRE are like two friends working together to break down the barriers between the software development team, and the production and deployment team. Ask anyone alive during the 60’s and they’ll tell you “make love not war.”
Both methodologies combine development and operations teams by educating each in what the other does, creating overlapping responsibilities so that everyone is on the same page. By doing this, there is visibility on both sides as to what the entire lifecycle of an application looks like.
The goals of DevOps and SRE are automation and monitoring. Where manual work can be taken out of the equation, it’s replaced with efficient code. After an app has been deployed, a continual monitoring process feeds information back into the development process to fuel updates, bug fixes, and any features that need to be added onto the main product that will enhance the user experience.
HOW ARE DEVOPS AND SRE DIFFERENT?
In a nutshell, DevOps focuses on continuity between the development and operations teams, and the speed of the product delivery schedule. Where SRE prioritizes system availability and reliability by overlapping responsibilities between the two teams. DevOps has this mindset, this team culture that encourages collaboration instead of an “us versus them” mentality and is about attitudes and how teams work together. SRE focuses on using metrics to measure reliability, and sharing the same tools and techniques between the teams to reduce tension and conflict between the two groups.
If DevOps is the what, then SRE is the how. Where the DevOps philosophy identifies areas that need changing in order to streamline the software development and deployment process, SRE offers the solutions to get it done.
HOW DO THE ROLES DEVOPS ENGINEER AND SITE RELIABILITY ENGINEER DIFFER IN THEIR RESPONSIBILITIES?
A DevOps Engineer has to maintain the 5 pillars of the DevOps movement, while a Site Reliability Engineer needs to introduce the corresponding SRE practices that are required to make it happen.
Reducing operational silos using DevOps is something that can help a large company that has a complex organizational structure – the product will fail if teams are pulling it in different directions and not communicating as a whole. SRE comes in by sharing the responsibility for success and failure equally amongst the teams, and ensuring they use the same tools in development and operation.
The DevOps concept of accepting failure as normal is a coping mechanism, acknowledging that something will fail as an unavoidable inevitability can be used as a catalyst for teams to learn and grow. SRE aims to solve the problems as early as possible, and lowers the target down from 100% reliability, to an acceptable margin for errors and bugs.
A DevOps Engineer will implement gradual change, as companies want to develop software faster, release more frequently, and continually improve their product with new features to keep up with technological advancement. An SRE will balance reliability and the ability to rapidly update, using version rollbacks to combat with bugs in the new code that affect the user experience.
The DevOps Engineer will look to add as many automation tools to the overall process as possible – granted they add value to the development and operations teams by removing manual or menial tasks. The SRE supports this by identifying the manual work tasks that are taking up over 50% of a software engineer’s time, eliminating work bit by bit and reflecting that in their set of processes.
As this automated workflow increases speed, it also increases the possibility of errors. As such, a DevOps Engineer will need to measure everything to make sure the product is heading in the right direction. An SRE will look at it from the angle that operations is a software problem, and as such, things like availability, uptime, outages etc will need to be measured at every organizational level.
So, as it turns out, DevOps and SRE are not so different. Instead of being opposing software development methodologies, the mindsets can actually work in tandem to combine the development and operation teams by sharing responsibilities and focusing on automation and reliability.
The end result is an applications workflow that is no longer fragmented, but one continuous loop feeding back into itself. It’s all about the data, how success can be measured and replicated, and how failure can be used as a way to improve the overall quality of the product.
Salaries for DevOps Engineers vs. SREs
A DevOps Engineer overseeing continuous and rapid application deployment can expect to earn $99,600 as an average salary, where a Site Reliability Engineer charged with developing and managing system documentation can expect to earn roughly 15% more – averaging $117,530 per year.
That’s a pretty sizeable difference in salaries!
Next Steps
We hope this article helped you learn more about DevOps and SREs and where their responsibilities and roles overlap and diverge.
If you enjoyed this article you may also enjoy Computer Science vs Dev Boot Camp: Which One Should You Choose? or Microservices Explained in 10 Minutes.
Kofi Group offers a multitude of resources to help you learn more, improve your career, and help startups hire the best talent. If you are interested in learning more get in touch today!