Platform Engineering - the new role that replaces

In 2024, the term “Platform Engineering” appeared at the top of Gartner’s Top Technology Trends list. In 2025, it became one of the most frequently searched terms in the context of software engineering. Now, in 2026, organizations are massively investing in building Platform Engineering teams and Internal Developer Platforms. Does this mean the end of DevOps? Not exactly. It’s more of an evolution in the approach to software delivery, addressing real problems that have emerged in organizations practicing DevOps over the past years.

If you’re a Tech Lead wondering how to organize infrastructure for a growing team, a DevOps Engineer who’s felt that most of your time is spent answering the same developer questions, or a CTO looking for a way to accelerate delivery without expanding infrastructure teams - this article is for you.

Quick navigation

What is Platform Engineering?
DevOps vs Platform Engineering - key differences
Why are companies transitioning to Platform Engineering?
Internal Developer Platform (IDP) - what it is and how it works
Platform Engineer competencies - what do you need?
Tools in the Platform Engineering ecosystem
How to start with Platform Engineering in your organization
How EITT trains Platform Engineers
Frequently Asked Questions (FAQ)
Summary

What is Platform Engineering?

Platform Engineering is the discipline of designing and building tools and workflows that act as a self-service layer for development teams. The goal is to enable developers to independently manage the entire application lifecycle - from development, through deployment, to monitoring - without needing deep infrastructure knowledge.

According to the definition from Platformengineering.org (2025): “Platform Engineering is the discipline of designing and building toolchains and workflows that provide self-service capabilities for software engineers in the cloud-native era. Platform Engineers deliver an integrated product most often called an Internal Developer Platform (IDP) covering the operational needs of the entire application lifecycle.”

In practice, this means creating a dedicated team (Platform Team) whose clients are the development teams in the organization. This team builds and maintains an Internal Developer Platform - a set of tools, automation, and abstractions that allow developers to focus on delivering business value instead of struggling with infrastructure.

Key elements of Platform Engineering:

Internal Developer Platform (IDP) - central self-service platform
Golden Paths - recommended, tested paths for typical tasks
Self-service - developers don’t wait for the ops team
Developer Experience (DevEx) - focus on developer productivity and satisfaction
Platform as Product - the platform is treated as a product for internal users

DevOps vs Platform Engineering - key differences

Many consider Platform Engineering as “DevOps done right” or “the next evolution of DevOps.” But is it actually a replacement or an extension?

Theoretical concept vs practical implementation

DevOps was originally a cultural philosophy: “You build it, you run it”. Every development team was supposed to be responsible for the entire lifecycle of their application - from code to production. The problem? In organizations with dozens or hundreds of development teams, this model doesn’t scale.

Platform Engineering emerged as a response to DevOps implementation problems in large organizations. Instead of forcing each team to build their own CI/CD, manage infrastructure and monitoring, a central platform is created that standardizes and automates these processes.

Comparison table: DevOps vs Platform Engineering

Aspect	DevOps	Platform Engineering
Philosophy	Each team manages the entire application lifecycle	Dedicated team builds platform for other teams
Responsibility	Distributed (each team for themselves)	Centralized (Platform Team for tools)
Scaling	Difficult - each team duplicates efforts	Easier - reusable platform
Cognitive Load	High - dev must know infra	Low - dev uses abstractions
Standardization	Weak - each team does it their way	Strong - Golden Paths
Tooling	Fragmented - each chooses their own	Unified - through the platform
Time to Market	Slower - each team from scratch	Faster - ready-made components
Onboarding	Difficult - each team differently	Easier - one platform
Maintenance	Distributed - each team separately	Central - Platform Team
Developer Experience	Inconsistent	Designed and optimized

Analogy: restaurant vs food delivery platform

DevOps is like running your own restaurant. You have full control - you choose suppliers, design the menu, cook, sell, deliver. If you have 1-3 locations, you can manage. But when you want to expand to 50 restaurants, each managed independently, chaos appears, duplication of efforts, and lack of standards.

Platform Engineering is building a food delivery platform for your restaurants. You centralize suppliers, logistics, payment systems, mobile apps. Each restaurant (dev team) still creates their unique menu (features), but uses ready-made infrastructure. Scaling from 3 to 50 locations becomes feasible.

Does Platform Engineering replace DevOps?

No. Platform Engineering doesn’t replace DevOps - it implements its principles in a scalable way.

DevOps as a culture (collaboration, automation, monitoring, feedback loops) remains relevant. But the way of implementation changes. Instead of each team building their own tools, we create a dedicated team that builds a platform allowing other teams to practice DevOps more effectively.

It can be put this way: Platform Engineering allows development teams to reap the benefits of DevOps without having to be infrastructure experts.

Why are companies transitioning to Platform Engineering?

Organizations don’t invest in Platform Engineering out of boredom. They transition to this model because they encountered specific problems that couldn’t be solved with “classic” DevOps. Here are the most common reasons:

1. Cognitive Overload of developers

The State of DevOps 2025 report showed that in organizations practicing the “You build it, you run it” model, developers spend an average of 40-50% of their time on tasks related to infrastructure, deployment, and operations. This means half their time doesn’t go toward delivering business value.

