What is platform engineering? Internal developer platforms
Platform engineering is the practice of building internal platforms and tooling — often called an internal developer platform — that give an organisation’s developers self-service, paved paths to build, deploy and run software, reducing the cognitive load of dealing with complex cloud infrastructure directly. It is a response to a specific problem: as cloud and DevOps practices matured, developers were increasingly expected to understand Kubernetes, infrastructure as code, CI/CD pipelines and cloud networking on top of their actual job of writing application code. This article explains that problem honestly, draws a clear line between platform engineering, DevOps and SRE, covers the core ideas, names the general tooling categories involved, gives an honest caution about who actually needs it, and connects it to a career path built on existing cloud skills.
The problem it solves
The DevOps era popularised "you build it, you run it" — developers owning their software all the way into production, rather than throwing it over a wall to a separate operations team, as explained in our DevOps article. That idea solved a real organisational problem, but it created a new one at scale: it asked every developer, on every team, to also become competent in provisioning cloud infrastructure, writing deployment pipelines, configuring container orchestration and reasoning about networking and security — a genuinely large amount of expertise layered on top of their actual job of writing application code.
In a small team that extra scope is manageable. Across dozens of teams, it means the same infrastructure problems get solved slightly differently by every team, expertise is duplicated unevenly, and developers spend a growing share of their time on plumbing rather than on the product. Platform engineering is the answer: build that expertise once, into a supported internal platform, instead of expecting every team to reinvent it.
How it relates to DevOps and SRE
Platform engineering is best understood as building on DevOps rather than replacing it — it exists specifically to address the operational burden that "you build it, you run it" placed on developers, using the same underlying automation and infrastructure-as-code practices DevOps established. The culture of shared ownership does not go away; platform engineering simply gives developers a supported, paved path to exercise that ownership without each of them mastering the underlying infrastructure from scratch.
Site reliability engineering, covered in the same DevOps article, is a related but distinct discipline: SRE’s focus is reliability — using error budgets and service-level objectives to decide when to ship and when to stabilise. Platform engineering’s focus is developer self-service — making it easy and safe for developers to ship and run their own services. The two frequently sit alongside each other in the same organisation, addressing different halves of the same underlying goal.
The core ideas
A handful of ideas recur across platform engineering, whatever an organisation happens to call its team or tooling:
- Internal developer platform (IDP) — the actual product a platform team builds: a layer that abstracts away raw cloud infrastructure behind self-service tooling, documentation and defaults.
- Golden paths — a supported, opinionated way to do a common task (deploy a new service, provision a database) that is easy to follow correctly and hard to get wrong, without banning other approaches outright.
- Self-service — developers can provision what they need — environments, pipelines, resources — themselves, through the platform, rather than filing a ticket and waiting for another team.
- The platform as a product — the platform team treats developers as its customers, gathering feedback and iterating on the platform the same way a product team would iterate on a customer-facing feature.
The tooling landscape, in general terms
Internal developer platforms are typically built on top of the same foundations covered elsewhere on this blog rather than being a wholly new category of technology: Kubernetes as the underlying orchestration layer (see our Kubernetes explainer), infrastructure as code to define environments and resources repeatably (see our IaC explainer), and CI/CD pipelines to automate build and deployment (see our CI/CD explainer). A platform team’s job is largely to assemble and curate these into a coherent, self-service experience for developers — packaging existing building blocks well matters more than inventing new ones.
The honest caution
Platform engineering is a genuine, growing trend, but it is not something every team needs. Building and maintaining an internal platform is itself an ongoing engineering effort, and it only pays off once an organisation has enough developers and enough repeated infrastructure work that a shared, supported platform saves more effort than it costs to run. A small team is usually better served by using managed cloud services directly than by building a platform layer on top of them. Treat "should we invest in platform engineering" as a genuine scale-dependent question, not a default yes.
Careers built on this foundation
Platform engineering is a growing role, and the honest way to describe the path into it is that it builds directly on cloud, Kubernetes and infrastructure-as-code fundamentals rather than requiring an entirely separate skill set. Certifications that establish those foundations — cloud architecture broadly, Kubernetes specifically, and operational practice — are a sensible base to build from before specialising in platform tooling, since the skills a platform engineer packages up for others are the same skills those exams already test directly.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.
Questions, answered
Get the study material as it lands
Occasional email when we publish a new certification, guide or set of practice questions. No spam, unsubscribe in one click.