DevOps vs. SRE vs. Platform Engineering - A Clickbait Discussion...

Table of Contents

There are many discussions about DevOps vs. SRE vs. Platform Engineering. This post shares some helpful links and my personal interpretation of these concepts, plus a few related ideas that often get mixed into the debate.

Originally intended as a social media post, this became too long for that format. Please excuse any typos or informal language!

Disclaimer:
These discussions are often driven by software vendors, consulting companies, IT magazines, and snake-oil salesmen. New hype means new revenues, right? :)
There is usually no formal definition for these concepts. They describe heuristics and observations, which are “branded” as soon as emerging practices mature into good practices. There will never be a formal definition for these things! The risk of being attacked after writing such posts is high :)

What is DevOps? (Organization-level, Culture, Behavior)

Recommended links:

DevOps is about organization-wide change in behavior—across management, crosscutting departments, development, and operations. The focus is on:

Collaboration (breaking down silos and rigid, Tayloristic processes)
Quality, learning, and feedback
Automation and lean principles
Autonomy and shared responsibility
Constant value delivery and rapid turnaround in critical situations

DevOps is not a set of tools or prescriptive guidelines. It’s a mindset, a cultural revolution, and a response to the failures of “scientific management” and Taylorism in IT organizations.

The promise:

Sustainable social systems (happy engineering teams, work-life balance—even with 24/7 services, low turnover, strong commitment to business goals and customer value)
High-quality technical systems (efficiency and effectiveness together)

Happy engineers, less waste, better outcome!

Caveats:

DevOps will not work in companies that exploit people. I’ve seen these initiatives fail in industrial environments like automative, banking. You can’t achieve the benefits of DevOps without listening to employees and removing narcissistic management behaviors.
DevOps is not needed in organizations that never applied Scientific Management to IT. Startups, for example, often don’t need DevOps—they hire people who haven’t been trapped in Tayloristic cages.

Still, DevOps is a great starting point for organizations with “history” and “legacy” to discuss how to do business or provide digital services in the future. There are thousands of case studies, reports, videos, and books to learn from.

What is Continuous Delivery?

Recommended links:

(Follow Dave Farley and Bryan Finster on Twitter, LinkedIn, and YouTube)

Continuous Delivery (CD) is what engineering teams should strive for in practice—regardless of whether there’s a formal “DevOps initiative” in your organization.

“Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain.”
— minimumCD

For more details, check out the MinimumCD site and related resources.

“You build it, you run it”

Recommended link:

What is “You build it, you run it”?

This is a style of DevOps that says: the people who build software should also run, fix, and operate it. It’s about responsibility and usually involves Continuous Delivery. It fits perfectly with digital services and product teams that develop their own service-based products.

Note: There are still cases where separation of Dev and Ops is needed:
Public sector organizations (due to lack of Dev people)
When operating mostly 3rd party software/infrastructure
In these cases, adopting SRE principles can help ensure 3rd parties don’t accidentally break your stuff.

What is Site Reliability Engineering (SRE)?

Recommended links:

SRE is a style of DevOps that puts more focus on operations work. SRE follows similar goals and principles as DevOps, but with a stronger emphasis on reliability.

When is SRE applied?

Operating 3rd party software
Running custom-built solutions produced by external contractors
Managing critical software (banking, e-government, education)
Running critical infrastructure (databases, gateways, cloud platforms, etc.)

Often, there’s not much “you build it”—it’s more about integrating and operating components. The main focus is on making changes (new versions, new configs) without breaking things.

You can do SRE without learning all the SRE jargon (SLO, SLI, etc.). Many teams have done this in practice, even before SRE was a buzzword.

What is Platform Engineering?

Recommended links:

Product teams often have T-shaped skillsets—they can build features, but may lack the deep technical expertise to integrate complex technology or deal with legacy systems (ITIL operations, governance, custom protocols, etc.).

Platform teams focus on establishing self-services (“lego bricks”) to reduce technical and organizational complexity for everyone who needs to use them. A platform team is basically enforcing the “Shift Left” principle. They handle conversations with departments or silos that can’t or won’t change their ways (classic business IT, vendors, cloud providers).

A platform is a marketplace where providers (classic IT, datacenter services, legacy systems) interact with consumers (product teams, business partners, etc.).

The product of a platform team is often called a Developer Platform, Cloud Platform, DevOps Platform, API Platform, etc.

Platform engineering usually involves adopting several concepts:

DevOps
Continuous Delivery
SRE
“You build it, you run it”

…and interacting with teams that may have adopted some or all of these concepts.

Summary

DevOps, SRE, and Platform Engineering are not rigid frameworks—they are evolving mindsets and practices.

DevOps emphasizes organization-wide cultural change and collaboration.
SRE adapts DevOps principles with a stronger focus on reliability and operations, especially for complex or third-party systems.
Platform Engineering builds self-service platforms to reduce complexity for product teams, integrating DevOps, SRE, and CD concepts.

There is no one-size-fits-all approach—success depends on context, organizational culture, and a willingness to adapt, learn, and avoid dogma.