A frontend developer must know: Docker, Kubernetes, Terraform, AWS/Azure/GCP, CI/CD pipelines, monitoring tools, security scanning, secrets management… The list grows every year. This is cognitive overload that slows down development and reduces job satisfaction.

2. Duplication of efforts and lack of standards

In an organization with 20 development teams, each builds their own:

CI/CD pipeline (20 different implementations)
Deployment workflow (20 different approaches)
Monitoring and alerting (20 different stacks)
Secrets management (20 different solutions)

Result? Enormous duplication of work, inability to reuse solutions, difficulties in onboarding (each team different), problems with compliance and security (impossible central management).

3. Slow Time to Market for new teams

A new development team or new project needs weeks or months to “start”. They must build infrastructure, CI/CD, monitoring from scratch. Consequence? The first 2-4 weeks are not about delivering features, but setup.

In organizations with Platform Engineering, a new team can start delivering value from day one - the platform provides ready-made infrastructure, you just need to use the self-service portal.

4. Difficulty managing compliance and security

When each team manages infrastructure independently, centrally enforcing security and compliance policies becomes impossible. Examples:

Team A uses old library versions with security vulnerabilities
Team B keeps secrets in Git repository
Team C doesn’t have GDPR-compliant logging enabled

Platform Engineering solves this through standards enforced by the platform: all teams use the same, secure flow.

5. Inefficient use of infrastructure experts

In the DevOps model, experts in Kubernetes, Cloud, Security are scattered across teams. Each team has 0.5-1 FTE Senior DevOps Engineer solving the same problems that others solved yesterday.

In Platform Engineering, these experts create a dedicated Platform Team and build solutions reusable by everyone. Instead of 20 people solving the same problem 20 times, you have 5 people who solve the problem once and make the solution available to 20 teams.

6. Developer Experience as competitive advantage

The best engineers want to work in organizations where they can be productive from day one, not spend weeks fighting with YAML. Developer Experience has become a factor in the war for talent.

Companies like Spotify, Netflix, Google have publicly shared how they invest in Internal Developer Platforms precisely to attract talent.

Data confirming the trend

Gartner predicts that by 2027, 80% of organizations will have dedicated Platform Engineering teams (up from 35% in 2024)
State of DevOps Report 2025: organizations with Internal Developer Platforms achieve 2.5x faster deployment frequency and 50% lower change failure rate
Stack Overflow Survey 2025: 73% of developers indicated “quality of internal tooling” as a top 3 factor affecting job satisfaction

Internal Developer Platform (IDP) - what it is and how it works

The Internal Developer Platform is the heart of Platform Engineering. But what exactly is an IDP and how does it work in practice?

IDP definition

An Internal Developer Platform (IDP) is an abstraction layer over infrastructure and operational tools that allows developers to independently manage the entire application lifecycle without needing to directly interact with underlying complexity.

More simply: IDP is a set of integrated tools and automation that allow a developer to perform all operations from “create new service” to “deploy to production and monitor” on one interface (web portal, CLI, or Git-based workflow).

Key IDP components

A typical IDP consists of the following layers:

1. Developer Portal (Service Catalog) Central point of entry for developers. Examples: Backstage, Port, Cortex.

What it offers:

Catalog of all services in the organization (owner, stack, documentation)
Self-service actions: “Create new microservice”, “Provision database”, “Deploy to staging”
Technical documentation consolidated in one place
Dashboards: deployment status, infrastructure costs, code quality metrics

2. Infrastructure Orchestration Layer that translates high-level developer intentions (“I want a PostgreSQL database”) into concrete infrastructure changes. Examples: Crossplane, Terraform Cloud, Pulumi.

Developer clicks “Create database” in the portal, the platform automatically:

Provisions RDS instance in AWS
Configures security groups
Creates secrets with credentials
Sets up backups and monitoring
Provides connection string

3. CI/CD & Deployment Unified pipelines for all teams. Examples: GitLab CI, GitHub Actions, ArgoCD, Flux.

Golden Path for deployment:

git push → automated tests → security scan → build container → deploy to dev → automated smoke tests → promote to staging → manual approval → deploy to prod → health checks

Everything configured upfront - developer doesn’t write YAML, just uses the ready-made flow.

4. Observability & Monitoring Central tools for monitoring, logging, and alerting. Examples: Datadog, New Relic, Grafana, ELK Stack.

The platform automatically configures:

Application instrumentation (automatic metrics)
Log aggregation
Distributed tracing
Standard dashboards for each service
Pre-configured alerts

5. Security & Compliance Layer Enforcing security policies at the platform level. Examples: OPA (Open Policy Agent), Kyverno.

Automatic checks:

No secrets in code (enforced pre-commit)
Container scanning for vulnerabilities
Network policies (service A can only connect to service B)
Compliance as code (GDPR, SOC2)

6. Developer Experience Layer Tools that make working with the platform pleasant:

CLI tools (platform create service, platform deploy)
IDE integrations
Documentation and tutorials
Slack/Teams bots for self-service
Internal Stack Overflow for Q&A

What does a typical workflow in IDP look like?

Scenario: Developer wants to create a new microservice

