Published on

What is running, where and why

From any service in production you should be able to walk the path backwards to the requirement that justifies it. That traceability chain is what turns an audit of weeks into a query of minutes.

Service line Platform Engineering

The question that arrives on a Friday

'Why does the billing service do this?' The question can come from a customer, an auditor or the team itself. Answering it properly requires knowing which version is running, which change it came from, who approved it, which requirement asked for it and which decision justified it.

If each of those pieces lives somewhere different with no connection between them, the answer takes days. If they are linked, it takes minutes.

The chain

From production to the whyThe traceability chain from the service in production back to the specification and the decision.PLATFORM · TRACEABILITYFrom production to the why Service in productionexposes its digest Artefact digestsha256:4f1a… Buildrecords the change Code changecites the specification G3 approvalwho and when Specification and decisionthe whyEach link points to the previous one with a specific value. The platform stores it on its own.N100F · n100f.com

Each link points to the previous one with a specific value:

  1. The service in production exposes the digest of the artefact it runs.
  2. The digest leads to the build that produced it.
  3. The build records the code change it came from.
  4. The change cites the specification or the task that asked for it.
  5. The gate approval records who accepted that digest and when.
  6. The specification and the decision records explain the why.

None of this data is hard to keep. The hard part is doing it every time, which is why the platform does it automatically on every build and every deployment, without depending on anybody remembering.

What it is for, besides auditing

  • Diagnosing: faced with a failure, knowing in seconds what changed since the last good version.
  • Rolling back safely: the previous digest and its approval are still there.
  • Explaining the cost: each service, with its owner and its design decision, can be cross-referenced with what it costs (we covered this in the FinOps series).

Traceability shows what happened. What gets done with it when something fails is what makes a platform improve or repeat its mistakes.


How we apply it: Platform Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk