Platform engineering is mostly described by organisations that have a platform department. Netflix built Titus so that engineers deploy a container and never meet a scheduler. The CNCF platforms paper describes capabilities, product thinking and user research.
All of it is sound, and reading it from an engineering team of twelve it is easy to conclude the whole idea is for somebody else. It is not. The part that creates the value is available at any size, and it is the smaller half.
What a golden path actually is
A golden path is the one route from a commit to production that is supported, automated and kept working. Not the only route that is permitted. The one that is easiest.
That distinction decides everything. A standard that is slower than doing it by hand is a standard people route around, and you discover the detour during an incident, in a service nobody can deploy because the person who set it up has left.
If the approved way is not the fast way, it is not a golden path. It is paperwork with a nicer name.
The failure it fixes
The symptom is familiar long before anyone uses the word platform. Every service is set up slightly differently. Each has its own pipeline, assembled by whoever started it, reflecting what that person knew that month. Deploying service A requires knowledge that does not transfer to service B.
The cost is not in any one of them. It is that the organisation can no longer answer basic questions in one place: which services exist, how each reaches production, which are on supported runtimes, what happens when the person who built one is on leave.
- Owned by
- a named person, with time allocated
- Exercised by
- a real service, daily
- Opt-out
- allowed, and written down with a reason
This diagram as text
- Repository from a template
- Pipeline, inherited not copied — one definition, centrally updated
- Same stages for every service
- Build and sign
- Scan — blocking threshold
- Test — including a migration rehearsal
- Environment from shared modules — infrastructure arrives with the service, not through a ticket
- Deploy
- Instrumented by default
- On-call route already set
Relationships
- Repository from a template → Pipeline, inherited not copied
- Pipeline, inherited not copied → Build and sign
- Build and sign → Scan
- Scan → Test
- Test → Environment from shared modules
- Environment from shared modules → Deploy
- Deploy → Instrumented by default
- Instrumented by default → On-call route already set
Build it in this order
The order matters more than the tooling, because each step makes the next one cheaper.
One: the template. A new service starts from a repository template that already contains the pipeline, the Dockerfile, the health endpoint, the instrumentation and the deployment manifest. This is the single highest-leverage artefact, because it decides what every future service looks like without anybody having to enforce anything.
Two: the shared pipeline. Inherited rather than copied. A copied pipeline is a fork that drifts from the day it is created; an inherited one means a fix to the scanning stage reaches every service at once. This is the difference between a template that decays and one that compounds.
Three: infrastructure from shared modules. The service’s database, queue and bucket come from the same modules production uses, parameterised. The moment infrastructure arrives by ticket, the path has a manual step in it and the time saved everywhere else is lost.
Four: observability by default. Instrumentation in the template, dashboards generated from the service name, alert routing created with the service. A service that reaches production without being watched is a service nobody will notice failing.
Five, and only now: discoverability. A catalogue, or a portal, once there is enough on the path that finding things is the problem. Starting here produces a beautiful index of services that are each still deployed differently.
What small organisations get wrong
Building the portal first. It is the visible part, it demos well, and it solves a problem you do not have yet.
Making the path mandatory before it is good. Mandating a route that is slower than the alternative teaches engineers that the platform is an obstacle, and that impression outlasts the fix.
Nobody owning it. A path that is everyone’s responsibility is maintained in the gaps between other work, which means it is maintained until the first busy quarter. It does not need a department. It needs a name against it and hours that are protected.
Treating an opt-out as a failure. Some services genuinely do not fit. The right response is to write down which ones and why, so the exception is visible and revisited, rather than to force a bad fit or to pretend the exception is not there.
How you know it is working
Not by adoption percentage, which measures compliance rather than usefulness. Four questions, asked honestly:
- How long does it take a new service to reach production the first time? Measured end to end, by someone who has not done it before.
- When the scanning stage needs a change, how many repositories have to be touched?
- Can an engineer who did not build a service deploy and roll it back without asking anyone?
- When somebody opts out, do they say so, or do they quietly build their own?
The fourth is the one that tells you whether the path has the team’s confidence. People route around things they do not trust, and they do it silently.
The part that scales down
Netflix’s platform exists so engineers do not have to meet the scheduler. At twelve engineers you do not need a scheduler abstraction. You need the same underlying promise: that there is one supported way to get to production, it is the easiest way, somebody owns it, and it works today because somebody used it today.
That is available at any size. It is mostly writing things down and then automating what you wrote.
How STP approaches this
We start with the template and the shared pipeline, because they decide the shape of everything built afterwards, and we put a real service on the path before declaring it ready. Ownership is named and the hours are agreed up front, since a path nobody owns decays to the state of the organisation that was there when it was built. Where an estate already exists, we start by writing down how each service actually reaches production today, which is usually the first time anyone has seen that on one page.
More on DevOps and platform automation and Kubernetes platform engineering, or start a conversation.