Without IDP (classic DevOps):

Copy template repository (if it exists, if not - start from scratch)
Write Dockerfile
Write Kubernetes manifests (Deployment, Service, Ingress)
Configure CI/CD pipeline in Jenkins/GitLab (several hundred lines of YAML)
Provision infrastructure in AWS through Terraform (write module, apply)
Configure monitoring (Prometheus rules, Grafana dashboard)
Setup log aggregation
Configure alerting
Write documentation about where everything is and how it works
Time: 2-4 weeks (if you know what you’re doing)

With IDP:

Go to Developer Portal
Click “Create New Service”
Fill out form: Name, Language (Python/Java/Go/Node), Type (API/Worker/Frontend)
Click “Create”
Platform generates:
- Repository with template code
- All CI/CD pipelines
- Infrastructure (pre-configured)
- Monitoring and alerting
- Documentation in Service Catalog
Developer clones repo, writes business logic, does git push
Automatic deployment to dev environment
Time: 15 minutes

Golden Paths - recommended paths

A key concept of IDP is Golden Paths - pre-approved, well-tested ways to perform typical tasks.

Example Golden Paths:

“Python API Service” - template + CI/CD + infrastructure for standard REST API in Python
“React Frontend” - template + CI/CD + CDN deployment + monitoring
“Batch Job” - template for cron jobs on Kubernetes

Golden Path is not enforced - a developer can deviate and do it their way if they have a reason. But 90% of cases fit into Golden Paths and then everything works out-of-the-box.

Platform as a Product - IDP is not a project

Key: IDP is not a one-time project. It’s an internal product whose users are developers.

This means:

Product thinking: roadmap, priorities, user research
Customer feedback loops: regular feedback collection from development teams
Metrics: developer satisfaction, time to first deployment, adoption rate
Continuous improvement: platform evolves with organizational needs
Support: Platform Team as “customer success” for developers

The best platforms have dedicated Product Managers who treat developers as customers and optimize the platform for their needs.

Platform Engineer competencies - what do you need?

Platform Engineer is not a new name for DevOps Engineer. It’s a separate role with a unique set of competencies. If you’re considering a career path in Platform Engineering or recruiting for a Platform Team, here’s what you need.

Required technical competencies

1. Infrastructure as Code (IaC) - expert level

Platform Engineers spend most of their time writing code that defines infrastructure. You must be fluent in:

Terraform (most popular) or Pulumi
Principles of designing reusable modules
State management, workspaces
Testing IaC (Terratest)

2. Kubernetes - very good knowledge

Most IDPs are based on Kubernetes. Required knowledge:

K8s architecture (control plane, nodes, networking)
Custom Resource Definitions (CRDs)
Operators pattern
Helm charts
GitOps (ArgoCD, Flux)
Multi-cluster management
K8s security (RBAC, network policies, pod security)

3. Cloud Platforms - practical knowledge

Working with at least one cloud provider at advanced level:

AWS: EKS, RDS, S3, IAM, VPC, CloudFormation
Azure: AKS, managed databases, networking
GCP: GKE, Cloud SQL, networking

Plus understanding of multi-cloud concepts and abstractions (e.g., through Crossplane).

4. CI/CD - design and optimization

Not configuring a single pipeline, but designing a CI/CD system for hundreds of services:

GitLab CI / GitHub Actions / Jenkins - advanced
Artifact management (Artifactory, Harbor)
Security scanning in pipeline (SAST, DAST, container scanning)
Deployment strategies (blue-green, canary, progressive delivery)
Pipeline as code - reusable templates

5. Observability - full stack

Designing observability for the entire organization:

Metrics: Prometheus, Thanos, Cortex
Logging: ELK, Loki, Splunk
Tracing: Jaeger, Tempo
Visualization: Grafana
Alerting: Alertmanager, PagerDuty
Cost monitoring: Kubecost, Cloud cost tools

6. Programming / Scripting - required

Platform Engineering is largely software engineering. You must be able to program:

Python or Go - most popular languages in PE
Bash/Shell scripting
API design
Code testing (unit tests, integration tests)
Code review and best practices

You write: automation scripts, Kubernetes operators, custom tooling, API integrations, internal CLI tools.

7. Platform Tools - specialized knowledge

Tools specific to Platform Engineering:

Backstage - most popular developer portal
Crossplane - Kubernetes-native infrastructure orchestration
ArgoCD - GitOps continuous delivery
OPA (Open Policy Agent) - policy as code
Service Mesh (Istio, Linkerd) - for advanced use cases

Non-technical competencies - equally important

1. Product Mindset

The platform is a product. You must think like a Product Manager:

Who are your users (developers)?
What are their pain points?
How to measure platform success?
How to prioritize features on the roadmap?
How to collect feedback and iterate?

2. Developer Empathy

You must understand developer experience:

Why do developers hate writing YAML?
What makes onboarding frustrating?
What friction points slow down their work?
What makes a tool intuitive vs confusing?

The best Platform Engineers are often former developers who understand problems firsthand.

3. API Design & Abstractions

Designing good abstractions is an art. The platform must:

