Scrolls
6 min read
On this page

DevOps vs Platform Engineering

DevOps says "you build it, you run it." Platform engineering says "we'll build a platform so you can run it yourself." Both aim to accelerate software delivery, but they represent different stages of organizational maturity. Understanding where your organization sits on this spectrum determines which approach will actually help.

The Evolution

The path from traditional operations to platform engineering follows a predictable arc:

Manual Ops -> DevOps -> Platform Engineering

Manual Ops (2000s):
  Ops team manages servers, deploys code, fights fires.
  Developers write code and hand it off.
  Deploy cycle: weeks to months.

DevOps (2010s):
  Teams share responsibility for deployment and operations.
  Developers learn infrastructure. Ops engineers learn code.
  Deploy cycle: days to hours.

Platform Engineering (2020s):
  A dedicated team builds an internal platform.
  Developers self-serve: deploy, monitor, scale via the platform.
  Deploy cycle: minutes.

This is not a strict timeline -- many organizations are still in the manual ops phase. The evolution happens when the current model stops scaling.

DevOps: You Build It, You Run It

The DevOps model asks every team to own their entire stack. A team that builds a payment service also writes the Dockerfile, configures the CI pipeline, sets up monitoring, manages the Kubernetes manifests, and responds to production incidents.

This works well when:

  • Teams are experienced enough to handle infrastructure
  • The infrastructure is simple enough for generalists to manage
  • The organization is small enough that duplication is tolerable

This breaks down when:

  • Every team reinvents the CI/CD pipeline slightly differently
  • Junior developers spend more time fighting Kubernetes than writing features
  • Security and compliance requirements demand consistency across teams
  • The cognitive load on developers becomes unsustainable
Team A's pipeline:         Team B's pipeline:         Team C's pipeline:
  GitHub Actions             GitLab CI                  Jenkins
  Docker -> ECR              Docker -> GCR              Buildpacks -> ACR
  Helm -> EKS                Kustomize -> GKE           Raw manifests -> AKS
  Datadog                    Prometheus + Grafana        New Relic

All three teams deploy the same kind of service.
None of them can help debug each other's pipelines.

Platform Engineering: Build the Paved Road

Platform engineering acknowledges a hard truth: most developers do not want to become infrastructure experts. They want to ship features. A platform team builds the "paved road" -- a well-maintained, opinionated path from code to production that developers can use without understanding every layer of the stack.

The platform team's product is an internal developer platform (IDP). The platform team's customers are the development teams.

Without a platform:
  Developer -> writes Dockerfile -> configures CI/CD -> writes K8s manifests
             -> sets up monitoring -> manages secrets -> deploys

With a platform:
  Developer -> pushes code -> platform handles the rest
             (or: developer fills in a simple config file and the platform does the rest)

What an Internal Developer Platform Looks Like

An IDP is not a single tool. It is a curated, integrated set of tools and workflows:

Layer               What It Provides              Example Tools
----------------------------------------------------------------------
Developer portal    Service catalog, docs          Backstage, Port
CI/CD               Build, test, deploy            GitHub Actions, ArgoCD
Infrastructure      Self-serve infra provisioning  Terraform modules, Crossplane
Observability       Metrics, logs, traces          Grafana stack, Datadog
Security            Scanning, secrets, policies    Vault, OPA, Trivy

The key word is "self-serve." Developers should be able to create a new service, provision a database, set up monitoring, and deploy to production without filing a ticket or waiting for another team.

A Practical Example

A platform team at a 200-person engineering org might provide:

# service.yaml -- the only file a developer needs to write
apiVersion: platform.internal/v1
kind: Service
metadata:
  name: payment-api
  team: payments
spec:
  language: go
  port: 8080
  replicas:
    min: 2
    max: 10
  database:
    type: postgres
    size: small
  monitoring:
    slo: 99.9
  alerts:
    slack-channel: "#payments-alerts"

The developer writes this file. The platform takes it from there: provisions infrastructure, creates CI/CD pipelines, configures monitoring and alerting, sets up the Kubernetes deployment. The developer can still override defaults when needed, but the defaults handle 90% of cases.

Shift Left & the Platform Team

