intellimetrics Learning
Cloud Modernization Patterns Module 6 · Stay Modern

Golden Paths

Last reviewed · content updated

Intermediate

What you'll learn

~20 min
  • Turn one-off modernization wins into a paved road new teams inherit by default
  • Build a wrapper module library with pinned, vendored dependencies
  • Express environments as a baseline plus per-environment diff, never as copies

The question after the victory lap

Lessons 1 through 15 modernized an estate. Here is the question that decides whether it stays modernized: when the next team at Meridian needs a web app with a database next quarter, what do they do?

If the answer is “read the wiki, copy the FieldDesk repo, adapt as needed,” entropy wins: each copy drifts, each adaptation forgets a control, and in three years someone runs this training’s assessment against a jungle of divergent snowflakes that were all born modern. The alternative has a name — platform engineering — and a governing idea: the golden path, where the easy way and the right way are the same way.

(This lesson is the overview; the DevSecOps Foundations training goes deeper on every mechanism here — wrapper mechanics, template governance, policy wiring, and running the paved road as a product.)

The wrapper library

The estate’s infrastructure needs are repetitive: app + database + identity + telemetry, in five flavors. A wrapper module library captures each flavor once, with the organization’s decisions baked in:

modules/
  web-app/        # App Service + managed identity + App Insights + the
                  # Lesson 4.1 hardening defaults (headers, identity, telemetry)
  sql-db/         # managed database + private endpoint + audit logging ON
  container-app/  # the Lesson 2.3 shape: KV references, scale rules, probes
  storage/        # versioning, soft delete, no public blobs - not optional
  aks-exception/  # the Lesson 2.4 shape - exists, documented, rarely consumed

Three properties make a library a platform rather than a snippet folder:

  • Wrappers over verified upstream, never raw resources. Teams consume modules/web-app, which internally uses well-maintained upstream modules — reviewed once, by the platform team, for everyone.
  • Versions pinned and vendored. Every module dependency is version-locked and the source vendored into the estate’s own repository. Builds are reproducible in five years, immune to upstream deletion, and — critically for Meridian’s world — installable in an air-gapped enclave from the vendored copy alone. “The registry was down” stops being a deploy risk.
  • Compliance defaults inside the wrapper. The audit-logging-on, public-access-off, TLS-floor decisions live in the module, annotated with the control IDs they satisfy (Lesson 6.4 consumes those annotations). A team cannot forget a control they never had to remember.

Environments as baseline + diff

The second platform pattern kills the classic config-drift disease. Not five parallel environment files that started as copies — a hierarchy:

config/
  baseline.yaml        # strict defaults: encryption on, public access off,
                       # audit on, minimum TLS - the SECURE posture is the base
  dev.yaml             # diff: smaller SKUs, relaxed alerting thresholds
  test.yaml            # diff: prod-shaped SKUs, synthetic data flags
  prod.yaml            # diff: scale, retention, alert routing - and that's all

Each environment declares only its difference from baseline. Two consequences worth the price of admission: an environment cannot silently lack a control (it inherits the strict default unless it explicitly overrides — and the override is a visible, reviewable diff), and “what is different about prod?” is answered by reading one short file instead of diffing five long ones. Note the polarity: the baseline is the strict posture, and dev relaxes downward visibly — never a loose baseline that prod is supposed to remember to tighten.

The paved road, end to end

Library plus hierarchy plus a scaffolder gives the next team their answer:

Scaffold a new internal service from the golden path:
- modules/web-app + modules/sql-db, wired with workload identity (Lesson 6.1)
- config inherited from baseline; dev diff only
- CI from the standard template: policy gates (Lesson 6.3), federated identity,
  the fleet registry entry (Lesson 5.3) generated and committed
- The Lesson 4.1 hardening checklist pre-satisfied by module defaults,
  with the exceptions list empty

Day one, the new service is on the road: identity federated, controls inherited, registry entry written. The team’s creative energy goes into their actual problem — which is the entire point. And the road is products, not police: teams can leave it (the ladder’s tests still apply — maybe they genuinely need the aks-exception module), but leaving is a visible, justified decision in the register, not a quiet copy-paste divergence.

💬Who owns the road

A golden path nobody maintains becomes the thing teams route around, and then you have snowflakes plus resentment. The platform library is a product with an owner-team (Lesson 5.3’s registry applies to it, tier: critical), a deprecation policy, and its consumers as customers. Budget it like the load-bearing asset it is — it is the mechanism by which “way more automation” compounds instead of fragmenting.

KNOWLEDGE CHECK

A new team needs Postgres with slightly different tuning than modules/sql-db provides. They propose copying the module's internals into their repo and adjusting. What does the platform pattern say?

Key takeaway

Modernization sticks when the easy way is the right way: a wrapper library with pinned, vendored dependencies and compliance baked in; environments as a strict baseline plus visible diffs; a scaffolder that puts new teams on the road by default; and a real owner treating the road as a product. This is the delivery mechanism for estate-wide automation — and the substrate Lessons 6.3 and 6.4 enforce against.

Search lessons