Hide complexity but not limit flexibility
Have intuitive API (whether web portal, CLI, or YAML spec)
Provide “escape hatches” for advanced use cases
Be consistent - similar operations work similarly

4. Technical Writing & Documentation

No one will use the platform if there’s no good documentation:

Getting started guides
Tutorials for typical scenarios
Reference documentation
Runbooks for troubleshooting
Architecture decision records (ADRs)

5. Collaboration & Communication

Platform Team works with every team in the organization:

Gathering requirements from various stakeholders
Communicating trade-offs (security vs convenience)
Training and enablement (workshops, office hours)
Managing expectations (what will be in the roadmap, what won’t)
Building buy-in for the platform

Typical Platform Team structure

In an organization with 100-200 developers, a typical Platform Team is 4-8 people:

Roles:

1-2 Platform Architects - strategic direction, high-level design
3-5 Platform Engineers - building and maintaining platform
1 Product Manager (optional but recommended) - roadmap, prioritization
1 Technical Writer (optional) - documentation

In larger organizations (500+ devs) there may be several sub-teams:

Infrastructure Platform Team
Developer Experience Team
Security & Compliance Platform Team

Development path: from DevOps to Platform Engineer

If you’re a DevOps Engineer and want to transition to Platform Engineering:

What you already have:

Good knowledge of infrastructure, CI/CD, Kubernetes
Automation skills
Understanding of deployment and operations

What you must develop:

Programming skills - especially Python or Go
Product thinking - thinking about platform as a product
API design - designing intuitive abstractions
Platform-specific tools - Backstage, Crossplane
Developer empathy - understanding developers’ perspective
Scale mindset - solutions must work for 100 teams, not 1

Recommended steps:

Learn programming in Python/Go (if you don’t already)
Build proof-of-concept: small internal tool for your team
Collect feedback, iterate
Learn Backstage - set up locally, integrate with your infrastructure
Read the book “Team Topologies” (fundamentals of organizing Platform Teams)
Follow leaders in the PE space: Humanitec, Spotify Engineering Blog, platformengineering.org

Tools in the Platform Engineering ecosystem

Platform Engineering is a young discipline but the tool ecosystem is developing rapidly. Here’s an overview of the most important categories and tools.

1. Developer Portals / Service Catalogs

Central point of entry for developers to the platform.

Backstage (Spotify, open-source)

Most popular developer portal
Plugin architecture - hundreds of community plugins
Software Catalog - central registry of all services
Software Templates - scaffolding for new projects
TechDocs - documentation integrated with code
Adopters: Spotify, Netflix, American Airlines, IKEA

Port (commercial)

Cloud-native developer portal
No-code/low-code configuration
Strong focus on self-service actions
Built-in metrics and scorecards
Adopters: scale-ups, mid-market companies

Cortex (commercial)

Service catalog + scorecards
Strong integrations with observability tools
Focus on reliability and ownership
Adopters: DoorDash, SoulCycle, Grammarly

2. Infrastructure Orchestration

Abstraction layer over cloud providers.

Crossplane (CNCF, open-source)

Kubernetes-native control plane for infrastructure
Providers for AWS, Azure, GCP, 50+ others
Composition - build your own abstractions
GitOps friendly
Integrates great with Backstage

Terraform Cloud / Terraform Enterprise (HashiCorp)

Managed Terraform with collaboration features
Remote state management
Policy as code (Sentinel)
Private registry for modules

Pulumi (open-source + commercial)

IaC in real programming languages (Python, TypeScript, Go)
Better developer experience than HCL
Strong typing, IDE support
Pulumi Cloud for state and collaboration

3. GitOps & Continuous Delivery

Automating deployments in a declarative way.

ArgoCD (CNCF, open-source)

GitOps continuous delivery for Kubernetes
Declarative setup
Automated sync with Git repositories
Multi-cluster support
Web UI for visibility

Flux (CNCF, open-source)

GitOps toolkit for Kubernetes
More “Kubernetes-native” than Argo (CRDs)
Helm support
Image automation

Spinnaker (open-source)

Multi-cloud continuous delivery
Advanced deployment strategies (canary, blue-green)
Used at Netflix, Airbnb

4. Policy & Governance

Enforcing security and compliance policies.

Open Policy Agent (OPA) (CNCF, open-source)

Policy as code in Rego language
Integrations with K8s, Terraform, CI/CD
Use cases: RBAC, compliance, security policies

Kyverno (CNCF, open-source)

Kubernetes-native policy management
Policies written in YAML (easier than Rego)
Validation, mutation, generation policies

Checkov (open-source)

Static analysis for IaC (Terraform, CloudFormation, K8s)
Hundreds of pre-built policies for security best practices

5. Secrets Management

Secure secrets management.

HashiCorp Vault

Industry standard for secrets management
Dynamic secrets
Encryption as a service
Rich integrations

External Secrets Operator (open-source)

Kubernetes operator that synchronizes secrets with external vaults
Integrations: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault

Sealed Secrets (open-source)

Encrypt secrets to be able to commit to Git
Simpler solution for smaller organizations

6. Platform Engineering Frameworks

Complete platforms / reference implementations.

Humanitec (commercial)

