Platform Engineering: The Role That Replaced DevOps

In 2019, our team had a DevOps engineer. His name was Andrei, and his job was to do everything that application developers didn't want to do: configure CI/CD pipelines, manage Kubernetes clusters, set up monitoring, handle deployments, and respond to production incidents at 3 AM. Andrei was brilliant and perpetually overwhelmed.

By 2023, Andrei's title had changed to "Platform Engineer," and his job had fundamentally shifted. Instead of doing things for developers, he was building tools that let developers do things themselves. Instead of being the bottleneck for every deployment, he built a self-service deployment platform that let any engineer deploy to production in under 5 minutes. Andrei went from being the busiest person on the team to the most impactful.

That transformation — from "DevOps as a service desk" to "Platform Engineering as an enabler" — is the most significant organizational shift in infrastructure since the cloud migration wave of the 2010s. According to Gartner, by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components, and tools for application delivery. The CNCF 2024 Survey found that 78% of organizations are either using or evaluating platform engineering practices.

This article explains what platform engineering is, why DevOps alone isn't enough, and how to build an Internal Developer Platform that actually works.

Why DevOps Isn't Enough Anymore

DevOps was a cultural movement that broke down the wall between development and operations. It succeeded spectacularly — CI/CD, infrastructure as code, and shared responsibility for production are now industry standards. But DevOps had a flaw: it assumed every developer wanted to (and could) manage infrastructure.

In practice, "you build it, you run it" often became "you build it, you struggle to run it because infrastructure is incredibly complex and you have features to ship." The cognitive load on application developers became unsustainable. According to a Humanitec survey, 78% of developers report that managing infrastructure takes significant time away from feature development.

Platform engineering addresses this by providing golden paths — opinionated, well-supported workflows that handle the infrastructure complexity behind an abstraction layer. Developers get self-service capabilities without needing to understand the underlying infrastructure. The platform team gets to enforce standards, security policies, and best practices without being a bottleneck.

The Evolution

What Is an Internal Developer Platform (IDP)?

An Internal Developer Platform is a layer of tooling and automation that sits between developers and infrastructure. It provides self-service capabilities for common tasks: deploying applications, provisioning databases, managing secrets, setting up monitoring, and creating development environments.

The internaldeveloperplatform.org reference architecture identifies five core capabilities:

1. Application Configuration Management

Developers describe what their application needs (a database, a cache, a message queue) without specifying how to provision it. The platform translates these requirements into actual infrastructure.

2. Infrastructure Orchestration

The platform provisions and manages infrastructure resources using tools like Terraform, Crossplane, or Pulumi. Developers don't write Terraform modules — the platform handles that.

3. Environment Management

Creating a new environment (staging, feature branch, load testing) should be a one-click operation. The platform handles networking, database provisioning, secret injection, and DNS configuration.

4. Deployment Management

The platform provides a standard deployment pipeline: build, test, deploy, verify. Developers push code; the platform handles everything else, including rollback on failure.

5. Role-Based Access Control

The platform enforces who can deploy to which environment, access which secrets, and manage which resources — without requiring manual approval workflows.

The Tools: Backstage, Crossplane, and the Ecosystem

Backstage (Spotify)

Backstage is an open-source developer portal originally created by Spotify and now a CNCF incubating project. It's the most widely adopted platform engineering tool, used by companies like Netflix, American Airlines, and Fidelity.

What it does:

• Software Catalog: A registry of all services, libraries, and infrastructure components with ownership information. "Who owns this service?" is answered instantly.
• Software Templates: Scaffolding for new services. Create a new microservice with CI/CD, monitoring, documentation, and deployment configuration in minutes.
• TechDocs: Documentation-as-code, rendered directly in Backstage. No more hunting for documentation across Confluence, Google Docs, and README files.
• Plugin ecosystem: Over 150 community plugins for integrating with Kubernetes, CI/CD tools, monitoring platforms, and cloud providers.

My take: Backstage is the right starting point for most organizations. Its software catalog alone provides massive value — knowing what services exist, who owns them, and their current status is foundational to platform engineering. However, Backstage is a framework, not a product. You need to invest significant engineering effort to customize it for your organization.

Crossplane

Crossplane is a CNCF project that extends Kubernetes to manage external infrastructure (cloud resources, databases, DNS records) using Kubernetes-style declarative APIs. Instead of writing Terraform and running it in CI/CD, you define infrastructure as Kubernetes custom resources.

What it does:

• Provisions cloud resources (RDS databases, S3 buckets, VPCs) from Kubernetes manifests
• Supports Compositions — abstracted infrastructure blueprints that hide cloud-specific details
• Reconciliation loop ensures infrastructure matches desired state (drift detection built-in)
• Multi-cloud support via Providers (AWS, GCP, Azure, and 50+ others)

