Service Mesh Platform  ·  View 03 of 31  ·  2 · People and journeys

Actors and Their Core Journeys

Six parties who change or depend on the mesh, each with the one thing they need from it, and the journeys that carry the value.

Editable source SVG draw.io All views
Teams that own services Service team ≈ 250 teams Goal — Get mTLS, retries and a canary without writing any of it into my service. Core journeys Move a service to strict mTLS Declare a new dependency Read what my mesh costs Release engineer ≈ 900 releases a week Goal — Ship to 1% of traffic, and get back in one step if it is wrong. Core journeys Canary a release at 1% Mirror traffic to a new version Abort a rollout Platform and security Mesh SRE on call for 20 clusters Goal — Upgrade 40,000 proxies without anyone noticing, and see drift before users do. Core journeys Upgrade the proxy fleet in waves Ride out a control-plane outage Explain one failed call Security engineer owns authz and PKI Goal — Know who called what, and make a stolen identity useless within minutes. Core journeys Contain a compromised workload Dry-run an authorisation policy Rehearse a root rotation Machines and reviewers Rollout controller Argo Rollouts Goal — Read the weights the mesh actually applied, not the ones I asked for. Core journeys Step weights on analysis Abort on SLO breach Auditor 13-month lookback Goal — Show me every certificate issued and every policy change, with who did it. Core journeys Query issuance records Trace a change to its author Actors — Who the Mesh Is For and What They Get to Do Person or role Journey / task Security / platform External / third party v 1.0 · owner Platform Networking Architecture · date 2026-09

What the cast says about the design

  • Service teams never write a VirtualService by hand to get mTLS. The platform gives them defaults; the journeys they own are declaring dependencies and choosing when to go strict.
  • The rollout controller is an actor, not a tool. It is the only writer of canary weights, so it needs an identity, a permission boundary and a journey of its own.
  • The auditor's goal is why issuance records keep attestation evidence for 13 months and why every change carries before and after digests.

Journeys drawn in full

  • Move a service to strict mTLS (view 04): where the mesh's security promise becomes real for a team.
  • Canary a release at 1% (view 05): where the mesh earns its keep with release engineers.
  • Contain a compromised workload (view 06): where identity-based design is tested under pressure.

Assumptions

  • About 250 service teams and 900 releases a week at the design ceiling. Both are planning estimates, not requirement figures.
◀  High-Level Architecture All views Journey — Move a Service to Strict mTLS  ▶
Solution Architecture v1.0 · Platform Networking Architecture · 2026-09 · 31 views · open source, fully on-premises03-actors-and-journeys