Platform Orchestrator as a Service
Score spec - workload specification standard
Managed control plane for IDP
Quick start for organizations without time to build from scratch

mia-platform (commercial)

Complete Internal Developer Platform
Console + Kubernetes-native runtime
Strong in European market

Kratix (open-source)

Framework for building platforms
“Platform as a Product” principles built-in
Promises - high-level abstractions for users

7. Cost Management

Visibility and optimization of infrastructure costs.

Kubecost (open-source + commercial)

Real-time cost visibility for Kubernetes
Cost allocation per team/service/label
Recommendations for optimization

OpenCost (CNCF, open-source)

Open standard for K8s cost monitoring
Vendor-neutral
Integrations with cloud providers

8. Developer CLI Tools

Command line tools for productivity.

Garden (open-source)

Local development and testing for Kubernetes apps
Fast feedback loops

Tilt (open-source)

Smart rebuilds and hot reloading for K8s
Define multi-service workflows

Skaffold (Google, open-source)

Automated build, push, deploy workflow
Integrates with kubectl, Helm, Kustomize

Stack recommendations by organization size

Startup / Small Team (< 20 devs):

Portal: Backstage (self-hosted)
IaC: Terraform
GitOps: ArgoCD
Secrets: External Secrets + cloud-native solutions
Policy: Checkov in CI/CD
Setup time: 2-4 weeks

Mid-size (20-100 devs):

Portal: Backstage or Port
IaC: Crossplane + Terraform
GitOps: ArgoCD + Flux
Secrets: Vault
Policy: OPA
Observability: Prometheus + Grafana + Loki
Setup time: 2-3 months

Enterprise (100+ devs):

Portal: Backstage (customized) or commercial solution
IaC: Crossplane
GitOps: ArgoCD (multi-cluster)
Secrets: Vault
Policy: OPA + Kyverno
Observability: Full stack (Datadog/Dynatrace or Prometheus ecosystem)
Platform Orchestrator: Humanitec or custom
Setup time: 6-12 months for mature platform

How to start with Platform Engineering in your organization

You’re deciding to invest in Platform Engineering. Great. But where to start? Here’s a pragmatic roadmap.

Phase 0: Assessment and Planning (2-4 weeks)

Step 1: Diagnosis - do you need Platform Engineering?

Not every organization needs a full IDP. Platform Engineering makes sense if:

You have 5+ development teams (below that, simple scripts often suffice)
You see duplication of efforts in infrastructure setup
Onboarding new teams/projects is slow
Developers spend a lot of time on ops instead of code
Lack of standards leads to security/compliance problems

Step 2: Collect data

Organize interviews with:

Team Leads / Engineering Managers - what are the bottlenecks?
Senior Developers - what frustrates them in current setup?
DevOps Engineers - what do they spend most time on?
Security / Compliance - what are the risks in current state?

Key questions:

How long does it take to setup a new project from zero to first deployment?
Which operations do developers have to wait for ops team?
Where are the biggest friction points in developer workflow?
What are the recurring tickets to ops team?

Step 3: Define success metrics

Before you start building, determine how you’ll measure success:

Time to First Deployment for new service (target: < 1 day)
Lead Time for Changes - from commit to production (target: < 1h)
Mean Time to Recovery (MTTR) - how fast recovery after incident (target: < 30 min)
Developer Satisfaction Score - regular surveys (target: 7+/10)
Self-service adoption rate - % of operations performed by devs without ops help (target: 80%+)

Step 4: Start small - choose MVP scope

Don’t build the entire platform at once. Choose one Golden Path for MVP.

Example MVP scope:

Use case: “Deploy new Python API microservice”
Features:
- Self-service project creation (Backstage template)
- Automated CI/CD pipeline (GitLab CI or GitHub Actions)
- Deploy to Kubernetes dev cluster
- Basic monitoring (Prometheus + Grafana)
- Documentation in Service Catalog
Out of scope (for later):
- Provisioning infrastructure (databases, queues)
- Multi-environment promotion (dev → staging → prod)
- Advanced observability (tracing, log aggregation)
- Policy enforcement

MVP should be ready in 4-8 weeks and show value.

Phase 1: Foundation (2-3 months)

Step 5: Build platform foundations

5a. Developer Portal

Setup Backstage:

Deploy Backstage instance (Kubernetes or cloud hosting)
Integration with Git (GitHub/GitLab) - import existing services
Creating Software Catalog - registry of all services
Basic documentation - how to use the portal

5b. Golden Path Template

Create first software template:

Repository template for Python API (or dominant language in organization)
Includes: linting, testing, containerization (Dockerfile)
README with clear instructions

5c. CI/CD Automation

Setup pipeline template that automatically:

Runs tests
Builds Docker image
Pushes to container registry
Deploys to dev environment

5d. Infrastructure Baseline

Setup basic infrastructure:

Kubernetes cluster for dev environment
Basic monitoring (Prometheus + Grafana)
Secrets management (External Secrets or Vault)

Step 6: Onboard pilot team

Choose one team as early adopter:

Preferably team with open mindset and non-critical product
Onboard them to the platform
Hand-hold through first project
Collect feedback intensively

Step 7: Iterate based on feedback

