Search
4 results for “platform-engineering”
Search results
Platform Engineering Fundamentals
What an internal developer platform actually is, why "golden paths" beat unlimited flexibility, and how platform engineering differs from just having a good DevOps team.
How does platform engineering differ from traditional DevOps or a shared infrastructure team?
Traditional DevOps distributes infrastructure responsibility to product teams ("you build it, you run it"), while a shared infrastructure team typically operates as a ticket-driven service, product teams request resources and wait. Platform engineering treats the internal platform itself as a product, with its own users (the engineers building on it) and a deliberate design goal: reduce cognitive load by providing paved, self-service paths for common needs, rather than either forcing every team to become infrastructure experts or making them wait on a queue. The platform team builds golden paths; product teams self-serve through them.
What is a "golden path" and why does it matter more than giving teams unlimited flexibility?
A golden path is an opinionated, well-supported, self-service way to accomplish a common task, spinning up a new service, provisioning a database, setting up a CI pipeline, that comes with sane defaults for security, observability, and reliability already wired in. Unlimited flexibility sounds appealing but means every team re-solves the same problems (how do we get logs flowing, how do we handle secrets) slightly differently, multiplying the platform team's support burden and creating inconsistent security/reliability posture across the organization. A golden path trades some flexibility for consistency and speed, while still allowing teams to go off-path when they have a genuine reason to.
What is an Internal Developer Platform (IDP), concretely?
An IDP is the layer, often a combination of a self-service portal/CLI, templated infrastructure (via Terraform modules, Kubernetes operators, or similar), and standardized CI/CD pipelines, that lets a product engineer provision what they need (a new service, a database, a queue) without filing a ticket or becoming an expert in the underlying infrastructure. It sits between raw cloud/Kubernetes primitives and the product engineers who need to consume them, and its quality is measured the same way any product's is: by whether its users (internal engineers) actually prefer using it over working around it.