Platform Engineering vs DevOps vs SRE

📖 Introduction

One of the most common questions I encounter is: "Isn't platform engineering just DevOps with a new name?" It's a fair question—the industry has seen plenty of rebranding. But having worked across all three disciplines, I can tell you the differences are real and meaningful.

Understanding how Platform Engineering, DevOps, and Site Reliability Engineering (SRE) relate to each other—and where they differ—is crucial for building effective engineering organizations. They're not competitors; they're complementary approaches that address different aspects of software delivery.

---

🎯 The Three Disciplines

---

🔄 DevOps: The Cultural Foundation

What is DevOps?

DevOps is a cultural movement that emerged in the late 2000s to break down the traditional wall between development and operations. It's not a job title or a tool—it's a philosophy.

Core DevOps Principles

Principle	Description
Culture	Collaboration over silos, shared responsibility
Automation	Automate everything that can be automated
Measurement	Data-driven decision making
Sharing	Knowledge sharing, blameless postmortems
Flow	Optimize the entire value stream

The DevOps Journey

DevOps: The Reality Check

The "you build it, you run it" ideal works well at certain scales and with certain talent pools. But many organizations discovered:

DevOps Promise:
    Developers own end-to-end delivery
    ↓
Reality at Scale:
    • Not everyone wants to manage infrastructure
    • Cognitive load becomes overwhelming
    • Inconsistent implementations across teams
    • Senior devs become "shadow ops"
    • Standards are hard to maintain

DevOps didn't fail—it revealed that developer self-sufficiency needs supporting infrastructure.

---

🔧 Site Reliability Engineering: The Reliability Focus

What is SRE?

Site Reliability Engineering is a discipline pioneered by Google that applies software engineering practices to infrastructure and operations. Ben Treynor, VP of Engineering at Google, described SRE as "what happens when you ask a software engineer to design an operations team."

Core SRE Concepts

SRE Principles

Concept	Definition	Example
SLI	Service Level Indicator	99.95% of requests complete in < 200ms
SLO	Service Level Objective	Target: 99.9% availability per month
SLA	Service Level Agreement	Contractual commitment with consequences
Error Budget	Allowed failures before action required	0.1% downtime = 43 minutes/month
Toil	Manual, repetitive operational work	Manual deployments, ticket processing

SRE's Approach to Reliability

from dataclasses import dataclass
from datetime import datetime, timedelta


@dataclass
class ErrorBudget:
    """Manage reliability vs. velocity tradeoffs."""
    
    service: str
    slo_target: float  # e.g., 0.999 for 99.9%
    measurement_window: timedelta
    current_availability: float
    
    @property
    def error_budget_total(self) -> float:
        """Total allowed error percentage."""
        return 1 - self.slo_target
    
    @property
    def error_budget_used(self) -> float:
        """Percentage of error budget consumed."""
        actual_errors = 1 - self.current_availability
        return actual_errors / self.error_budget_total
    
    @property
    def error_budget_remaining(self) -> float:
        """Remaining error budget percentage."""
        return max(0, 1 - self.error_budget_used)
    
    def can_deploy_risky_change(self) -> bool:
        """Whether error budget allows risky deployments."""
        return self.error_budget_remaining > 0.25  # 25% buffer
    
    def recommended_action(self) -> str:
        """What the team should focus on."""
        if self.error_budget_remaining > 0.5:
            return "SHIP: Plenty of budget for features"
        elif self.error_budget_remaining > 0.25:
            return "CAUTION: Balance features with reliability"
        elif self.error_budget_remaining > 0:
            return "SLOW DOWN: Focus on reliability improvements"
        else:
            return "FREEZE: Stop features, fix reliability"


# Example usage
api_service = ErrorBudget(
    service="api-gateway",
    slo_target=0.999,  # 99.9%
    measurement_window=timedelta(days=30),
    current_availability=0.9985  # 99.85%
)

print(f"Error budget remaining: {api_service.error_budget_remaining:.1%}")
print(f"Recommendation: {api_service.recommended_action()}")

---

🏗️ Platform Engineering: The Enablement Layer

What is Platform Engineering?

Platform Engineering is the discipline of building and operating internal developer platforms that enable self-service for development teams. It takes DevOps principles and makes them accessible through well-designed tooling.

Core Platform Engineering Focus

The Platform Engineering Value Proposition

