Platform engineering is the practice of building and running an internal platform that software teams use to develop, deploy and operate their applications. The platform, often called an internal developer platform, packages infrastructure, deployment pipelines, security controls and common services into self-service tools and standard paths, so developers can get what they need without opening tickets or building everything themselves. A dedicated platform team treats it as a product, with the organization’s developers as its customers.
At a glance
- Platform engineering builds shared, self-service tooling for internal software teams.
- The internal developer platform commonly includes templates, CI/CD pipelines, environments, observability and access to cloud resources.
- Standard “paved” or “golden” paths make the recommended way the easiest way, while often allowing exceptions.
- It is a way to put DevOps into practice across many teams without each one building its own tooling.
- It is mainly relevant to organizations with several development teams; small teams may not need it.
What problem it solves
DevOps asked development teams to take more ownership of how their software is built, deployed and run. In many organizations that meant every team assembled its own pipelines, cloud configuration, monitoring and security checks. The result was duplicated effort, inconsistent practices and developers spending a large share of their time on infrastructure instead of features.
Platform engineering moves that shared work into one team and one platform. Developers get self-service access to environments, deployments and services through standard templates, and the platform team builds in security, compliance and cost controls once. The aim is faster delivery with less cognitive load on developers, and more consistent operations for the business.
How it works
Platform team. A team of engineers owns the platform as a product. It gathers requirements from development teams, prioritizes features and measures adoption and satisfaction.
Core building blocks. Platforms are typically assembled from existing tools: source control, continuous integration and continuous delivery (CI/CD) pipelines, infrastructure as code (IaC), container orchestration and container management, secrets management, observability and policy checks.
Self-service interface. Developers interact through a portal, command-line tools or templates. A new service can often be created from a template that already includes a repository, pipeline, monitoring and security scanning.
Golden paths. The platform offers recommended, supported ways to build common kinds of applications. Teams that follow them get the supported defaults; whether later changes to templates reach services already built from them depends on the platform’s update and migration mechanisms. Teams that need something different can usually diverge, with more responsibility.
Reliability. Platform teams often work closely with site reliability engineering (SRE) on availability targets and incident handling.
When it matters for buyers
- When the number of development teams grows. Duplicated tooling and inconsistent practices become expensive.
- When moving applications to the cloud or containers. A shared platform can standardize how teams use new infrastructure.
- When compliance or security requirements tighten. Building controls into the platform can be easier than enforcing them team by team.
- When choosing between building and buying. Platform as a service (PaaS), managed Kubernetes and developer portal products can reduce the amount you build.
- When redesigning the IT organization. Platform teams are a common feature of platform-based IT operating models.
Questions to ask vendors
These questions apply to vendors of developer portals, platform products and consultancies that help build platforms:
- Which parts of an internal developer platform does your product cover, and what do we still have to build or integrate?
- Which cloud providers, CI/CD tools and container platforms do you integrate with?
- How do templates and golden paths get updated, and how do existing services pick up changes?
- How are security scanning, policy checks and access controls built in?
- How is the product priced: per developer, per service, per cluster or by usage?
- How do you measure developer adoption and delivery improvements?
- If we stop using your product, what remains usable, and how portable are our templates and configurations?
How it differs from DevOps and SRE
DevOps is a culture and set of practices for bringing development and operations together. Site reliability engineering applies software engineering to keeping services reliable, with a focus on availability targets and incident response. Platform engineering focuses on building the shared tools and self-service paths that developers use. In practice the three overlap and often coexist: the platform makes DevOps practices easier to follow, and SRE helps keep the platform and the services on it reliable. For the monitoring part of a platform, see our application performance monitoring and observability overview.