SRE vs DevOps: What's the difference?
How systems reliability engineers and DevOps are transforming IT.
In today’s always-on digital economy, DevOps is quickly becoming as mainstream as the cloud. Indeed, DevOps was born out of a need for faster deployment to create lasting competitive advantages regardless of the industry. In short, if your enterprise organization has been looking to accelerate application delivery, there’s a good chance you’ve already considered implementing DevOps.
But is DevOps the perfect fit for every enterprise organization?
In recent years, another approach to managing IT infrastructure has begun to gain more prominence in the enterprise business scene. Site Reliability Engineering, or SRE for short, has become known as the distant cousin of DevOps that effervesces some of the same core principles but applies them to large scale frameworks, like those at Google.
If you’ve been thinking of making the transition to DevOps, you can’t afford to miss this information, before you begin the culture shift.
Before we go any further, it’s worth explaining some of the foundational concepts of DevOps in greater detail.
DevOps is an approach to programming that follows the principles of lean or Agile. In DevOps, teams focus on continuous delivery of useable digital products. Automation makes this focus on continuous delivery a reality for enterprises.
For organizations undergoing the process of digital transformation, DevOps stands to bridge the gap between operations and development that can sometimes be very wide: Development teams are focused on programming and delivery while Operations must monitor and maintain platform stability and ensure functionality needs are met.
This means Operations often puts pressure on development to work on things other than rolling out new software (e.g. testing and QA); whereas Dev sometimes pushes back by sneaking in releases before Operations has a chance to audit them.
Needless to say, the relationships between these two departments can be contentious as a result. That’s where DevOps comes in with an automated approach to Agile software development that allows Dev teams to focus on delivering new software while maintaining functionality and compliance principles required by Operations.
Using this approach, many enterprises have not only enhanced their IT department, but also their overall company culture. That’s because a successful move to DevOps requires a shift in corporate thinking that inspires change across the entire organization. But, more on this later in the article.
In an enterprise climate where multiple applications are required to automate and integrate on a given framework, DevOps is the glue that holds the pieces together with a lean approach to development and agility. Think of SRE, instead, as the engine that allows developers to create the framework itself.
The concept of SRE came about at Google, when an engineer named Ben Treynor headed up a team to improve Google’s site reliability. It quickly became apparent that an architectural method didn’t exist to cover the needs of such large-scale systems. And thus, SRE was born out of necessity.
SRE teams spend half their time working on operations calls and the other developing software, adding configurations and program features.
The architectural method is considered an extension of DevOps that has some necessary and important differences.
A staggering difference between SRE and DevOps is that SRE is operationally driven from the top down. Under this approach, developers are empowered to monitor and maintain their software releases, a function that would normally be housed in IT Operations. However, this can only be done if team leadership has a keen eye for IT operations, as well as a passion for frequent releases.
While DevOps seeks to bridge the gap between departments via a culture of aligning key goals and initiatives, SRE focuses on removing departmental communication headaches altogether by installing team-lead engineers who have an Operations background and mindset.
However, it is important to note that SRE is a more scalable approach for the continuous development and improvement of complex frameworks, while DevOps is ideal for the frequent releases of digital products and code. But both exist under the same DevOps paradigm.
SRE elevates the significance of continuous improvement to that of continuous development. With an SRE approach, improvements to existing programs fall under ownership of the development team. And they are just as important as new releases.
Hopefully, you are starting to clearly see how the two approaches are alike, yet very different at the same time.
With faster delivery time to market comes greater ROI. Implementing a DevOps approach could be the right solution for enterprise businesses looking to boost return on investment with more frequently released, highly usable digital products to distribute to end users.
A culture of high mutual trust. This is a key requirement to ensure that Dev and Ops can accomplish incredible things – together as one cohesive DevOps effort. One way to do this is to designate a “Transformational Leader” who has the characteristics to contribute to such progressive momentum.
A culture that encourages innovation that focuses on integrating lean principles and shorter implementation cycles.
A structure that removes organizational silos thus empowering strategic alignment and reducing conflict.
With a DevOps approach, enterprise businesses benefit from a stable operating environment, automation, early detection of defects and continuous product release. These are all benefits that offer businesses agility, an outcome that is often sought after in high-functioning enterprise organizations.
If you decide that DevOps is the right fit for your organization, then your next steps should involve enabling jobs-as-code to drive faster, more reliable delivery. With jobs-as-code developers can now include jobs as artifacts in the continuous DevOps delivery pipeline the same way the Java or Python code is managed through the entire software development process today. The result? Operations receives tested, ready-to-go applications because jobs are defined and built at the same time as applications are built, thereby reducing the normal stress involved with application delivery.
Those businesses that switch to SRE can also expect to benefit from increased ROI, improved relationships and greater agility since SRE seeks to address the same key principles as DevOps. However, SRE is often viewed as the perfect marriage of Dev and Ops.
The approach is well-suited for businesses that require the management of large scale systems. But you will also come to find that it benefits companies of different shapes and sizes. Apart from Google, other organizations including Netflix and DropBox have been at the forefront of tech leadership in this space.
Always remember that, with SRE, successful implementation means first ensuring your organization has the people with the right experience in place to operationally lead Development teams.
DevOps vs. SRE: Which should you choose?
As you can see, there is no cookie cutter response to determining which approach is better: DevOps or SRE. However, what is apparent is that any enterprise organization looking to make the change to one of these approaches should prepare for big organizational, culture and production changes within their organization.
Assess your baseline. Knowing where your processes stand today is an important first step in developing a roadmap that allows you to prioritize key enterprise requirements.
Consider your current team: Which approach will mean bringing on new staff, partnering with IT vendors for software and managed services, implementing new process that support growth, training and more? How will this affect your IT budget?
Focus on outcomes: Determine if your desired product output is rapid release digital products for revenue growth (DevOps) or larger frameworks with a focus on continuous improvement (SRE).
Stephen Watts is a Web Strategist and author at BMC Software. He combines a background in philosophy, two decades of web development experience and an expertise in enterprise IT to help break down complex IT subjects.