My take: Crossplane is powerful but complex. It's best suited for organizations already running Kubernetes with a platform team that understands both K8s and infrastructure management. For smaller teams, Terraform remains simpler and more approachable.

Other Notable Tools

Building a Platform Team: Practical Guidance

Team Size and Structure

The Team Topologies framework (by Matthew Skelton and Manuel Pais) provides the organizational model: the platform team is an "enabling team" that provides capabilities to "stream-aligned teams" (product teams). Key considerations:

• Minimum viable team: 2-3 engineers. One person can't build a platform — they'll burn out and create a bus factor of 1.
• Ideal ratio: One platform engineer per 8-12 application developers. This is a rough guideline, not a rule.
• Required skills: Infrastructure (Kubernetes, cloud, networking), software engineering (the platform is a product — it needs proper engineering), and product thinking (understanding developer needs).

The "Treat Your Platform as a Product" Principle

The most common failure in platform engineering is building a platform that nobody uses. The fix is product thinking:

• Talk to your customers. Application developers are your users. Interview them. Understand their pain points. Prioritize based on their needs, not your technical interests.
• Measure adoption. Track how many teams use each platform capability. If a feature has low adoption, either improve it or kill it.
• Provide documentation and support. A platform without documentation is a platform nobody can use. Invest in tutorials, examples, and a support channel (Slack, Teams).
• Don't mandate — attract. If your platform is good, developers will adopt it willingly. If you need to mandate its use, it's a sign that the developer experience isn't good enough.

Golden Paths: The Core Concept

A golden path is a supported, opinionated way to accomplish a common task. It's not the only way — it's the recommended way. Developers can deviate from the golden path, but they lose platform support when they do.

Examples of Golden Paths

Creating a new service:

1. Run platform create-service --name my-service --type rest-api --language python
2. The platform scaffolds a repository with CI/CD, Dockerfile, Kubernetes manifests, monitoring configuration, and documentation template
3. Push code to the repository; the platform handles building, testing, and deploying to staging
4. Merge to main; the platform deploys to production with canary rollout

Provisioning a database:

1. Add a database requirement to the service configuration: database: type=postgresql, size=small
2. The platform provisions an RDS instance, creates credentials, injects them as environment variables, and configures backups
3. The developer connects to the database using standard environment variables — no Terraform, no AWS console

The key principle: Golden paths should make the right thing the easy thing. Security best practices, monitoring, logging, and deployment safety should be built in by default, not added as an afterthought.

Action Plan: Starting Your Platform Engineering Journey

Phase 1: Discovery (Week 1-4)

1. Audit developer workflows. Map the steps required to deploy a new service, provision infrastructure, and debug a production issue. Count the tools, manual steps, and tickets involved.
2. Interview developers. Ask: "What takes too long? What's confusing? What do you wish you could do without asking for help?" Document the top 5 pain points.
3. Assess current tools. What do you already have? CI/CD pipelines, container orchestration, monitoring — these are platform building blocks even if they're not labeled as such.

Phase 2: Quick Wins (Week 5-8)

1. Standardize CI/CD. Create shared pipeline templates that teams can adopt. A single, well-maintained build pipeline is the simplest platform capability.
2. Deploy Backstage (or equivalent). Start with the software catalog. Get every team to register their services. This alone creates massive organizational value.
3. Create one golden path. Pick the most common developer task (e.g., creating a new service) and build a fully automated, opinionated workflow for it.

Phase 3: Build the Platform (Month 3-6)

1. Self-service infrastructure. Let developers provision databases, caches, and message queues without tickets or Terraform knowledge.
2. Environment management. Enable one-click environment creation for feature branches, staging, and load testing.
3. Observability integration. Every service created via the golden path should have monitoring, logging, and tracing configured automatically.

Phase 4: Scale and Iterate (Month 6+)

1. Measure and iterate. Track adoption metrics, developer satisfaction (quarterly surveys), and time-to-production for new services.
2. Expand golden paths. Add paths for common patterns: background workers, scheduled jobs, event-driven services, frontend applications.
3. Build a platform community. Create a working group of developers who contribute to the platform, provide feedback, and champion adoption.

Sources

• Gartner — What Is Platform Engineering
• CNCF Annual Survey 2024
• Humanitec — State of Platform Engineering
• Internal Developer Platform Reference Architecture
• Backstage
• Crossplane
• Team Topologies

I'm Ismat, and I build BirJob — Azerbaijan's job aggregator scraping 80+ sources daily.