Challenge	DevOps Response	Platform Engineering Response
Complex tooling	Train everyone on all tools	Abstract complexity behind interfaces
Inconsistency	Guidelines and documentation	Enforced through templates and APIs
Slow onboarding	Extensive training programs	Self-service with golden paths
Security compliance	Manual reviews	Automated guardrails
Cognitive overload	Accept as necessary	Reduce through abstraction

---

🔍 Comparing the Three Disciplines

Side-by-Side Comparison

Aspect	DevOps	SRE	Platform Engineering
Origin	Grassroots movement	Google	Enterprise patterns
Primary Focus	Culture & collaboration	Reliability & uptime	Developer experience
Key Metric	DORA metrics	SLOs & error budgets	Developer productivity
Main Output	Practices & culture	Reliable systems	Internal platform
Scope	Entire org	Production systems	Developer workflows
Job Title?	Debatable	Yes	Yes

Focus Areas Venn Diagram

                    ┌─────────────────────────────────────┐
                    │              DevOps                 │
                    │   Culture, Collaboration, Flow     │
                    │                                     │
         ┌──────────┼──────────────┐                      │
         │          │              │                      │
         │   ┌──────┼──────────────┼──────┐              │
         │   │      │   Shared:    │      │              │
         │   │      │ • Automation │      │              │
    SRE  │   │      │ • CI/CD      │      │ Platform    │
         │   │      │ • IaC        │      │ Engineering │
         │   │      │ • Monitoring │      │              │
         │   │      └──────────────┘      │              │
         │   │                            │              │
         │   │  Reliability    Self-      │              │
         │   │  SLOs           Service    │              │
         │   │  Error Budgets  Golden     │              │
         └───┼────────────────────────────┼──────────────┘
             │                            │
             └────────────────────────────┘

Organizational Relationships

---

🤝 How They Work Together

Complementary Roles

# Example: How disciplines collaborate on a deployment pipeline

devops_contribution:
  - Established CI/CD culture
  - Defined deployment best practices
  - Created blameless postmortem culture
  
sre_contribution:
  - Defined SLOs for deployment success rate
  - Created canary deployment patterns
  - Built rollback automation
  - Monitors error budget impact
  
platform_engineering_contribution:
  - Built self-service deployment interface
  - Created deployment templates
  - Abstracted Kubernetes complexity
  - Integrated security scanning
  
result:
  developer_experience: "One-click deploy with guardrails"
  reliability: "Canary deployments with auto-rollback"
  culture: "Shared ownership, blameless learning"

The Collaboration Model

Scenario	Primary Owner	Supporting Role
New service deployment	Platform Engineering	SRE reviews SLOs
Production incident	SRE	Platform improves based on findings
CI/CD pipeline design	Platform Engineering	SRE for reliability patterns
Monitoring setup	SRE	Platform for self-service integration
Security scanning	Platform Engineering	SRE for runtime security
Capacity planning	SRE	Platform for cost optimization

Example: Incident Response Flow

---

🏢 Organizational Models

Model 1: Separate Teams

┌─────────────────────────────────────────────────────────┐
│                    Engineering Org                       │
├─────────────────┬─────────────────┬─────────────────────┤
│   Development   │    Platform     │        SRE          │
│     Teams       │      Team       │       Team          │
│                 │                 │                     │
│ • Build         │ • Build IDP     │ • On-call rotation  │
│   features      │ • Golden paths  │ • SLO management    │
│ • Use platform  │ • Self-service  │ • Incident response │
│ • Provide       │ • Developer     │ • Reliability       │
│   feedback      │   experience    │   improvements      │
└─────────────────┴─────────────────┴─────────────────────┘

Works best for: Large organizations (500+ engineers)

Model 2: Combined Platform & SRE

┌─────────────────────────────────────────────────────────┐
│                    Engineering Org                       │
├─────────────────────────┬───────────────────────────────┤
│      Development        │   Platform + SRE Team          │
│        Teams            │   (Production Engineering)     │
│                         │                               │
│ • Build features        │ • Build & run IDP             │
│ • Use platform          │ • Self-service capabilities   │
│ • Provide feedback      │ • Reliability & SLOs          │
│                         │ • Incident response           │
└─────────────────────────┴───────────────────────────────┘

Works best for: Medium organizations (100-500 engineers)

Model 3: Embedded SRE with Central Platform