After 2-4 weeks of use by pilot team:

What works well?
Where are friction points?
What is missing?
Iterate and improve

Phase 2: Expansion (3-6 months)

Step 8: Add more Golden Paths

Based on organizational needs, add templates for:

Frontend apps (React, Angular)
Background workers / cron jobs
Data pipelines
Other dominant patterns in organization

Step 9: Extend self-service capabilities

Add ability to self-service provision:

Databases (PostgreSQL, MySQL, Redis)
Message queues (RabbitMQ, Kafka)
Object storage (S3)

Through:

Crossplane for Kubernetes-native abstractions
Or Terraform modules with self-service wrapper

Step 10: Multi-environment support

Extend platform to full flow:

Dev environment (automatic deploy on push)
Staging environment (manual promotion)
Production environment (manual promotion with approval)

Step 11: Enhanced observability

Add complete observability stack:

Central logging (ELK or Loki)
Distributed tracing (Jaeger)
Alerting (Alertmanager + PagerDuty/Slack)
Standard dashboards for each service

Step 12: Policy enforcement

Implement policies:

Security scanning in CI/CD (container scanning, SAST)
OPA policies for Kubernetes (resource limits, no privileged containers)
Compliance checks (e.g., all services must have owner label)

Phase 3: Scale & Maturity (6-12 months)

Step 13: Organization-wide rollout

Onboard all teams to the platform
Training programs and documentation
Office hours - regular Q&A sessions with Platform Team
Champions in each team - internal advocates

Step 14: Advanced features

Multi-cluster support (separate clusters per environment or per team)
Service mesh (Istio/Linkerd) for advanced networking
Advanced deployment strategies (canary, blue-green via Flagger)
Cost monitoring and optimization (Kubecost)

Step 15: Platform as Product maturity

Formal product management for the platform
Roadmap published and shared
Regular surveys - developer satisfaction
Public metrics - platform reliability, usage stats
SLAs for Platform Team responsiveness

Common pitfalls - what to avoid

❌ Building detached from users Platform Team builds “perfect platform” without input from developers. Result: no one wants to use it. ✅ Solution: Co-design with representative developers. Regular show-and-tells. Beta testing.

❌ Over-engineering from the start Trying to build perfect platform day 1. Analysis paralysis, never ship MVP. ✅ Solution: Start simple. One Golden Path. Ship in 4-8 weeks. Iterate.

❌ Forcing adoption top-down “From next month everyone must use the platform.” Developers are resistant, platform seen as bottleneck. ✅ Solution: Make platform so good that developers WANT to use it. Voluntary adoption at first. Show value.

❌ Lack of documentation Platform exists, but no one knows how to use it. ✅ Solution: Documentation BEFORE rollout. Getting started guides. Video tutorials. Internal Stack Overflow.

❌ Platform Team as gatekeepers All requests go through Platform Team. No real self-service. ✅ Solution: True self-service from the start. Platform Team unblocks and improves platform, doesn’t execute requests.

❌ Ignoring legacy Focus only on new projects. Existing services remain outside the platform. ✅ Solution: Migration strategy for existing services. Can be gradual (partial adoption).

How EITT trains Platform Engineers

Platform Engineering is a young discipline but demand for specialists is growing rapidly. EITT, as a leader in IT training in Poland, has adapted its offering to this trend.

Platform Engineering path at EITT

EITT offers a comprehensive development path for people aiming for a Platform Engineer role or organizations building Platform Teams.

Module 1: Foundations (5 days)

Technical basics essential for Platform Engineering:

Kubernetes Advanced - architecture, operators, CRDs (3 days)
Infrastructure as Code with Terraform - reusable modules, testing (2 days)

For whom: DevOps Engineers, Infrastructure Engineers who want to transition to Platform Engineering

Module 2: Platform Tools & Practices (5 days)

Tools specific to PE:

Backstage - Developer Portal in practice (2 days)
Crossplane - Kubernetes-native infrastructure orchestration (2 days)
GitOps with ArgoCD and Flux (1 day)

For whom: People after Module 1 or with K8s + Terraform experience

Module 3: Building Internal Developer Platforms (3 days)

End-to-end design and implementation of IDP:

Platform as Product principles
API design and abstractions for developers
Golden Paths - design patterns
Observability and monitoring for platforms
Security and policy enforcement (OPA)
Metrics - how to measure platform success

For whom: Senior Engineers, Architects designing IDP

Module 4: Platform Team Leadership (2 days)

For Platform Team leaders:

Organizing Platform Team - roles and structure
Product management for internal platforms
Stakeholder management
Building buy-in for the platform in organization
Roadmapping and prioritization
Developer relations and enablement

For whom: Engineering Managers, Tech Leads, Architects

Training format

Closed trainings (most popular)

For organizations building their own IDP:

Program adapted to your stack (AWS/Azure/GCP, specific tools)
Hands-on workshop - we build a piece of your platform during training
Follow-up consultations after training (3 months)
For teams of 4-12 people

Open trainings

Calendar dates for individual participants:

Every quarter for each module
Online or on-site (Warsaw)
Networking with other Platform Engineers from the industry

