Cloud Sandbox
All notes

A golden path isn't the same thing as a mandatory path

A golden path makes the common, safe route through an internal platform easy to discover and use. It guides teams towards supported outcomes without pretending that every workload has identical needs.

about 11 minutes min read

A platform team creates a standard way to deploy an internal service.

For an ordinary bfstore application, the path includes:

  • an approved repository template
  • a container build
  • workload identity
  • a Kubernetes deployment
  • network policy
  • structured telemetry
  • GitOps promotion
  • standard dashboards and alerts

A developer can move from a service definition to a healthy deployment without deciding how every underlying component should work.

CREATE SERVICE
      │
      ▼
DECLARE REQUIREMENTS
      │
      ▼
PLATFORM VALIDATES AND RECONCILES
      │
      ▼
SERVICE BECOMES READY

The platform team calls this the golden path.

Then another team arrives with a workload that needs specialist hardware, unusually high network throughput or a different release model.

The platform responds:

That is not how the template works.

The team asks whether another route is supported.

The answer is:

No. Everyone must use the golden path.

At that moment, the phrase has changed meaning.

The platform no longer offers the easiest supported route through common infrastructure decisions. It has created a mandatory route, whether or not that route fits the journey.

A golden path is the easiest supported route to a good outcome. A mandatory path is the only route permitted.

That distinction does not mean standards are optional.

Some outcomes should be mandatory. Permanent cloud access keys may be prohibited. Production changes may require approval. Workloads may need encryption, audit logging and defined recovery controls.

But a mandatory outcome does not always require one mandatory implementation.

I find it useful to separate three ideas:

GUARDRAIL

what must remain true


GOLDEN PATH

the easiest supported way
to achieve it


GOVERNED ALTERNATIVE

how a legitimate difference
is handled safely

A mature platform needs all three.

A golden path begins with a common problem

A useful path starts with a recurring user need, not with a preferred tool.

For example:

I need to deploy a private Go service that communicates over gRPC, uses workload identity and emits standard telemetry.

The bfstore review service fits that pattern.

Without a platform path, its team must separately decide:

  • how to structure the repository
  • how to build and publish the image
  • which Kubernetes resources to create
  • how the service obtains identity
  • how deployments are promoted
  • which health checks are required
  • how logs, metrics and traces are emitted
  • which callers may reach the service

Those decisions create repeated work and inconsistent results.

The golden path packages the organisation’s ordinary answers behind a smaller interface. The developer declares the dimensions that matter to the service. The platform supplies the standard implementation.

apiVersion: platform.bfstore.dev/v1alpha1
kind: Application
metadata:
  name: review
spec:
  runtime: go
  protocol: grpc
  exposure: internal

  database:
    type: mysql

  messaging:
    consumes:
      - order.completed

The platform can translate that request into a container build, workload identity, deployment resources, database access, Kafka permissions, network policy, GitOps configuration and observability.

Its value comes from the fit between the path and the problem.

A workflow does not become golden merely because the platform team prefers it.

What makes a path genuinely golden

The word golden should describe the quality of the route.

A path earns that description when intended users can:

  • discover it without asking its author
  • understand what it provides and what it does not
  • complete the ordinary journey through documented interfaces
  • receive safe defaults and useful validation
  • see progress, failures and corrective actions
  • operate the result after deployment
  • obtain support from a named owner
  • move to maintained versions as the platform evolves

Teams should prefer the path because it offers lower effort, fast feedback, clear ownership and a dependable result.

Enforcement is not evidence that the experience works.

A team may comply with a required platform while wrapping it in shell scripts, copying pipeline files, making manual console changes or keeping administrator credentials nearby. Mandatory usage can hide product failure.

The better test is:

Does the path make the common, safe outcome easier than assembling or bypassing it?

For the review service, that means the supported journey should be faster and easier to understand than creating identity, networking, deployment and telemetry separately. It should also produce a result the team can operate without hidden platform intervention.

Enforce outcomes, not unnecessary uniformity

An organisation may require:

  • central audit logging
  • encryption
  • approved identity mechanisms
  • protected production changes
  • vulnerability checks
  • data-classification controls
  • backup policies
  • network boundaries

These are guardrails. They define properties that must remain true.

For example, bfstore workloads may be required to use temporary workload identity rather than permanent cloud keys.

That security outcome can be mandatory while several implementations remain supported:

  • Kubernetes workload federation
  • managed compute identity
  • approved CI federation

The guardrail is simple: no permanent cloud keys.

The review service may satisfy it through Kubernetes workload federation. A managed batch workload may use the cloud provider’s compute identity. A deployment pipeline may use approved CI federation.

The invariant remains consistent even though the implementation differs.

This is different from insisting that every workload use one repository template because that is the only mechanism the platform team has built.

The platform should be opinionated where uniformity removes repeated work or protects important outcomes. It should not turn an implementation choice into policy without a clear reason.

Publish the path’s applicability boundary

One path cannot serve every workload well.

The bfstore review service may fit a standard pattern:

  • stateless
  • Go runtime
  • gRPC API
  • Kubernetes Deployment
  • MySQL dependency
  • Kafka integration

Other workloads may not:

  • a stateful Kafka broker
  • a batch-processing job
  • a GPU-backed inference service
  • a cluster-level controller
  • a low-latency gateway
  • a temporary database migration

A path should therefore state the conditions under which its promise applies.

