SRE vs DevOps
We often hear SRE and DevOps interchangeably used to describe operational activities done by engineers for applications running in private or public cloud environments. What’s the difference?
DevOps was coined by Patrick Debois in 2009 to describe the culture of having developers and operations engineers work together. There was a constant conflict between developers who build the software and IT operations teams that manage the day to day operations of the software. It was often referred to as developers throwing software “over the wall” to operations.
DevOps brought a change to this culture that brings the responsibility of building and running software to both dev and ops, with increasing collaboration and shared responsibility across various aspects of software development life cycle (code, build, test, deploy and management)
“DevOps is not a process or a technology. It’s a philosophy or culture of having developers and operations work together to achieve the common goal of running software to achieve high performance and high availability.”
Site Reliability Engineering
The field of site reliability engineering (SRE) originated at Google with Ben Treynor Sloss, who founded a site reliability team after joining the company in 2003. The Google SRE books have formalized many of the ideas that are developed in these site reliability teams since then.
Unlike DevOps, SRE is both a job function and a set of principles that are followed by a team to achieve high reliability for software services offered by a company to its customers. SRE also brought engineering principles of writing “infrastructure-as-code”, testing and deploying operational software similar to how product services are developed.
“SREs are software engineers doing operational work!”
Though SRE predates DevOps, it’s an implementation of DevOps principles in a specific manner. Automation plays an important role in SRE.
Fylamynt is an SRE platform that helps SREs build and run automation workflows.