Consulting and Mentoring

For organizations building IDP:

Architecture review - audit of your design
Implementation support - mentoring during construction
Code review - review of your Crossplane compositions, Backstage plugins
Retainer packages - access to experts on a daily basis

Trainers

Trainings conducted by practitioners who built IDPs in Polish and foreign companies:

Experience in organizations of 50-500+ developers
Contributors to open-source Platform Engineering projects (Backstage, Crossplane)
Active in community - conferences, meetups

What you get

Hands-on experience - we build things during training, not just theory
Code examples and templates - starter templates for Backstage, Crossplane compositions
Architecture blueprints - reference IDP architectures
Decision frameworks - how to choose tools, how to design abstractions
Access to lab environment - 30 days after training for exercises
Private Slack - access to EITT Platform Engineers community

Success stories

Case: Fintech company (120 devs) - from chaos to platform

Company with 25 teams, each managing infrastructure independently. Onboarding new project: 4-6 weeks.

What they did:

Team of 4 people went through Platform Engineering path at EITT (3 months)
Built MVP IDP in 8 weeks (Backstage + ArgoCD + Crossplane)
Onboarded 5 pilot teams in 2 months
Full rollout in 6 months

Results (year after implementation):

Time to first deployment: from 4 weeks to 3 hours
Self-service adoption: 85% (from 0%)
Developer satisfaction: increase from 4.2/10 to 7.8/10
Ops team size: no growth despite 40% more services

Case: Software house (200+ devs) - standardization and compliance

Company with enterprise contracts requiring certifications (ISO 27001, SOC2). Lack of standards prevented audits.

What they did:

Platform Team of 6 people trained at EITT
Built IDP with policy enforcement (OPA)
All deployments through platform = automatic compliance

Results:

ISO 27001 audit: passed first time (previously 3 attempts)
Security incidents: -70% in first year
Time spent on compliance: -60% (automated checks)

Free resources from EITT

Not ready for full training? Start with:

Webinar “Platform Engineering 101” - monthly, free, online
EITT Blog - articles and case studies from Platform Engineering
Newsletter “Cloud Native Poland” - trends and tools
Meetup Platform Engineering Poland - organized by EITT alumni

Frequently Asked Questions (FAQ)

1. Is Platform Engineering only for large companies?

Short answer: No, but depends on the definition of “large”.

Full-scale Internal Developer Platform makes sense from about 5+ development teams (30-50 developers). Below this threshold, the costs of building and maintaining IDP often outweigh the benefits - simpler scripts and documentation may suffice.

But you can start “lean”:

Startup with 10-15 devs can start with Backstage as Service Catalog + some automation scripts
This provides benefits (central documentation, standards) without full IDP overhead
As organization grows, platform naturally evolves

2. How much does building an IDP cost?

Investment breakdown:

Time:

MVP (1 Golden Path): 1-2 FTE for 2-3 months
Mature platform: 3-6 FTE for 6-12 months
Ongoing maintenance: 1 FTE per every 20-30 developers using the platform

Tooling costs:

Open-source stack (Backstage, ArgoCD, Crossplane): $0 licensing (only hosting and time)
Commercial tools (Port, Humanitec): $10k-$100k+/year depending on scale
Cloud infrastructure: depends on scale, but IDP itself is 5-10% of overall cloud costs

ROI:

Organizations report break-even after 6-12 months
Main savings: faster time to market, less duplication of work, reduction in ops team needs

3. Does IDP mean vendor lock-in?

Depends on choices.

Open-source IDP stack (Backstage, Crossplane, ArgoCD) minimizes lock-in:

Everything hosted at your place
You can migrate components independently
Community ownership

Commercial platforms (Humanitec, Port) have some lock-in but offer:

Faster time to value (weeks vs months)
Managed and supported
Good for organizations without capacity to build from scratch

Mitigation: Use open standards where possible (Score spec, OpenAPI) and avoid vendor-specific APIs in core abstractions.

4. What about legacy applications? Do they also have to be on the platform?

Pragmatic answer: Not immediately.

Typical strategy:

New projects: Must use platform from day 1 (full benefits)
Actively developed legacy apps: Gradual migration (e.g., only CI/CD first, then deployment)
Maintenance-only legacy: Can remain outside platform if migration cost > benefits

Key decision: Platform doesn’t enforce one way. Good IDP allows “partial adoption” - team can use only part of the platform.

5. Will DevOps Engineers lose their jobs because of Platform Engineering?

No - roles are evolving.

DevOps Engineers don’t disappear, they transform into Platform Engineers or specialize deeper.

Option 1: Join Platform Team

You build the platform instead of managing infrastructure for specific projects
Greater impact (your work affects all teams)
Development toward software engineering and product thinking

Option 2: Specialization

SRE (Site Reliability Engineering) - focus on reliability of large systems
Security Engineering - specialization in security and compliance
Cloud Architecture - designing systems in the cloud

What actually changes: less “toil” (repetitive operational work), more engineering and innovation.

6. How long does it take to build an IDP?

Realistic timeline:

MVP (1 Golden Path, base features): 2-3 months with small team (2-3 people)
Functional platform (multiple Golden Paths, self-service): 6-9 months
Mature platform (full features, org-wide adoption): 12-18 months