Those boundaries may include:

  • workload type and runtime
  • expected scale and traffic profile
  • latency and availability requirements
  • data sensitivity and residency
  • recovery objectives
  • supported regions
  • cost profile
  • ownership and operating model

For example:

THIS PATH SUPPORTS

stateless internal services
running on Kubernetes

standard availability and recovery targets

approved internal data classifications


THIS PATH DOES NOT CURRENTLY SUPPORT

stateful brokers

specialist hardware

cluster-scoped controllers

ultra-low-latency workloads

That honesty is part of the product.

Without a boundary, the interface often grows into a collection of implementation switches:

enable_stateful_mode

enable_batch_mode

enable_gpu_mode

disable_default_networking

override_security_context

custom_everything

The platform has not reduced cognitive load. It has moved the underlying complexity into configuration.

The caller should choose only dimensions that represent meaningful product variation. The platform should infer routine implementation decisions.

When a new option is proposed, the useful question is:

Is this a real user decision, or are we exporting an implementation detail?

Handle legitimate variation deliberately

When a workload falls outside the published boundary, the answer should begin with evaluation rather than automatic rejection.

The platform team should ask:

  • Is the requirement legitimate?
  • Does it recur across teams?
  • Can the existing path support it coherently?
  • Does it have different operational or security characteristics?
  • Who will own and operate the result?
  • Which guardrails still apply?

The response should match the shape of the need.

Signal Response
The need is common and fits the current model Add a documented option to the existing path
The need is common but has a distinct operating model Create a separate supported path
The need has a stable integration boundary Provide a controlled extension point
The need is rare but legitimate Approve a bounded, governed exception
The request violates a non-negotiable control Reject it and explain why

Suppose the bfstore recommendation service requires GPU-backed inference.

If GPU workloads are becoming common and share the same lifecycle as ordinary application services, the existing interface might gain a controlled product decision:

spec:
  computeProfile: gpu-inference

If inference workloads require different scheduling, scaling, cost controls, deployment strategies, observability and operational support, they may deserve a separate inference-service path.

If the requirement is temporary or unique, a governed exception may be appropriate.

An exception should not mean “do anything you like.” It should define:

  • the reason
  • a named owner
  • applicable security controls
  • the operating and support model
  • observability requirements
  • cost attribution
  • recovery expectations
  • a review or expiry date

Repeated exceptions are evidence. They may reveal a missing platform capability rather than a collection of difficult users.

Learn from adoption, workarounds and exceptions

Usage alone does not prove that a path is golden, especially when adoption is compulsory.

A stronger product view combines several signals.

Dimension Example measure
Speed Median time from service declaration to healthy deployment
Independence Percentage of standard journeys completed without platform-team intervention
Reliability Successful reconciliation rate and recovery time
Safety Percentage of requests meeting policy on first submission
Adoption Percentage of eligible workloads using the supported path
Currency Percentage of workloads on supported platform versions
Friction Repeated support requests and workaround frequency
Variation Number, type and age of active exceptions

For the bfstore review service, a useful target might be:

A developer can create a healthy development deployment in under one hour, without platform-team intervention, while satisfying identity, network and observability controls.

Workarounds deserve investigation because they reveal either an unmet need or excessive friction.

The platform team should ask:

  • What outcome was the team trying to achieve?
  • Where did the supported path become difficult?
  • Was feedback too slow or unclear?
  • Was a legitimate capability missing?
  • Did a guardrail lack an approved route?
  • Is the team avoiding a control, or compensating for a product gap?

The conclusion may still be that the team attempted something unsafe.

That conclusion should follow investigation, not replace it.

Maintain the promise

A golden path is not complete when the first template is released.

Its dependencies, controls and user needs will change. The platform may introduce a safer identity mechanism, improved deployment verification, new observability conventions, better resource defaults or updated security policy.

Existing users need a route to those improvements.

A generated service should not remain frozen at the platform version that existed when the repository was created.

The platform might deliver updates through:

  • versioned modules
  • shared CI workflows
  • maintained libraries
  • centrally reconciled resources
  • automated upgrade pull requests
  • deprecation notices and migration guides

Maintenance also requires explicit ownership.

For each path, users should know:

  • which team owns it
  • which versions are supported
  • how incidents and support requests are handled
  • how breaking changes are communicated
  • who provides migration tooling
  • when an exception becomes a supported capability
  • how an obsolete path will be retired

A golden path is a maintained agreement between the platform team and its users.

Without that ownership, it becomes scaffolding that was useful at creation time but increasingly expensive to carry.

The mental model I am keeping

My earlier model treated the golden path as the standard way everyone must deploy.

The stronger model is:

MANDATORY OUTCOME
       │
       ▼
    GUARDRAILS
       │
       ├──────── common case ────────► GOLDEN PATH
       │
       └──── legitimate difference ─► GOVERNED ALTERNATIVE
                                              │
                                              ▼
                                     PRODUCT FEEDBACK

The golden path asks which supported route is easiest for the common case.

Guardrails define which properties must remain true on every route.

The applicability boundary states which workloads the path was designed and operated to support.

A governed alternative explains how a legitimate difference can be handled safely.

Feedback shows which recurring exceptions or workarounds should shape the next capability.

Golden paths optimise the common case.

Guardrails preserve mandatory outcomes.

Published boundaries make the support promise honest.

Governed alternatives handle legitimate differences without turning the standard interface into a configuration labyrinth.

A golden path guides teams towards a supported outcome. It stops being golden when conformity becomes more important than whether the path still serves the journey.