I always worry a bit when I hear people repeat Google’s famous statement that “class SRE implements DevOps“. It’s not that I think it’s wrong. I certainly agree that the way Google describe SRE makes it sound very much aligned to the objectives of DevOps. What I worry about is that (as I’ve witnessed) sometimes people misinterpret this to mean they are identical. The danger of doing this is that people and organisations may close themselves off to the transformative potential of applying the valuable processes and approaches emphasised in SRE.
I’ve seen a lot of “DevOps” initiatives very busy with the Dev side of DevOps i.e. CI/CD pipelines and environment automation, but often with much less attention on Operational concerns i.e. Operability, Reliability, Resilience, Service Management, Observability. I’ve seen SRE implementations to be very effective at specifically addressing these residual problems.
I think it is true that the SRE body of knowledge contains a lot of valuable advice that is very relevant to implementing DevOps. I agree that fundamentally they are trying to achieve exactly the same outcomes i.e. sustainably great IT that can enable great businesses. I agree that for organisations heavily invested in implementing DevOps one way or other it would be very unhelpful to ignore that, duplicate that, or in any way deprecate or disparage that. BUT there are also certain potential advantages to treating SRE differently within the context of a specific company/enterprise, such as:
- It may create a renewed amount of focus on the Ops side of DevOps.
- If starting in traditional Operations teams (by measuring SLIs, TOIL, etc.) it may be possible to deliver improvements (at least in terms of situational awareness) without having to impact inflight DevOps work (which may be CI/CD focused).
- SRE practices are agnostic of tools, technology, Continuous Delivery maturity etc., so this may be an opportunity to affect those systems that may so far not been the focus of your DevOps efforts. For example a lot of DevOps attention has been on custom code whilst Digital and harder to reach systems (COTS products, Mainframe, Core mission critical platforms etc.) may still be waiting in line.
- If the DevOps initiatives in flight are currently heavily focused on Tools-as-a-Service, SRE may present an opportunity to take a fresh and complimentary approach.
So overall yes, understood correctly Google’s famous statement is true. But if your DevOps instantiation does happen to be a little on the side of big DEV, small ops, and you aren’t quite yet continuously deploying unicorns… I recommend putting some fresh and possibly even separate, highly operation, reliability, and technical debt -focused energy into trying out more ideas from SRE.