┌─────────────────────────────────────────────────────────┐
│                    Engineering Org                       │
├───────────────────────────────┬─────────────────────────┤
│       Stream-Aligned Teams    │     Platform Team       │
│     (with embedded SREs)      │                         │
├───────────────────────────────┤                         │
│ Team A          Team B        │ • Central IDP           │
│ ├── Devs        ├── Devs      │ • Shared tooling        │
│ └── SRE         └── SRE       │ • Standards & templates │
└───────────────────────────────┴─────────────────────────┘

Works best for: Organizations with complex, diverse systems

---

📊 Metrics Comparison

Each Discipline's Key Metrics

from dataclasses import dataclass
from typing import Literal


@dataclass
class DisciplineMetrics:
    """Key metrics tracked by each discipline."""
    
    discipline: Literal["devops", "sre", "platform_engineering"]
    
    @property
    def primary_metrics(self) -> list[str]:
        metrics_map = {
            "devops": [
                "Deployment frequency",
                "Lead time for changes",
                "Change failure rate",
                "Mean time to recovery (MTTR)",
            ],
            "sre": [
                "Availability (SLO)",
                "Error budget consumption",
                "Incident count and severity",
                "Time to detect (TTD)",
                "Time to mitigate (TTM)",
                "Toil percentage",
            ],
            "platform_engineering": [
                "Platform adoption rate",
                "Developer satisfaction (NPS)",
                "Time to first deployment",
                "Self-service success rate",
                "Ticket deflection rate",
                "Mean time to onboard",
            ],
        }
        return metrics_map[self.discipline]
    
    @property
    def focus_area(self) -> str:
        focus_map = {
            "devops": "Delivery velocity and flow",
            "sre": "System reliability and uptime",
            "platform_engineering": "Developer productivity",
        }
        return focus_map[self.discipline]

Metrics Dashboard Example

┌─────────────────────────────────────────────────────────────────┐
│                    ENGINEERING HEALTH DASHBOARD                  │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  DevOps / DORA Metrics                                          │
│  ├── Deployment Frequency: 12/day ✅                            │
│  ├── Lead Time: 2.3 days ⚠️                                    │
│  ├── Change Failure Rate: 4.2% ✅                               │
│  └── MTTR: 45 minutes ✅                                        │
│                                                                 │
│  SRE Metrics                                                    │
│  ├── API Availability: 99.95% ✅                                │
│  ├── Error Budget: 62% remaining ✅                             │
│  ├── P1 Incidents (30d): 2 ✅                                   │
│  └── Toil: 18% of time ⚠️                                      │
│                                                                 │
│  Platform Engineering Metrics                                   │
│  ├── Platform Adoption: 87% ✅                                  │
│  ├── Developer NPS: +52 ✅                                      │
│  ├── Self-Service Success: 94% ✅                               │
│  └── Time to First Deploy: 4 hours ⚠️                          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

---

🚦 When to Use What

Decision Framework

Practical Guidelines

If you have...	Focus on...	Key Actions
Siloed teams, blame culture	DevOps	Cross-functional teams, shared ownership
Frequent outages, SLA breaches	SRE	Define SLOs, error budgets, incident management
Slow developer productivity	Platform Engineering	Build self-service, golden paths
All of the above	All three	Start with culture (DevOps), then build (PE + SRE)

---

📝 Summary

DevOps, SRE, and Platform Engineering are complementary disciplines that work together to deliver reliable software quickly. They're not competing approaches—they address different layers of the same challenge.

Quick Reference

Discipline	Core Question	Outcome
DevOps	"How do we collaborate better?"	Culture of continuous improvement
SRE	"How do we stay reliable?"	Measured, sustainable reliability
Platform Engineering	"How do we scale developer productivity?"	Self-service internal platform

The Modern Engineering Organization

                  DevOps Culture
                       │
         ┌─────────────┴─────────────┐
         │                           │
    SRE Practices          Platform Engineering
         │                           │
    Reliability                 Productivity
    SLOs & Error Budgets        Self-Service
    Incident Management         Golden Paths
         │                           │
         └─────────────┬─────────────┘
                       │
             Fast, Reliable, Scalable
               Software Delivery

---

🔗 References

• Google SRE Book

• The DevOps Handbook

• Team Topologies

• DORA State of DevOps Reports

• What is Platform Engineering - Microsoft

---

➡️ Next Steps

Continue to Article 4: Internal Developer Platform Architecture to learn about the components and architecture of a well-designed Internal Developer Platform.