Insights from DevOps Institute Ambassadors
SRE Does Not Replace DevOps
“DevOps and SRE are a “marriage made in heaven”, complement each other, and in no way does SRE replace DevOps. While the DevOps best practices and cultural movement joins the development team with the operations team to produce, test, and deliver quality software at a much faster pace, SRE joins operations with software developers and engineers to maintain high-performing hardware and software systems. In essence, DevOps = Collaboration to produce feature-rich software fast and with fewer errors, SRE = Collaboration to automate functions that focus on SLOs and maintain the highest level of uptime possible.”
DevOps and SRE are Better Together
“They are so closely related, hand in hand, actually. While DevOps seems older, Google codified SRE a bit earlier; they just didn’t release it to the masses until a few years after the DevOps movement had spawned. They have so much in common but some subtle differences. Where DevOps seeks to balance throughput with stability, SRE focuses on reliability. An SRE is a role, DevOps is a cross-enterprise movement. SRE focuses on the ‘wisdom in production’; DevOps concerns itself with the end-to-end value stream. They both are obsessed with metrics, but DevOps is a bit more interested in things like cycle time, deployment frequency, and change fail rates; SRE is centered around SLAs, SLOs, and SLIs and managing them through error budgets. They might be different from each other, but they are certainly not mutually exclusive; indeed, they are both better, together.”
Implementing DevOps and SRE is a Journey–Not a Quick Fix
“In many ways, DevOps and SRE sit, in both practice and philosophy, very close to each other in the overall landscape of IT operations. Both DevOps and SRE require discussion, management support, and buy-in from the people actually doing the work to make serious progress. Implementing either of them is a journey and not a quick fix: the practice of rename-and-shame is a hollow one, unlikely to yield benefit. Given that it is a more opinionated implementation of how to perform operations, SRE has more concrete suggestions on how to change your work practices earlier on in that journey, albeit requiring specific adaptation. DevOps, having a wider focus, is somewhat more difficult to reason about and translate into concrete steps, but precisely because of that wider focus, is likely to meet with weaker initial resistance. But practitioners of each use many of the same tools, the same approaches to change management, and the same data-based decision-making mindset. At the end of the day, we all face the same persistent problem: production and making it better—no matter what we’re called.”
DevOps and SRE are Interdependent
“For me, both SRE and DevOps are part of the cultural continuum that defines modern engineering practices. It is important to enable and optimize the feedback loops of excellence which SRE covers extremely well. In a way, DevOps and SRE are interdependent; SRE would have a hard time executing its vision without DevOps, and DevOps capacity to deliver clear results in some aspects is accelerated immensely by SRE.”
DevOps and SRE Defined
“DevOps is a set of practices that help organizations increase business agility by improving the relationship between operations and development teams and allowing these teams to work in a more integrated way. DevOps practices affect the organization’s culture, breaking down silos and enabling teams to deliver business value through rapid and quality service delivery. Site Reliability Engineering is a prescriptive software engineering approach to execute and measure DevOps practices within an organization. SRE emphasizes the stability of the production environment of IT systems, but at the same time, ensures the deployment of new features in a balanced way. SRE leverages software to manage IT systems, prescribes a method for measuring these IT systems, and eliminates repetitive, tactical work with no value, also known as toil.”
Growing SRE Chops is a Continuous Journey
“To me, Site Reliability Engineering (SRE) is a skill set that ALL developers on a product team/squad who are developing software using CI/CD and monitoring can continuously grow. There are a variety of ways to upskill too. Pairing, sharing, and tapping into external learning opportunities are some ways. The DevOps Institute is a great resource for external learning. A good starting point is their Site Reliability Engineering Foundational certification. Through the Institute, you can also collaborate with people all over the globe who are on the SRE journey. Growing SRE chops is a continuous journey because the more the skill set is applied in different contexts, the more is learned. New solutions emerge, and SRE evolves. Enterprises that are on a DevOps cultural journey can accelerate learning by growing SRE on teams/squads that develop software using CI/CD with continuous monitoring.”
DevOps and SRE are Irrefutably Intertwined
“DevOps and SRE are irrefutably intertwined. I will spare the technicalities of the similarities and differences between the two practices as there is an abundance of related literature on that topic. Instead, I will adopt a different tract to illustrate the relationship by way of an analogy.
DevOps is like a tree, and SRE is the ground in which a magnificent tree is embedded in. They add value to one another in that ecosystem. SRE, if done well, will support and nourish DevOps practices, enabling them to grow from strength to strength. And as DevOps practices mature, it will grow and anchor its roots into the ground, making the ground ever more compact and stable. You see, the two are not separate practices that are mutually exclusive but reinforces each other. Both practices will dovetail in an eternal tango.
One more thing. As a parting reminder, both the tree (DevOps) and the ground (SRE) require the right weather and climate for them to thrive and support each other. Right weather, right climate. And that, dear reader, is the right culture!”
DevOps and SRE Must Work Together
”DevOps and SRE are not exclusive; they are inclusive and must work together. Good advice to companies who want to provide products with velocity, quality and lower cost of rework, is to apply techniques and cultures based on DevOps principles. For instance, CALMS, the Three Ways, and automating operational tasks that could impact the results of ROI. This improves and consolidates the best UX and CX while not forgetting to provide the best Development Experience (DX) to the development team. The SRE, normally, is focused on the Total Experience (TX) maintaining and continuing to improve the CX based on best practices and metrics provided by using SLIs, SLOs, SLAs and Observability techniques that they could give an aggregated value to the entire product development flow reducing the lack of competitiveness in the market due to the customer satisfaction and loyalty.
Based on that we can assure that DevOps teams are interested in how to reduce the time of delivery by practicing shift-right / shift-left, and the SRE is focused on problem solving and how to continuously improve the tomorrow–always interested and looking to the customer-centricity.”
Getting to Know SRE and DevOps
Maciej Jarosz, Poland
“This is but an opinion, not a dogma in any way so let’s go: DevOps being a philosophy, culture and also, why not, a set of blueprints on how to introduce, evolve and sustain your DevOps implementation (as per one interesting book that’s available out there), is quite a broad field, which we can compare to an open-source garden, where everyone can come, plant their ideas, nurture them, weed out those outdated or invalid ones all the while being a part of a community of people who do the same at mostly the same time.
Which is great. Even the marketing and sales part of different vendors, as long as it’s ethical and not set up to destroy your competition. It’s a technological arms race, which produces lots if not tons of splendid technologies, be it mobile applications, full-blown software for the enterprise, some new programming languages, etc., which all distills into how we as humans interface with technology.
SRE on the other hand, as far as I see it, is a particular subset of DevOps created by Google people for Google purposes, yet some concepts, ideas, and practices are universal (and brilliant, to be honest) enough that others may also use them. Like SLE – it’s universal, even if you do not yet possess advanced monitoring and observability command center (or maybe you’ll never ever need one) you can still use the concept and tweak it to serve your business.
I’d say, at least get to know both, take whatever you think will work for you, experiment, share, exchange information with others – that’s the beauty of DevOps.”