Site Reliability Engineering and Release Engineering

Site Reliability Engineering focuses on running services reliably. It emerged from Google and has garnered attention rightfully as a fundamental discipline in operating and designing systems to run complex software machinery reliably. It provides tactics and embraces software engineering philosophy in a world traditionally looked upon as system administration. It’s transformed the world of DevOps by bringing software engineering into system operations, understanding risk and creating service metrics.

Site Reliability Engineering differs from Release Engineering heavily in that the former applies to infrastructure and operations of the software while the latter’s goal is to ship software in a reliable and repeatable process. While some principles carry over across these sub-disciplines, they solve fundamentally different problems.

While topics such as toil and automation suit perfectly, monitoring and establishing service level objectives with end users and customers don’t find their home as neatly here.

At a high level, Site Reliability Engineering makes software-based services more resilient. Release Engineering on the other hand solves how a product ships in the hands of users.

If you'd like to learn more about Site Reliability Engineering, read Google's excellent Site Reliability Engineering book.

At Tanzu, we teach and employ Site Reliability Engineering principles for our live services. Our Release Engineering practices are also inspired by some of the SRE principles, but it’s worth noting that they are used at two fundamental points in the lifecycle of software.

As we’ll further explore, the goal is for release engineers to rely on automated services to further the processes from building to compiling to testing and to release, and each of these phases comprise of numerous services that in themselves, are encouraged to employ SRE principles. The user in this case may not be the end user and availability metrics may not need to be as high as 99.99%, but keeping these frameworks in mind for each slice of service in release engineering is useful in its own right.