DevOps Is Not Dead -- It Evolved
In 2015, DevOps meant breaking down the wall between development and operations. In 2020, it meant "you build it, you run it." In 2026, the industry has learned that making every developer responsible for Kubernetes manifests, Terraform modules, CI/CD pipelines, and Datadog dashboards does not scale — it just makes everyone worse at their primary job.
Gartner predicts that by 2027, 80% of large software engineering organisations will have established platform engineering teams, up from 15% in 2023. The shift is happening because the cognitive load on application developers has become unsustainable.
What Platform Engineering Actually Means
Platform engineering is the practice of building and maintaining an Internal Developer Platform (IDP) — a self-service layer that abstracts infrastructure complexity and provides golden paths for common tasks.
The key difference from traditional DevOps:
| Aspect | Traditional DevOps | Platform Engineering |
|---|---|---|
| Philosophy | "You build it, you run it" | "We build the platform, you build on it" |
| Infrastructure access | Every team manages their own infra | Teams use self-service abstractions |
| Cognitive load | High — developers manage infra + app code | Low — developers focus on business logic |
| Standardisation | Varies by team | Golden paths enforced by platform |
| Team structure | Embedded SRE/DevOps per team | Central platform team serving multiple teams |
| Developer experience | DIY | Product-grade self-service |
The Cognitive Load Problem
A 2024 Humanitec survey found that developers spend 30-40% of their time on infrastructure-related tasks rather than writing business logic. For a team of 50 developers at EUR 100,000/year average cost, that is EUR 1.5-2 million/year spent on tasks that could be automated by a platform team of 3-5 engineers.
The specific tasks that create cognitive load:
- Writing and debugging Kubernetes manifests
- Configuring CI/CD pipelines for each new service
- Setting up monitoring and alerting dashboards
- Managing secrets and environment configuration
- Debugging infrastructure issues in production
- Understanding and applying security best practices
- Navigating cloud provider documentation and pricing
What an Internal Developer Platform Looks Like
An IDP is not a single tool — it is a curated set of tools and abstractions that provide self-service capabilities to development teams. The five core components:
1. Service Catalogue (Backstage)
Backstage, originally developed by Spotify, is the de facto standard for service catalogues. It provides:
- A single pane of glass for all services, their owners, documentation, and dependencies
- Software templates for creating new services with all the boilerplate (CI/CD, monitoring, IaC) pre-configured
- Plugin ecosystem for integrating with your existing tools (PagerDuty, Datadog, Kubernetes, GitHub)
2. Self-Service Infrastructure
Developers should be able to provision databases, caches, queues, and environments without opening a ticket or writing Terraform:
# Example: self-service infrastructure via Backstage template
# Developer fills out a form, platform creates the infrastructure
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: new-microservice
title: Create New Microservice
spec:
parameters:
- title: Service Configuration
properties:
serviceName:
type: string
description: Name of the microservice
database:
type: string
enum: ["postgres-small", "postgres-medium", "none"]
description: Database tier
cache:
type: string
enum: ["redis-small", "none"]
description: Cache tier
environment:
type: string
enum: ["development", "staging", "production"]
steps:
- id: create-repo
action: publish:github
input:
repoUrl: github.com?repo=${{ parameters.serviceName }}&owner=myorg
template: ./skeleton
- id: provision-infra
action: custom:terraform-apply
input:
module: microservice
variables:
service_name: ${{ parameters.serviceName }}
database_tier: ${{ parameters.database }}
cache_tier: ${{ parameters.cache }}
- id: setup-cicd
action: custom:github-actions-setup
input:
repo: ${{ parameters.serviceName }}
pipeline: standard-microservice3. Golden Path CI/CD
Instead of every team building their own pipeline, the platform team provides standardised, reusable pipeline templates:
- One template for backend services (build, test, scan, deploy to K8s)
- One template for frontend apps (build, test, deploy to CDN)
- One template for data pipelines (build, test, deploy to Airflow/Step Functions)
Teams can extend the templates for specific needs but the baseline (security scanning, compliance checks, deployment strategy) is enforced.
4. Observability as a Service
The platform team configures standard observability for every service:
- Automatic metrics collection (request rate, error rate, latency)
- Centralised logging with structured format and correlation IDs
- Distributed tracing enabled by default (OpenTelemetry)
- Pre-built dashboards that teams can customise
- Standard alerting rules (e.g., error rate > 1% for 5 minutes)
5. Security and Compliance Guardrails
Security policies enforced at the platform level, not by individual teams:
- OPA/Kyverno policies preventing insecure Kubernetes configurations
- Automated secret rotation
- Network policies enforcing service-to-service communication rules
- Compliance controls (GDPR, SOC 2, EU AI Act) built into the deployment pipeline
When to Transition to Platform Engineering
Not every organisation needs a platform team. The investment makes sense when:
- You have 5+ development teams — Below this, the platform team is overhead. Above this, duplicated effort across teams justifies centralisation.
- Developers spend >25% of time on infrastructure — Survey your teams. If infrastructure tasks are consuming a quarter of their capacity, a platform can reclaim that time.
- Onboarding new developers takes >4 weeks — A golden-path platform with good templates and documentation can reduce this to 1 week.
- Your DevOps maturity is Level 3+ — You need a solid foundation (IaC, CI/CD, monitoring) before building a platform on top. See our DevOps Maturity Model for assessment.
- Consistency matters — If different teams using different tools and patterns creates compliance, security, or operational challenges.
Building Your Platform Team
A platform team should be staffed and managed as a product team, not an ops team:
Team Composition (Minimum Viable Platform Team)
- Platform Product Manager (can be part-time): Defines roadmap based on developer needs
- 2-3 Platform Engineers: Build and maintain the platform infrastructure
- 1 Developer Experience Engineer: Focuses on documentation, onboarding, and developer feedback
Operating Model
- Treat developers as customers: Run user research, satisfaction surveys, and feature requests
- Measure adoption, not availability: The platform's success metric is what percentage of teams use it voluntarily (target: >80%)
- Provide escape hatches: Teams must be able to deviate from the golden path when they have a legitimate reason. If they have to deviate >10% of the time, the platform has gaps.
- Iterate based on feedback: Ship small improvements weekly, not big-bang platform releases quarterly
The Platform Engineering Technology Landscape in 2026
| Category | Leading Tools |
|---|---|
| Service Catalogue | Backstage, Port, Cortex |
| Infrastructure Orchestration | Crossplane, Terraform Cloud, Pulumi |
| Kubernetes Management | Argo CD, Flux, Karpenter |
| CI/CD | GitHub Actions, GitLab CI, Dagger |
| Observability | Datadog, Grafana Stack, Honeycomb |
| Security | OPA/Kyverno, Wiz, Snyk |
| Developer Portal | Backstage, Humanitec, Kratix |
Get Started with Platform Engineering
If your development teams are drowning in infrastructure complexity, platform engineering is the path forward. Our DevOps consulting team helps organisations design and build internal developer platforms — from initial assessment through implementation to adoption. We also provide dedicated platform engineering teams for organisations that want to accelerate their platform journey. Book a free consultation to discuss your platform engineering strategy.