"Shift left" means moving responsibilities earlier in the development lifecycle. Security scanning happens in CI, not after deployment. Testing happens locally, not in staging. Infrastructure is defined in code alongside application code.

Shift left is a good idea. The problem is that it keeps adding responsibilities to developers:

2010: Developer writes code
2015: Developer writes code + tests + CI pipeline
2018: Developer writes code + tests + CI pipeline + Dockerfile + K8s manifests
2020: Developer writes code + tests + CI pipeline + Dockerfile + K8s manifests
      + monitoring + security scans + cost management
2023: Developer writes code. Platform handles everything else.

The platform team exists because shift left, taken to its logical extreme, turns every developer into a full-stack infrastructure engineer. That is neither efficient nor realistic. The platform team absorbs the operational complexity and exposes it through simple, well-documented interfaces.

When to Use Which Approach

DevOps Without a Platform Team

Appropriate when:

  • You have fewer than 5-10 development teams
  • Your infrastructure is relatively simple (one cloud, one cluster, one language)
  • Your developers are senior and comfortable with operations
  • You can tolerate some inconsistency across teams
  • You are a startup where velocity matters more than standardization

Platform Engineering

Appropriate when:

  • You have more than 10 development teams
  • Developers are spending significant time on non-feature work
  • Teams are duplicating infrastructure effort (every team builds its own CI/CD)
  • You need consistency for security, compliance, or cost control
  • Onboarding new developers takes weeks because the infrastructure is complex
  • Your DORA metrics are stalling because operational overhead is growing

The Transition Point

The signal that you need a platform team is usually this: your best developers are spending 30-50% of their time on infrastructure instead of features, and your less experienced developers are blocked waiting for infrastructure help. The "you build it, you run it" model has hit its cognitive load ceiling.

The Platform as a Product

The most important mindset shift in platform engineering is treating the platform as a product. The platform team has customers (developers), conducts user research, tracks adoption metrics, iterates based on feedback, and markets its features internally.

Bad platform team:
  "We built this platform. Use it. It's mandatory."
  Result: developers route around it, build their own tooling, resent the platform.

Good platform team:
  "We noticed teams spending 2 days setting up monitoring.
   We built a one-line config that does it. Try it out."
  Result: adoption is organic because the platform solves real problems.

If the platform is harder to use than doing it yourself, developers will not use it, no matter how many mandates come from management.

Real-World Example

Spotify's Backstage is the most visible example of platform engineering done well. Spotify had hundreds of microservices and dozens of teams. Each team managed infrastructure differently. Onboarding a new developer took weeks. Finding the owner of a service required digging through Slack history.

They built Backstage as a developer portal: a single place to see all services, their owners, their documentation, their CI/CD status, their deployment history. They open-sourced it in 2020, and it became a CNCF project.

The result: developers could discover services, create new ones from templates, and understand the state of production -- all without filing tickets or reading tribal knowledge.

Common Pitfalls

  • Building a platform too early -- If you have 3 teams, you do not need a platform. You need good documentation and shared scripts. Platforms are expensive to build and maintain.
  • Platform without user research -- Building what the platform team thinks developers need instead of what developers actually need leads to low adoption and wasted effort
  • Mandatory platforms without value -- Forcing developers onto a platform that makes their lives harder guarantees resentment and shadow IT
  • Platform team as a bottleneck -- If developers must file a ticket with the platform team to deploy, you have recreated the ops silo with a new name
  • Ignoring DevOps culture -- Platform engineering is not a replacement for DevOps culture. Developers still need to own their services. The platform just makes ownership easier.
  • Over-abstracting -- Hiding too much complexity means developers cannot debug production issues. The platform should simplify the common case, not prevent access to the underlying infrastructure.

Key Takeaways

  • DevOps is a cultural movement; platform engineering is an organizational pattern that builds on DevOps principles
  • The evolution is: manual ops to DevOps to platform engineering, driven by scale and cognitive load
  • Platform engineering builds the "paved road" so developers can self-serve infrastructure without becoming infrastructure experts
  • The internal developer platform is the product; developers are the customers
  • Start with DevOps culture first; add a platform team when operational overhead starts throttling feature delivery
  • A good platform is adopted voluntarily because it solves real problems, not mandated from above