Platform Engineering 01 - What Is Platform Engineering?

Another Buzzword?

If you've worked in infrastructure long enough, you've experienced the cycle of job titles constantly changing. Sysadmin, DevOps, SRE, and now platform engineering. Is this just rebranding? Not quite. As environments evolve, roles expand and contract, and new names emerge to match the changed landscape. The fact that platform engineers are attempting to solve problems that DevOps couldn't is one such example.

Where DevOps Falls Short

The core philosophy of DevOps is "you build it, you run it." Developers don't just write code — they take responsibility for operating it as well. In theory, this is an excellent approach.

In practice, however, problems surface. Every team writes their own Terraform, builds their own CI/CD pipelines, and manages their own Kubernetes clusters. The result is 10 teams solving the same problem in 10 different ways. Developers end up spending their time debugging YAML files instead of writing business logic.

This is what's known as cognitive load — the total amount of knowledge a developer needs just to get code into production. The philosophy behind DevOps is sound, but its execution ended up placing an excessive burden on developers.

So What Is Platform Engineering?

Platform engineering is the discipline of building an Internal Developer Platform (IDP). The core idea is placing a self-service layer between developers and infrastructure, so that developers don't have to deal with infrastructure complexity directly.

For example, when you need a database, you shouldn't have to file a ticket and wait. When you need to deploy an application, you shouldn't have to understand Kubernetes internals. The platform abstracts away this complexity and provides developers with a simple interface.

Developer ──→ Platform (self-service) ──→ Infrastructure
                   │
                   ├── "I need a DB"      → done
                   ├── "Deploy my app"    → done
                   └── "Show me logs"     → here

DevOps, SRE, and Platform Engineering

These three are not competing approaches — they look at the same problem from different perspectives.

To summarize: DevOps is a culture, SRE is a practice, and platform engineering is a product. A platform team builds a product, and the customers of that product are the developers within the same organization. This difference in perspective is what fundamentally distinguishes platform engineering from previous approaches.

Golden Paths

One concept that frequently comes up in platform engineering is the golden path. This refers to the standard, recommended route that the platform provides for performing a specific task.

Take web service deployment as an example: you use a provided template, push to a branch, CI runs automatically, the service deploys to staging, and a single click promotes it to production. Following this path isn't mandatory — you can deviate if needed. However, the goal is to make the default path convenient enough that most developers never want to leave it.

What Platform Teams Actually Do

The work of a platform team is diverse, but it shares a common purpose. They build developer portals where services, documentation, and tools are accessible in one place. They provide self-service infrastructure so developers can provision databases, message queues, and storage on their own. They create CI/CD templates so teams don't have to build pipelines from scratch. They integrate observability tools to provide logging, metrics, and tracing in a consistent manner.

The common thread across all of these activities is simple: shrinking the distance between "I wrote code" and "it's running in production."

Beyond a certain scale, every organization hits the same wall. Developers spend more time managing infrastructure than writing business logic. Platform engineering is a systematic answer to that problem.

In the next post, we'll look at what actually goes inside an IDP.