Agree as to this opposition of sorts. It further extends to agile methodologies, such as Scaled Agile, which were founded on the software release cycle as a primary organizing principle. SRE is better aligned with operations ("Business As Usual" / reliability - resilience engineering in some enterprises). Agile is a square peg in a round hole for analytics, after-action reviews, troubleshooting, even design engineering - because, to phrase it clumsily, the dimensions of solution spaces are still to be determined, Once better understood, once decisions needed have been identified, agile processes can be employed to remediate, analyze or improve. Yet even in that scenario, it's often the quality Plan Do Check Act cycle that applies more than some adaptation of code-test-release baked into a sprint framework. Yes, the "two objectives " must be harmonized somehow, but until there is a better meta abstraction for analytic processes, SRE and DevOps may remain qualitatively [sic] different approaches. One might analogize this way: SRE is IT's jazz musicians, working in a framework but accountable in a time- or resource-constrained box. DevOps is for IT's classical musicians, following a repeatable score brilliantly. Importantly, when infrastructure shifts, such as to microservices design patterns, both will be disrupted in ways that neither framework can yet address well.