Factors affecting timeline:

Starting point - do you already have K8s, CI/CD or from scratch?
Team experience - does team know tools or must learn?
Organizational complexity - single stack or multi-cloud, legacy?
Build vs buy - open-source (longer) or commercial platform (faster)?

Tip: Don’t wait for “perfect platform” to start rollout. Ship MVP, collect feedback, iterate.

7. Who should “own” the platform - engineering or IT ops?

Best practice: Engineering organization, product model.

Platform Engineering belongs to Engineering, not IT/ops, because:

Platform is a product for developers - needs product thinking
Close collaboration with users - Platform Team sits with engineering, not in a silo
Continuous evolution - platform must evolve with engineering needs, not be an IT project

Organization:

Platform Team as autonomous team in Engineering
Reports to: Head of Engineering or CTO
Collaborates with: Infrastructure, Security, IT - but not subordinate to them

Analogy: Internal Developer Platform is like Figma for designers - no one would say Figma should be managed by IT support.

Summary

Platform Engineering is not a buzzword and not another fad in IT. It’s a pragmatic response to real problems that appeared in organizations practicing DevOps at large scale: cognitive overload of developers, duplication of efforts, slow time to market, compliance problems.

Key takeaways from this article:

1. Platform Engineering doesn’t replace DevOps - it evolves the way of its implementation DevOps as a culture remains relevant. But the way of implementation changes. Instead of each team building their own tools, we create a dedicated Platform Team that builds an Internal Developer Platform for everyone.

2. Internal Developer Platform is a product, not a project The best IDPs are treated as products with product managers, roadmaps, user research, and continuous improvement. Platform Team is an internal product team whose clients are developers.

3. Golden Paths - key concept 90% of developer needs fit into standard patterns. Well-designed Golden Paths allow most teams to be productive without specialized knowledge. The remaining 10% have escape hatches for custom needs.

4. Developer Experience as competitive advantage The best engineers choose organizations where they can be productive. An IDP that allows deploying a new service in 15 minutes instead of 2 weeks is a significant factor in the war for talent.

5. Start small, iterate Don’t build a perfect platform right away. Ship MVP with one Golden Path in 2-3 months. Onboard pilot team. Collect feedback. Iterate. Scale gradually.

6. Platform Engineer competencies are a mix of software engineering + infrastructure + product thinking This is not a renamed DevOps Engineer role. It’s a software engineering position focused on building a product for internal customers. Requires programming, API design, user empathy.

7. Tool ecosystem is maturing rapidly Backstage has become the de facto standard for developer portals. Crossplane for infrastructure orchestration. ArgoCD for GitOps. You don’t have to build everything from scratch - the ecosystem exists.

What next?

If you’re convinced that Platform Engineering is the direction for your organization:

For Tech Leads and Architects:

Conduct assessment - collect data on current pain points
Organize workshop with teams - what frustrates them in current workflow?
Define MVP scope - one Golden Path to start
Begin proof of concept

For DevOps Engineers:

Develop programming skills - Python or Go
Set up Backstage locally and experiment
Read Team Topologies
Consider Platform Engineering training at EITT

For CTO/Engineering Directors:

ROI assessment - does organization scale justify investment in IDP?
Budget allocation - can you allocate 2-4 people to Platform Team?
Long-term vision - how does platform support business goals?
Training investment - team needs upskilling

Future of Platform Engineering

Platform Engineering is not a fad that will pass in 2027. It’s a long-term evolution in the way of building and delivering software. Observed trends for the next 2-3 years:

1. AI-powered platforms Internal Developer Platforms with AI assistants that:

Suggest optimal deployment strategies
Auto-diagnose production problems
Generate infrastructure code from natural language descriptions

2. Platform-as-a-Service for smaller companies We’ll see more managed IDP offerings - companies with 20-50 devs that don’t have capacity to build their own IDP will be able to buy “platform-as-a-service”.

3. Standardization across industry Standards like Score (workload specification) will make migration between platforms easier. Less vendor lock-in.

4. Platform Engineering as career path Dedicated roles will appear: Platform Product Manager, Platform Architect, Platform SRE. Universities and certifications will start offering specializations.

5. Metrics and benchmarks Industry will develop standard metrics for platform effectiveness (similar to DORA metrics for DevOps). It will be possible to compare platforms and track improvement.

Platform Engineering gives development teams what DevOps promised but didn’t always deliver at large scale: autonomy, speed, and focus on business value instead of infrastructure complexity. If your organization is struggling with problems we described at the beginning of this article, perhaps it’s time to consider building an Internal Developer Platform.

At EITT we train teams that are building the future of software delivery. Over 500 experts, 2500+ trainings annually, experience with projects from startups to enterprise. If you want to learn more about our Platform Engineering programs or need consultation on how to start in your organization - contact us.

The future belongs to organizations that treat developer experience as a competitive advantage. Is your organization ready?

Develop your skills

Want to deepen your knowledge in this area? Check out our training led by experienced EITT instructors.

➡️ Platform Engineering - Internal Developer Platform (IDP) and Backstage — EITT training