Every piece of software should run, unmodified, against a twin of every service it depends on

If the application cannot tell a twin from the real service, the same unmodified code can run against an in-memory twin in milliseconds on a laptop, against a twin replaying last week's production journal, against a twin injecting the failures staging never shows (a timeout, a throttle, a permission that disappears halfway through a job), and against the real service for the final check. Most teams test against mocks they wrote themselves and hope production behaves the same; with twins the environment becomes a setting rather than a guess. Software that can only run against one provider's live API is software you cannot test properly, cannot move, and cannot put a policy in front of.

Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).

Note. A side effect the article says 'may end up mattering more than sovereignty'. The twin is also where the journal and the behaviour policy live, because every call passes through it (mandate-reach-gap, one-way-two-way-doors). The 2018 Chaos Engineering outline is the failure-injection half of this.

Where it comes from

Move the cloud, not the code Testing goes to another level (newsroom)

What it answers in the 2018 book

CI Testing answered outline, Concepts
Chaos Engineering answered outline, Concepts
Don't touch production answered outline, Security

Where it goes

Chapter Shipped means the user has it, part Build it without a server (drafting); topic Shipped means the user has it: tests, CI and going slow to go fast.

Other ideas proposed for the same chapter: Shipped means the user has it: green does not mean live, go slow to go fast.

Node idea:run-unmodified-against-a-twin in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.