Architecture Design Principles

Architecture & Design Principles — Platform Engineering at Scale

A field-tested distillation of how to build a developer platform that serves ~1000 services across ~13 regions on ~2000 long-lived proxies, derived from an 8-year platform-engineering retrospective (Atlassian, 2017-2025).

The talk is structured as a chronological build-up; this skill re-organises it as a principle map plus deep-dive references.

Why this skill exists

Platform-engineering content online tends toward two failure modes:

1. Vendor demos that show the happy path of a tool without the failure modes that emerged at year three. 2. Conference talks that describe a finished system without the sequence of decisions that produced it.

This talk is unusual because it walks chronologically through how a small team built a self-service load-balancing platform, which choices compounded, and which non-technical skills mattered most over eight years. The principles below are the durable shape of that experience.

Principle Map (with canonical grounding)

Each principle is anchored to its canonical name in the established literature. Use the canonical name in PRs and code review; reviewers can verify against the cited source. Detailed grounding lives in `references/06-canon-and-citations.md`; the canonical/novel/controversial breakdown lives in `references/07-contrasts.md`.

⚠ 2026 freshness flag — sidecars: the talk's sidecar pattern is now a deliberate architecture choice, not the default. Istio Ambient (GA November 7, 2024, v1.24) replaces per-pod sidecars with per-node ztunnel + per-namespace waypoint proxies; published savings ~90%+ proxy resources. Linkerd doubles down on sidecars with its Rust micro- proxy and disputes the resource claims. Pick a side deliberately; cite your reasoning. See `references/07-contrasts.md`.

For each principle, the columns "When to apply" and "Anti-pattern it prevents" live in the reference files (references/01-05.md) and in `references/07-contrasts.md`, which is the canonical place to look for the operational guidance.

The Reference Architecture (from the talk)

The talk's central diagram, reconstructed:

   ┌─────────────────────────────────────────────────────────────────────┐
   │  DEVELOPER                                                          │
   │     │                                                               │
   │     │  "pls provision a load balancer" (JSON in version control)    │
   │     ▼                                                               │
   │  ┌────────┐    ┌─────┐    ┌────────┐    ┌──────────┐               │
   │  │FastAPI │───▶│ SQS │───▶│ Worker │───▶│ DynamoDB │               │
   │  │ (OSB)  │◀───┴─────┘    │        │───▶│Route53,  │               │
   │  └────────┘                └────────┘    │CloudFront│               │
   │                                          │API calls │               │
   │  ── Open Service Broker (Tier 1) ─────────────────                  │
   │                                                                     │
   │  ┌─────────────────────┐                                            │
   │  │ Sovereign (xDS)     │   reads DB + S3 → renders templates        │
   │  │ ┌─────────────────┐ │                                            │
   │  │ │ Templates       │ │   xDS API ──▶┌──────────┐                  │
   │  │ │ + Context       │─┼──────────────▶│ 2000     │                  │
   │  │ │ → Clusters      │ │              │ Envoy    │ 13 regions       │
   │  │ │ → Routes        │ │              │ proxies  │                  │
   │  │ │ → Listeners     │ │              │ (EC2)    │                  │
   │  │ └─────────────────┘ │              └──────────┘                  │
   │  └─────────────────────┘                   ▲                        │
   │                                            │                        │
   │  ┌──────────────────────┐                  │                        │
   │  │ AWS CloudFormation   │  provisions ─────┘                        │
   │  │ Parameters, VPC,     │                                           │
   │  │ Subnet, IGW, SG,     │                                           │
   │  │ ASG, NLB, IAM, ACM,  │                                           │
   │  │ Route53, KeyPair     │                                           │
   │  │      │               │                                           │
   │  │      ▼               │                                           │
   │  │     AMI ◀──── Packer + SaltStack (image build)                   │
   │  └──────────────────────┘                                           │
   └─────────────────────────────────────────────────────────────────────┘

Three IaC layers map onto three different products in this stack:

• Image — Packer + SaltStack. Cadence: weeks. Risk: high (every proxy rebakes).
• Infrastructure — CloudFormation. Cadence: months. Risk: medium (regional).
• Runtime config — Sovereign / xDS. Cadence: seconds. Risk: per-tenant.

This separation is what lets a small platform team ship features daily without restarting customer traffic. Most platform-team failures come from collapsing these layers (e.g., redeploying proxies to ship a routing change).

Edge-Centralized Cross-Cutting Concerns

The second half of the talk reconstructs the "what is the proxy for" question:

                    Customer (the outside world)
                          │  ▲
                          ▼  │
                     ┌─────────────┐
                     │ CloudFront  │  ←── DDoS protection
                     └─────────────┘
                          │  ▲
                          ▼  │
                     ┌─────────────┐
                     │     NLB     │
                     └─────────────┘
                          │  ▲
                          ▼  │
                     ┌───────────────────┐     ┌─────────────────┐
                     │      Envoy        │ ←──▶│ Sidecars        │
                     │ (Access logs,     │     │ • Authentication│ (Rust)
                     │  routing,         │     │ • Authorization │
                     │  HTTP filters)    │     │ • Rate Limiting │
                     └───────────────────┘     └─────────────────┘
                          │  ▲
                          ▼  │
              ┌───────┐ ┌───────┐ ┌───────┐ ... (a "bazillion" backends)
              │backend│ │backend│ │backend│
              └───────┘ └───────┘ └───────┘

The rule: the further left a concern is solved, the cheaper it gets per backend. Solving DDoS at CloudFront protects all 1000 services. Solving auth at the Envoy + sidecar pair means 1000 backend teams don't each implement OAuth.

The cost: cross-cutting concerns at the edge belong to the platform team. Backend teams lose some autonomy in exchange for not having to think about those concerns.

When to Use This Skill

Invoke this skill explicitly when:

• Designing an internal developer platform (IDP) from scratch or evaluating one
• Choosing between native proxy features and sidecars
• Implementing an Open Service Broker or any resource-provisioning API
• Planning a fleet-wide migration to new infrastructure
• Auditing a long-lived codebase for churn / coupling / maintenance burden
• Onboarding engineers to an existing platform
• Mentoring vs training a junior engineer
• Justifying time spent on diplomacy / conflict resolution as engineering work

Reference Map

For depth on each principle group:

• Self-Service Platforms — OSB, xDS,

3-layer IaC, template+context, async task, boundary validation

• Edge Compute & Sidecars — cross-cutting

concerns, sidecar tradeoffs, multi-team contribution

• Platform Migration — forced migration,

removing the old path, migration cost calculus

• Long-Term Maintenance — churn as

smell, build vs maintain, operator-centric design, AI-coupling risk

• Non-Technical Engineering Skills — diplomacy,

mentoring vs teaching, conflict anticipation, curse of knowledge

• Canon and Citations — master

citation index across Platform Engineering, SRE/DORA, Architecture Patterns, Modern Tooling (2026), and Staff+ Engineering canon, with full bibliographies

• Contrasts (canonical / novel / controversial) —

for each principle, whether it matches canon, extends canon, or diverges from the 2026 canon; how to cite each in code review

• Source: talk transcript & diagrams — full attribution,

timestamps, key visual frames

Grounded Best Practices — TL;DR

Every principle in this skill has a canonical name and a named source. The full grounding is in `references/06-canon-and-citations.md`. The five canon clusters and what they ground:

• Platform Engineering canon (Skelton & Pais Team Topologies 2019;

Conway 1968; Accelerate 2018; Humanitec State of Platform Engineering Reports 2022-2024; Hohpe Architect Elevator 2020; Backstage v1.50 / Crossplane 2.0) → grounds principles 1, 7, 9 and the "platform team" framing throughout.

• SRE & DORA canon (Google SRE Book 2016; SRE Workbook 2018;

Accelerate 2018; DORA 2024 J-curve finding; DORA 2025 AI-as-amplifier finding) → grounds principles 10, 11, 12 and the AI-coupling-risk framing in 04-long-term-maintenance.md.

• Architecture Patterns canon (Evans DDD 2003 — ACL, Open Host

Service; Fowler PoEAA 2002 — Gateway; Fowler 2004 — Strangler Fig; Ford/Parsons/Kua 2017 + 2nd ed 2023 — fitness functions; Ford/Richards/Sadalage/Dehghani 2021 — saga patterns; Wiggins 2011 — 12-Factor V; AWS Well-Architected; Nygard 2011 — ADRs; Brown — C4) → grounds principles 2, 3, 4, 5, 6, 7, 9, 11.

• Modern Tooling 2026 reality check (Envoy v1.38 + go-control-plane;

OSB v2.17 not deprecated but Crossplane 2.0 is the 2026 substrate; Istio Ambient GA Nov 2024 / Linkerd micro-proxy debate; SMI archived Sept 2023; Backstage v1.50 + Spotify Portal GA; SaltStack in decline; Terraform Stacks GA HashiConf 2025) → grounds the freshness flags on principles 3, 8, and the tooling notes throughout.

• Staff+ Engineering canon (Reilly Staff Engineer's Path 2022 —

three pillars + "You're a Role Model Now"; Fournier Manager's Path 2017 — Alpha Geek anti-pattern; Larson Staff Engineer 2021 — Tech Lead archetype; Camerer/Loewenstein/Weber 1989 + Heath brothers 2007 — curse of knowledge; Scott Radical Candor 2017 — Ruinous Empathy; Grove High Output Management 1983 — leverage equation; Kram 1985 + Allen et al 2004 — mentoring research; Edmondson 1999/2018 — psychological safety; Hogan Resilient Management 2019) → grounds principles 13, 14 and 05-non-technical.md throughout.

The contrast matrix at `references/07-contrasts.md` catalogs where each principle is canonical, novel, or controversial against the 2026 canon — useful when defending a design in code review.

Anti-Heuristics (when NOT to apply)

• Greenfield project, no compounding cost yet. The three-IaC-layer split, the

control-plane separation, and the template+context pattern are amortizations of cost over many tenants. A single-team service doesn't need them.

• Cross-cutting concerns of a single team. Edge centralization is correct

when N teams need the same thing. For one team's auth, just put it in the app.

• Forced migration without an actually-better target. The talk's forced

migration worked because the new platform was strictly better. Forcing migration to a not-yet-better platform burns trust.

• Churn-as-smell on actively-developed code. Churn is a smell on finished

features that won't stop changing — not on features that are still being built.

Talk Attribution

"I was laid off by Atlassian" — Vasilios Syrakis, 2026-05-10

https://www.youtube.com/watch?v=55pTFVoclvE (40m05s)

>

Despite the click-bait title, this is one of the densest first-person

retrospectives on platform engineering at scale published in recent memory.

Vasilios built and open-sourced Sovereign (the Envoy xDS control plane)

while at Atlassian; the talk reconstructs the system from memory on Excalidraw.

Open-source artifact mentioned in the talk: Sovereign (Envoy xDS management server in Python/FastAPI) — see talk for Bitbucket link; the design is what matters here, not the specific repo.

Self-Service Platforms: Patterns

Six patterns that the talk converged on, in the order they appeared.

1. The Open Service Broker (OSB) Pattern

Shape: a web API that brokers resource provisioning. Devs request a typed "service instance" of a typed "plan", get back a binding (DNS, creds, etc.).

Endpoints (from the OSB spec):

• GET /v2/catalog — list services and plans the broker can provision
• PUT /v2/service_instances/:id — provision
• PATCH /v2/service_instances/:id — update
• DELETE /v2/service_instances/:id — deprovision
• PUT /v2/service_instances/:id/service_bindings/:bid — bind credentials

Why it's useful even outside K8s: the spec is a contract for "give me a typed resource". Whether the backing impl is K8s operators, Terraform, CloudFormation, or a custom worker doesn't matter to the dev.

At Atlassian: the OSB API was a FastAPI app. Plans corresponded to "load balancer with ACM cert + Route53 entry + CloudFront distribution".

Anti-pattern: exposing the backing tools (raw Terraform, raw kubectl) directly to dev teams. The OSB gives you a versioned contract; the underlying tooling is free to change underneath.

The catalog endpoint lists all of the services and plans that are available

on the OSB, and just metadata about them. You might query the service

broker and then display some of the metadata in your console... where

developers can click and provision things.

2. Async Task Orchestration (FastAPI → SQS → Worker → DB)

Shape:

client ─PUT─▶ FastAPI ─enqueue─▶ SQS ─dequeue─▶ Worker
   ▲             │                                 │
   │             │                                 ├─▶ Route53
   │             │                                 ├─▶ CloudFront
   │             │                                 └─▶ API calls
   │             ▼                                 │
   │          DynamoDB ◀────────────────write status
   │             ▲
   └─poll status─┘

Why: provisioning takes seconds-to-minutes. If you block the API thread on the work, you get timeouts, retried writes (creating duplicate resources), and partial-state nightmares.

The client contract: returns immediately with a task ID and "in progress" status. Client polls until it sees succeeded or failed.

At Atlassian: client → FastAPI returns a 202 with a task ID. The worker does the actual AWS API calls (which are slow and rate-limited). Status writes to DynamoDB. Client polls FastAPI which reads DynamoDB.

Critical detail from the talk: "the web worker wouldn't do it itself. It would actually send that over SQS." Resist the urge to do "just a bit" of work on the API path.

3. The Three IaC Layers

Many teams collapse these into one. The talk's separation is the durable shape:

Why three layers, not one or two:

• Image lives for weeks because AMI builds are slow and risky. You don't

want to rebake the image to change a routing rule.

• Infrastructure lives for months because changing VPC/subnet/IAM is

high-blast-radius and rarely needs to change.

• Runtime config lives for seconds because that's where developer

velocity lives. Devs ship routing changes every hour; you cannot tie those to AMI rebuilds.

Pattern: the inner layer should change the most slowly. Inverting this — putting business logic in the AMI — is the most common platform-team mistake.

Cargo-cult warning: many teams adopt Kubernetes and re-collapse these layers because the K8s control plane handles all three. Don't. The cadence mismatch is real; you'll feel it when you need to ship a CVE patch and realize the only path is a rolling reboot of customer pods.

4. The Control Plane / Data Plane Split (xDS)

Shape:

                    ┌─────────────────────┐
                    │   Control Plane     │
                    │   (Sovereign)       │
                    │                     │
                    │  reads DB + S3      │
                    │  renders templates  │
                    │  serves xDS API     │
                    └──────────┬──────────┘
                               │ gRPC / REST (xDS)
                               │ ADS (Aggregated Discovery Service)
                ┌──────────────┼──────────────┐
                ▼              ▼              ▼
            ┌───────┐      ┌───────┐      ┌───────┐
            │Envoy 1│      │Envoy 2│ ...  │EnvoyN │  (data plane)
            └───────┘      └───────┘      └───────┘
              long-lived processes, never restart for config change

Why this matters: with a control plane, proxy lifetime is independent of config lifetime. You can deploy 2000 proxies once and reconfigure them forever. Without it, every config change requires touching the proxy process.

The xDS API surface (Envoy-specific but generalizable):

• CDS — Cluster Discovery Service (which backends exist)
• EDS — Endpoint Discovery Service (instances of each cluster)
• RDS — Route Discovery Service (HTTP routes)
• LDS — Listener Discovery Service (ports/filter chains)
• SDS — Secret Discovery Service (TLS certs)
• ADS — Aggregated DS (all of the above, ordered)

At Atlassian: Sovereign was a FastAPI app that polled DynamoDB + S3, rendered Jinja templates into Envoy config, and served xDS. The proxies long-polled the control plane and applied diffs.

Generalizable beyond Envoy: the same pattern fits any fleet-of-workers problem — feature flags (LaunchDarkly), DNS (Route53 with health checks), content distribution (Fastly's instant purge), Kubernetes itself (the api-server is a control plane, kubelet is the data plane).

5. Template + Context Separation

Shape: a typed dev-facing parameter set ("Context") flows into platform-authored logic ("Templates") to produce complex output config.

dev's JSON input (Context)
   │ ─ tenant_id: "growth"
   │ ─ domains: ["growth.atlassian.com"]
   │ ─ rate_limit_rps: 100
   │ ─ requires_auth: true
   ▼
Template (platform-authored Jinja/Tera)
   │ {% if requires_auth %}
   │   http_filters:
   │     - name: envoy.filters.http.ext_authz
   │       config:
   │         grpc_service: { ... }
   │ {% endif %}
   ▼
Generated Envoy config (full power, dev never sees raw config)

Why this is better than letting devs write Envoy config directly:

1. Validation: Context schemas are small and tractable. Raw Envoy config is enormous and footgun-rich. 2. Forward compatibility: platform team changes how requires_auth maps to filter chains; devs don't relearn anything. 3. Cross-cutting upgrades: a security fix becomes "patch the template"; all tenants get it automatically on next render.

The locus of platform team logic: live in the templates. Every product feature the platform offers is a clause in a template.

Anti-pattern: letting devs override or extend templates per-tenant. The moment you have N templates, you have N-1 bugs.

6. Validate at the Boundary

The rule: validate Context (dev input) at the API boundary. Templates assume valid input.

Why: an invalid Context that reaches the template either crashes the render (good — caught early) or produces an invalid Envoy config that makes it onto live proxies (bad — traffic loss).

   ┌─────────────────────────────────────────────────────────┐
   │  dev JSON                                               │
   │     │                                                   │
   │     ▼                                                   │
   │  ┌────────────────┐  ← Pydantic model, strict typing    │
   │  │ Boundary check │    type checks, ranges, regex      │
   │  │ (validate now) │    cross-field invariants          │
   │  └────────────────┘    (fail fast, refuse render)      │
   │     │                                                   │
   │     ▼                                                   │
   │  Template (assume valid)                                │
   │     │                                                   │
   │     ▼                                                   │
   │  Envoy config (assumed valid by template)               │
   └─────────────────────────────────────────────────────────┘

At Atlassian: dev input was validated at the broker (Pydantic / OpenAPI spec). Templates were free to assume e.g. that tenant_id was a valid slug because the boundary check enforced it.

Two further defenses worth adding (not all explicit in the talk but implied by the model):

• Render-time validation: after templating, run envoy --mode validate

against the generated config before serving it to the data plane.

• Canary rollout: push new config to 1% of proxies first, monitor for

5xx spike, only then roll out.

Putting it all together (the OSB → Sovereign → Envoy flow)

1. dev writes simple JSON to a file in version control
2. CI uploads JSON to OSB API (FastAPI)
3. OSB writes provisioning task to SQS
4. Worker picks up task, creates AWS resources (Route53, ACM, CloudFront),
   writes status to DynamoDB
5. Sovereign control plane polls DynamoDB, renders templates with the new
   context, exposes via xDS
6. Envoy proxies long-polling xDS receive the new config diff
7. Traffic starts flowing through the new routes

This is the complete loop. Every box in it can be (and was) scaled, replaced, or upgraded independently because the seams between them are typed APIs, not shared databases.

Edge Compute & Sidecars: Centralizing Cross-Cutting Concerns

The core insight

"If we can deal with the problems here [at the edge] before they reach a

service, we save a lot of time, we save some money, and it saves the

customer time. It's great for everyone, really."

Every cross-cutting concern solved at the edge is a concern not solved by 1000 backend teams. The savings compound multiplicatively, not additively.

The cross-cutting concerns (in order of value-per-effort)

Native vs Sidecar — when to choose which

                          ┌─────────────────────┐
                          │                     │
                          │  Is the concern     │
                          │  implementable as   │
                          │  Envoy filter /     │
                          │  built-in config?   │
                          │                     │
                          └──────────┬──────────┘
                                     │
                       Yes ──────────┼────────── No
                        │                         │
                        ▼                         ▼
            ┌─────────────────────┐   ┌─────────────────────┐
            │ Native (Envoy)      │   │ Sidecar             │
            │ • Lowest latency    │   │ • Own language      │
            │ • No extra hops     │   │ • Own deploy lifecycle│
            │ • Hard to extend    │   │ • Owned by other    │
            │                     │   │   team possibly     │
            │ Use for: logging,   │   │                     │
            │   routing, headers, │   │ Use for: auth,      │
            │   basic rate limit  │   │   authz, rate-limit │
            │                     │   │   with global state │
            └─────────────────────┘   └─────────────────────┘

At Atlassian: access logs lived natively in Envoy (network filter + HCM access_log config). Authentication was a Rust sidecar (written by Vasilios). Authorization and rate-limiting were sidecars contributed by other teams. All sidecars were baked into the AMI by the Packer/SaltStack flow.

The "ext_authz" filter is the key Envoy primitive that makes sidecars work: a single filter that calls an external gRPC/HTTP service per request, which can deny or allow. The sidecar runs as a separate process on the same host (localhost, low latency).

The multi-team contribution model

The hidden benefit of the sidecar pattern: other teams can own and ship their own sidecars without forking the proxy.

                Platform team owns:
                  • Envoy itself
                  • Sovereign xDS control plane
                  • AMI build pipeline
                  • Native filter configuration

                Other teams contribute:
                  • Authentication sidecar (Vasilios/security team, Rust)
                  • Authorization sidecar (authz team)
                  • Rate-limiting sidecar (reliability team)

                AMI bakes in all sidecars at image-build time.
                Each sidecar has its own deploy lifecycle, language,
                and code review process.

Why this scales the platform team: without sidecars, every new cross-cutting concern requires a PR to the platform team. With sidecars, the platform team owns the contract (how sidecars are baked, configured, talked to via ext_authz) and other teams own the implementations.

Anti-pattern: forcing all cross-cutting logic into proxy filters. You'll either rewrite the proxy or get a 10,000-line config file.

The architectural rule

The further left (closer to the client) a concern is solved, the cheaper

it gets per backend service.

   client ──▶ CDN ──▶ NLB ──▶ Proxy + sidecars ──▶ backends
                 ▲        ▲          ▲
                 │        │          │
                 │        │          └─ auth, authz, rate-limit, headers
                 │        └──────────── TLS, basic flow control
                 └───────────────────── DDoS, geo-routing, caching

If your team is asking "should we put X in the API gateway or in each service?", the answer is almost always gateway, if X is needed by more than 2 services. The maintenance cost of N implementations grows super-linearly in N.

Tradeoffs and exceptions

*When not to centralize at the edge*:

1. Concerns specific to one team / one product. Don't push product logic into the proxy. 2. High variability per service. If the auth model is genuinely different per service (some use OAuth, some use mTLS, some use API keys), centralization adds branching complexity. Picking one auth model org-wide is the real fix. 3. Performance-sensitive paths. ext_authz adds a localhost round-trip (~0.1-1ms). For 99% of services that's invisible; for a high-frequency trading service it's not. 4. Concerns the platform team can't operate at the edge's reliability level. If your sidecar dies, all traffic through that proxy dies. The sidecar's SLO must match the proxy's SLO.

The cost of centralization

The flip side is real and worth naming:

• Backend teams lose autonomy: they can't pick their own auth scheme.
• The platform team becomes the bottleneck: every new cross-cutting

concern requires platform-team review.

• Outages have larger blast radius: an Envoy bug downs everyone, not

one team.

The talk's implicit answer: these costs are worth paying for an org with ~1000 services. They are not worth paying for an org with ~5. The breakeven is somewhere around 20-50 services with sufficient overlap in concerns.

Putting it together (the edge call path)

Customer request
   ↓
CloudFront (DDoS, geo, caching)
   ↓
NLB (L4, TLS passthrough)
   ↓
Envoy (TLS terminate, route lookup, header munging, access log)
   │
   ├─→ ext_authz call → Authentication sidecar (Rust)
   │                       returns identity claims
   ├─→ ext_authz call → Authorization sidecar
   │                       checks policy, allow/deny
   ├─→ HCM filter   → Rate limit sidecar (with global counters)
   │
   ↓ (if all allow)
Backend service
   ↑ response
   ↓ (back through Envoy, access log records duration + status)
NLB → CloudFront → Customer

Backend service sees: an authenticated request with identity headers already populated, never sees a denied request, never sees a rate-limited request. The backend team writes business logic only.

Platform Migration: Forcing Functions

The core problem

You've built a better platform. You want every team to move to it. But teams are busy shipping their own work, and migrating doesn't show up on their OKRs.

Result: voluntary migration is asymptotic — the last 20% never moves. You end up running both platforms forever, which doubles operational cost and means new platform features must be replicated in the old platform.

The talk's solution: remove the alternative

"They forced a switch to where you could no longer expose your service

publicly through their [old] load balancer, which is too basic, and you

had to go through our centralized load balancing infrastructure and to

explicitly configure it as a way of signaling your intention for that

service to be publicly accessible."

The mechanism: the old basic load balancer kept working, but it stopped accepting public traffic. You could still use it internally. The forcing function was specific (public exposure) rather than total (delete the old thing).

Why specificity matters: a total deprecation is a cliff. A specific forcing function is a wall — teams can choose when to climb it, but eventually they must.

The migration ladder (general shape)

1. Build the new thing alongside the old. Both run. New teams adopt new platform. Old teams keep using old platform. Voluntary. 2. Add a clear feature gap. New platform gets a feature old platform can't have (in this case: centralized auth, rate limiting, edge features). Now there's a reason for old teams to move. 3. Migrate the easy ones. Use platform team time to migrate willing-but-busy teams. Make the migration script idempotent. 4. Migrate the strategic ones. Identify which migrations create the strongest forcing function for the rest. At Atlassian: Jira, Confluence, Bitbucket, Status Page. When the top products are on the new platform, "this is unsupported" becomes credible. 5. Forcing function. Remove the path of least resistance from the old platform for new use cases (here: new public services must use new platform). 6. Deprecation date. Announce a hard date. By this time the cost of not migrating exceeds the cost of migrating.

Critical sequencing: steps 1-4 must be done before step 5. If you flip the forcing function while the new platform is missing features or poorly tested, you create a riot.

The cost calculus (why migrations are slow)

Migration cost per team =
    (engineer-days to migrate)
  × (number of services)
  × (regression risk factor)
  − (value of new features over time horizon)

This is why migrations stall: each team independently solves this equation and sets "migrate" priority based on their estimated cost. For most teams, even when net value is positive, the upfront cost loses to "ship the next feature".

The forcing function changes the equation: when "don't migrate" becomes "no public traffic", the cost of not migrating becomes infinite. Suddenly even pessimistic migration estimates are obviously cheaper.

Migration cost reduction tactics

The talk implies these but doesn't name them all:

• Script the migration. Don't ask teams to read docs and execute steps

— give them a one-command tool that does it.

• Make the new config compatible with the old. The OSB pattern helped

here: the dev contract (JSON in version control) was simpler than the old basic LB config, not more complex. Migration was "delete old config, write small JSON".

• Take ownership of the migration. Platform team does the migration

to the team's repo (PR'd into their codebase), not the team migrating themselves.

• Migrate the hardest service first as a credibility move. If you can

migrate Jira (the hardest), every other team's "but my service is special" becomes less believable.

Anti-patterns

Big-bang migration

"Everyone moves on March 1st." Doesn't work for orgs >10 teams. Too many conflicts, no time for the platform team to react to issues, no escape valve.

Voluntary migration with no end state

"Please migrate when you can." Forever-state. The platform team operates both platforms in perpetuity, and the new platform never gets the investment it needs.

Forcing function before parity

"You can no longer use the old platform" but the new one is missing features. Teams revolt. Platform team's credibility is destroyed and the next forcing function attempt fails too.

Forcing function without notice

"Today, we deprecated the old API." A surprise forcing function gets one emergency Slack channel and a year of trust deficit.

The implicit cultural prerequisite

A forcing function can only work if the platform team has organizational backing to enforce it. The talk doesn't dwell on this but it's there between the lines: "we could enforce that through the platform" is a sentence that only an org-supported platform team can say.

If your platform team is purely service-oriented (no enforcement authority), forced migration becomes pleading. You'll need either:

1. Executive backing to add the forcing function, or 2. A natural forcing function — e.g., a security incident that forces everyone off the old thing, or a vendor deprecation that does it for you.

Plan around whichever you have. Don't assume you have authority you don't.

The migration as a service

At a certain scale, migrations become a permanent function of the platform team. New platforms will be introduced; old ones will be deprecated. The migration ladder becomes a playbook the platform team runs every 18-24 months.

Treat it as a service:

• Catalog of currently-supported platforms with deprecation dates
• Migration scripts maintained for each transition
• Time-bounded support windows for each old version
• Forcing-function language consistent across migrations

The Atlassian story implies this maturity — moving Jira/Confluence/ Bitbucket/Status Page through migrations is muscle memory at that point, not a one-off project.

Long-Term Maintenance: The 8-Year View

The talk's most underrated section. Most architecture content focuses on greenfield decisions; this section is about what those decisions look like five years later.

The core observation

"Building something is easy. Changing it and making sure that you can

still change it over time is difficult. Because as you change things,

it slowly becomes harder to change. Things start to get coupled, and

all of a sudden when you change something in one area, it affects

another, and you have to deal with the task of detangling something."

This is the single most important sentence in the talk. The shape of code quality is not a stable plateau — it's an exponential decay unless actively fought. Every change creates some coupling; the integral over many changes is a system that resists further change.

Churn as a smell

"The area that churns becomes predictable where all the churn is going

to be at a certain stage. And once you notice that there is some churn,

it's sort of a smell. It is — it's an indication that part of the

service or project is going to keep increasing in size or complexity."

Mechanism: a file that keeps changing is doing too many jobs. Each new requirement adds another condition, another branch, another flag — because the existing shape doesn't naturally accommodate the requirement, you patch around it. The patches compound.

Detection:

# Top 20 files by commit count in the last year
git log --since="1 year ago" --name-only --pretty=format: \
  | sort | uniq -c | sort -rn | head -20

Files at the top of this list are your churn hotspots. Don't refactor all of them — pick the ones that also show up frequently in incidents or in code review comments.

The action when you find churn:

1. Read the recent commit messages on that file. What kept changing? 2. Is there a missing abstraction? Often the churn is because N slightly-different things share one file. Split into N+1 files (the common shape + N variants). 3. Is there a missing extension point? Often the churn is because every new requirement adds a flag. Replace flags with a plugin / strategy pattern. 4. Document the invariant. Sometimes the file is just inherently complex. Capture the invariant so future authors don't break it accidentally.

*When not to act on churn: the file is still in active development. A new feature's main file will always churn during build-out. Churn is a smell on finished* features that keep changing.

Build vs Maintain are distinct skills

The talk implies a hierarchy:

• Building — write code that solves the problem for now. Most

bootcamp/CS curriculum stops here.

• Maintaining — write code that can be changed for problems you

don't yet know about. Requires modeling future change.

• Operating — write code that someone else can change, debug, and

diagnose during incidents. Requires anticipating who that someone is and what they'll know.

A senior engineer is differentiated by maintain + operate. A junior engineer typically only builds.

Implication for hiring and team composition: a team of all-builders will produce a system that nobody can maintain after the original authors leave. Atlassian's eight-year tenure across this team is what produced the maintenance perspective — without that retention, the maintenance lessons are externalised onto whoever inherits the codebase, usually badly.

Operator-centric documentation

"When [people] become on call, they know where to look, what could go

wrong, where do things break essentially. So you know, that's whether

that's knowing what kind of what particular log messages mean, what

sort of metrics to check when something is going wrong and what those

metrics could allude to, how to resolve those particular expected

problems if they're not automated away."

The four artifacts every long-lived service needs:

1. Log message catalog. For every distinct log line in the system, what does it mean? What does it imply for operator action? Critical ones should include a runbook link. 2. Metric catalog. What metrics matter? What's the normal range? What does a deviation imply? What dashboard shows it? 3. Failure mode catalog. What can break? What's the symptom? What's the resolution? Common entries: "AWS region outage", "SQS unavailable", "DynamoDB throttling", "bad config pushed". 4. Recovery procedures. For each failure mode that isn't auto-healed, what does an on-call engineer do?

At Atlassian: the talk lists exactly these — "Amazon could have an outage and the database isn't accessible... SQS stops working... a proxy receives bad configuration... configuration that's valid but destroys the traffic." Each of these is a runbook entry.

Anti-pattern: a 50-page architecture document that doesn't tell on-call what to do at 3am. Architecture docs are for new engineers; runbooks are for on-call engineers. Different audience, different format.

Onboarding is recurring, not one-shot

"Over time people come and go. People get hired. People leave for other

jobs. And so you get you have to do that onboarding again obviously.

But you should have more people that are able to do that onboarding

collectively."

The lemma: every piece of operational knowledge that lives only in one person's head is a single point of failure. The cure is distributed knowledge production, not heroic individual documentation.

Tactics:

• Pair on-call. Junior + senior share shifts. Junior asks questions

during incidents. Senior captures answers as runbook updates.

• Rotate ownership. Code areas should have at least two owners.

Mandate this in code review (no PR to an area with one owner approves itself).

• Documentation as part of "done". A feature isn't done until the

runbook entry is written. This is the only durable countermeasure to "we'll document it later".

• Periodic re-onboarding drills. Every quarter, ask a senior engineer

to follow the onboarding docs from scratch. They will find rot.

Coupling accretes silently

"Things start to get coupled, and all of a sudden when you change

something in one area, it affects another."

Coupling is the dual of churn: churn is the symptom, coupling is the mechanism. A change that "shouldn't" affect another area but does is evidence of hidden coupling.

Two kinds of coupling worth distinguishing:

1. Compile-time / type coupling. Shared types, shared interfaces. The compiler catches incompatibilities. This is the good kind. 2. Runtime / behavioral coupling. One module depends on the behavior of another (timing, order, side effects). The compiler doesn't catch this. This is the bad kind.

Tactics to reduce behavioral coupling:

• Pure functions where possible. No side effects, no implicit state.
• Idempotent operations. Calling twice should produce the same result.
• Explicit contracts. If module A depends on B doing X first, that

ordering should be in code (call B then A) not in custom (call them in the right order).

The AI-coupling risk

"It'll be interesting with all these vibe coded apps and AI assisted

apps to see how we handle that. When we have people that are not really

familiar with what they've created, and the maintenance burdens appear.

They don't appear at the beginning. There's just not enough going

through. It hasn't been around for long enough. There hasn't been

enough changes."

The 2026 version of the maintenance problem: code authored by AI, supervised by a human who may not fully understand what was written.

The risk model:

• Building with AI is fast. You ship features faster than ever.
• Maintenance with AI requires the same understanding maintenance always

required, but now the original author had less of it.

• When the system breaks, the AI that wrote it isn't on-call. A human is.

That human reads code they didn't fully understand to start with.

Counter-tactics (not in the talk, but the natural extension):

• AI must write tests too. The test suite encodes the assumptions; if

it's complete, maintenance is tractable.

• AI must write docs too. The intent should be captured; the human

reviewer should verify the docs match the code.

• *Pull-request review by a different AI*. Cross-model adversarial

review catches what the writer-model missed (analogous to the bstack P20 Cross-Review primitive).

• Stronger types. The type system catches what the human doesn't.

Rust > Python here.

The cautious read: AI-authored code amplifies the maintenance burden in exactly the way the talk warns about. The hopeful read: AI-assisted detangling may be the cure: "you might be able to find these areas quite quickly, get an LLM to perform the detangling for you. I think if we can do that, that's fantastic. But I don't want to be too optimistic just in case."

The maintenance budget

A useful frame the talk doesn't name explicitly: every team has a maintenance budget, measured in engineer-weeks per year. If you spend more than that on maintenance, no new features ship. If you spend less, the maintenance debt compounds.

Healthy ratios (rough rules of thumb):

• Building: 50-70% of team time
• Maintaining: 20-30% of team time (refactors, doc, churn reduction)
• Operating: 10-20% of team time (on-call, incident response, runbook

updates)

Teams that spend 95% on building are accumulating maintenance debt. Teams that spend 95% on maintaining are not shipping. The talk's tone suggests Atlassian's load-balancing platform team eventually settled somewhere around the middle.

Non-Technical Engineering Skills

The talk's last 8 minutes (32:00-40:00). Most architecture content treats these as out-of-scope. The talk treats them as load-bearing — and the eight years of context backs that up.

1. Diplomacy as an engineering skill

"I have grown tremendously in my diplomacy skills, conflict avoidance,

probably conflict resolution as well. Being able to persuade, propose

ideas, being able to teach, educate, and mentor. These are the

non-technical things that you probably don't hear a lot about."

Why this is engineering, not just soft skill: a technically-correct decision that nobody implements has zero value. The path from "I see the right thing to do" to "the team does it" routes through diplomacy.

The diplomatic skill stack (implicit in the talk):

1. Self-awareness — knowing your own emotional state, biases, blind spots. Without this, every conflict is the other person's fault. 2. Awareness of the other person — what motivates them, what they're afraid of, what they've already heard from you. 3. Persuasion — framing your proposal in terms of their goals. 4. Conflict anticipation — seeing the disagreement before it happens. 5. Conflict resolution — when the disagreement is here, getting both parties to a workable outcome.

Where diplomacy shows up in platform engineering specifically:

• Forcing-function rollouts (see 03-platform-migration.md)

require buy-in from product teams who will lose autonomy.

• Sidecar contributions (see 02-edge-compute-sidecars.md)

require negotiation between the platform team (owns the contract) and feature teams (own the sidecar implementation).

• Long-term maintenance investments require selling refactor work to

leadership that wants new features.

• Incident retrospectives require blameless investigation across teams.

2. Personality conflicts are inevitable

"I was exposed to different types of managers and colleagues over time.

And everyone has different personalities and styles of working. And

because I was exposed to so many different types, I experienced

conflicts with certain people. And even though I had conflicts,

there's still people that I respect."

The framing matters: conflict ≠ disrespect. You can disagree fundamentally with someone's style or decisions while still respecting their intellect, integrity, or contribution.

What you can do:

• Anticipate conflicts before they happen, based on style mismatches.
• Take responsibility for your half of the dynamic.
• Recognize when the relationship can't be fixed and choose your battles.

What you can't do:

• Force someone else to change their style.
• Win every conflict.
• Make all conflict go away through technical correctness.

The career implication (the talk implies but doesn't state): if a particular personality conflict is dominating your work life, sometimes the right move is to leave that team, not "fix" the conflict.

3. Curse of knowledge

"I don't know. Maybe I do feel like I have the curse of knowledge. And

that this stuff seems easier to me now because I I've done so much

with it."

The phenomenon: things you've done many times feel obvious to you. You forget what it was like to not know them. You then explain things in shorthand and assume the listener tracks. They don't.

Why this matters specifically for platform engineers: you've built the thing. The teams using it are seeing it for the first time. Your documentation, your error messages, your onboarding guides — all written with the curse — make sense to you and not to them.

Tactics to counter:

• Watch a real user navigate your docs for the first time, silently.

You'll see exactly which mental leaps they can't make.

• Have a new hire write the onboarding doc. They still remember what

they didn't know.

• Defer to confusion as signal, not weakness. If a smart engineer is

confused by your interface, the interface is wrong, not the engineer.

4. Mentoring is different from teaching

"I find it easy to help people to point out areas where they need

understanding and to deliver that understanding to them, to break

down complex things into simple terms so that they can build a

mental model of the system that they're working on. I have that

ability. I'm quite good at that. But mentoring is distinct from that.

... What I found personally difficult was striking the balance between

how much time I give to the mentee and what that time would consist of,

whether it's — I didn't want to give them answers to problems, but I

don't want them to get so stuck that they become frustrated."

The distinction:

• Teaching / training: I have knowledge X, I transfer X to you. Goal:

you have X.

• Mentoring: I help you become someone capable of acquiring X (and Y

and Z) on your own. Goal: you have agency.

These are different jobs. The skills are related but not identical. Most senior engineers are good teachers (they've internalized enough patterns to explain them). Fewer are good mentors (which requires restraint about explaining).

The mentoring tension:

                  too much help
                       │
                       ▼
            Spoon-feeding.
            Mentee never struggles, never grows.
                       │
                       │
                   middle
                       │     ← target: mentee gets stuck enough
                       │       to learn, but not so stuck that
                       │       they give up
                       │
                       ▼
            Sink-or-swim.
            Mentee frustrated, learns the wrong lessons,
            or quits.
                       │
                       ▼
                 too little help

Tactics for staying in the middle:

• Time-boxed struggle. "Spend 30 minutes on this. If you're still

stuck, come find me." Sets explicit expectation.

• Hint, don't answer. "Have you looked at how X handles this case?"

rather than "Do Y."

• Explain reasoning after they solve it. They've already invested

effort; now your explanation has somewhere to land.

• Notice and name what they did well. Specific praise reinforces the

pattern.

The honest caveat from the talk: "I have no idea if I reached that balance, but I suppose the results speak for themselves. I'm not sure if I can attribute the results to me necessarily." Mentoring is hard to evaluate even after the fact. Don't overclaim.

5. The colleague-as-customer model

"Training my colleagues, getting them to understand, working through

problems with my colleagues, that was essentially my bread and butter

during the last half of my employment. Jumping on a call and going

through stuff. Feedback that I got from my colleagues all the time

was that I was always available to help and that I could boil down

hard topics into something that was understandable."

A senior engineer at scale spends progressively less time writing code and more time teaching colleagues. This is not a side-quest; it's the job. Code review, design review, paired debugging, ad-hoc Slack questions — this is how a senior engineer multiplies.

The trap: many engineers see helping colleagues as interruption from their "real work" (their own code). At sufficient seniority, that is the real work. Trying to fight it produces a senior IC who writes a lot of code that nobody else can change.

A heuristic: if you ever feel that your job has shifted from "write code" to "help other people write code", you have probably become a senior engineer. The transition is involuntary and one-way.

6. The non-technical evaluation criteria

The talk hints at how senior engineers should evaluate themselves:

• Have I left the system in a state someone else can change?
• Have I distributed enough knowledge that my absence isn't an incident?
• Have I taught the next layer of engineers enough that they can teach

the layer after that?

• Have I handled conflicts in a way that's productive rather than

scorched-earth?

• Have I anticipated the political and organizational costs of my

technical decisions?

These don't appear in performance reviews as bullet points, but they're what the speaker is implicitly proud of in retrospect.

Linking back to architecture

These non-technical skills are not separate from the architecture chapters earlier in the talk. They are the substrate that lets the architecture survive:

• The control plane / data plane split (architecture) only works because

the platform team can negotiate with backend teams about who owns what (diplomacy).

• The sidecar model (architecture) only works because cross-team

contribution requires teaching and patience (mentoring + curse-of- knowledge counter-tactics).

• The forced migration (architecture) only works because the platform

team has cultivated enough relationship capital to spend on the forcing function (diplomacy + conflict anticipation).

• The long-term maintenance discipline (architecture) only works because

the platform team has built distributed knowledge across colleagues (the colleague-as-customer model).

This is why the talk's chapter ordering is correct. The architecture sections set up what was built; the non-technical sections explain how it survived eight years. Skip the second half at your peril.

Canon and Citations — Grounded Best Practices

This file grounds every principle in the skill against the established canon of platform engineering, SRE/DORA, software architecture, and staff+ engineering literature (as of May 2026). Every claim has a named, dated source. No invented citations.

Five canon clusters, each with the named sources that ground the corresponding skill claims:

1. Platform Engineering canon 2. SRE & DORA canon 3. Architecture Patterns canon 4. Modern Tooling (2026 reality check) 5. Staff+ Engineering canon

The companion file `07-contrasts.md` sorts the skill's claims into three buckets — canonical / novel / controversial vs the canon — and is the place to look for where the Atlassian-talk's patterns either align with, extend, or run against established practice.

---

1. Platform Engineering Canon

The talk's "platform team" maps onto a canonical pattern. Skelton & Pais's Team Topologies (2019, IT Revolution) defines four canonical team types — stream-aligned, platform, enabling, and complicated-subsystem — and three interaction modes — collaboration, X-as-a-service, and facilitating. The Atlassian load-balancing team is a textbook platform team: small headcount, owning a self-service contract (OSB) over a complicated subsystem (the Envoy fleet), serving ~1000 stream-aligned services as customers via X-as-a-service. The book's "Thinnest Viable Platform" rule — start with the minimum that unblocks consumers, even if "just a wiki page" — is the principle that governs which features to build first.

Conway's Law makes the architecture inevitable. Melvin Conway's 1968 Datamation paper (after rejection by HBR for being "anecdotal") states: "Any organization that designs a system… will inevitably produce a design whose structure is a copy of the organization's communication structure." The Inverse Conway Maneuver — deliberately designing team boundaries to produce the desired architecture — was coined by LeRoy & Simons in the December 2010 Cutter IT Journal. Forsgren, Humble & Kim's Accelerate (2018) gives the empirical backing: "organizations should evolve their team and organizational structure to achieve the desired architecture." The Atlassian shape — one small platform team producing one coherent control plane (Sovereign) — is an Inverse-Conway construct.

The 2026 Internal Developer Platform (IDP) canon. Backstage (Spotify, donated to CNCF September 2020, Incubating since March 2022, Apache-2.0) is the dominant open-source framework — current stable v1.50.0 (April 2026), 3,400+ adopting organizations, 2M+ developers. Backstage gives what Sovereign+OSB didn't: a unified developer-facing portal (Software Catalog + TechDocs + Software Templates + Scaffolder). Sovereign+OSB had what Backstage still doesn't: an opinionated runtime. Humanitec's State of Platform Engineering Reports (Volumes 1-3, 2022-2024; Volume 4 in 2025 by platformengineering.org with Broadcom sponsorship) push the "Platform-as-a-Product" thesis — "organizations that mandate adoption by top-down decree underperform those that build a platform so useful that teams choose it voluntarily." This is the canon's direct challenge to the talk's "forced migration via removed alternatives".

Anti-patterns. Thoughtworks's Technology Radar marked "Miscellaneous platform teams" as Hold (March 2022): platform labels applied to "initiatives lacking clear outcomes or a well-defined set of customers" produce ivory-tower teams. The antidote — "Platform engineering product teams" — sits in Adopt. Gregor Hohpe's The Software Architect Elevator (O'Reilly, 2020) names the deeper failure mode: architects who don't ship code lose feedback on the consequences of their decisions. The Atlassian team's structural protection was that they got paged for what they shipped — a small platform team with deep operational ownership can't go ivory-tower.

Bibliography (Platform Engineering)

• Skelton, M., & Pais, M. (2019). Team Topologies. IT Revolution. ISBN 9781942788812.
• Conway, M. E. (1968, April). "How Do Committees Invent?" Datamation, pp. 28-31. https://www.melconway.com/Home/pdf/committees.pdf (Issue number disputed in secondary citations — Wikipedia intro uses 14(4), references section uses 14(5); melconway.com itself lists only "April 1968".)
• LeRoy, J., & Simons, M. (2010, December). "Dealing with Creaky Legacy Platforms." Cutter IT Journal. (Origin of "Inverse Conway Maneuver".)
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution.
• Backstage (CNCF Incubating). https://backstage.io/ | CNCF page: https://www.cncf.io/projects/backstage/
• Humanitec. State of Platform Engineering Reports Vols 1-3 (2022-2024). https://humanitec.com/state-of-platform-engineering
• platformengineering.org / Broadcom. State of Platform Engineering Report Vol 4 (2025). https://platformengineering.org/
• Thoughtworks Technology Radar: "Miscellaneous platform teams" (Hold, March 2022). https://www.thoughtworks.com/radar/techniques/miscellaneous-platform-teams
• Hohpe, G. (2020). The Software Architect Elevator. O'Reilly. Excerpted: https://martinfowler.com/articles/architect-elevator.html

---

2. SRE & DORA Canon

Toil discipline. The canonical definition lives in Chapter 5 of the Google SRE Book (Beyer et al, 2016, O'Reilly), written by Vivek Rau: toil is work that is "manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows." The talk's "churn is a smell" maps directly onto the scales-linearly criterion. Google's structural commitment: 50% engineering minimum, 25% on-call maximum, 25% other ops maximum — an explicit numeric cap enforced at management level. The talk's "50-70% building / 20-30% maintaining / 10-20% operating" ratio is the same shape, slightly rebalanced toward building.

Error budgets and the velocity/reliability control loop. Chapter 3 of the 2016 SRE Book ("Embracing Risk") introduces the error-budget mechanism: quantify reliability as a budget that can be spent on velocity. When budget is healthy, product ships freely; when drained, releases halt until recovery. This is the conceptual home of the talk's implicit "stability + change" balance.

Symptom-based alerting and runbook discipline. The Site Reliability Workbook (Beyer et al, 2018, O'Reilly) Chapter 5 ("Alerting on SLOs") prescribes alerting on user-visible symptoms (SLO burn rate), not internal causes. Chapter 8 ("On-Call") defines the canonical playbook structure: one entry per alert, with severity/impact, debugging suggestions, mitigation steps. The talk's log message catalog + metric catalog + failure mode catalog + recovery procedures is this canonical structure restated.

DORA's four keys. Accelerate (Forsgren/Humble/Kim, 2018) codifies deployment frequency, lead time for changes (throughput) + change failure rate, MTTR (stability). The book's central empirical finding: throughput and stability are not in tension; quality equals speed. Loosely-coupled architecture (which the Atlassian platform exemplifies) correlates with elite performance on all four metrics.

The platform-engineering J-curve. The 2024 DORA Report (Google Cloud, ~39,000 respondents) studied platform engineering as a primary theme. The headline finding: IDPs produce +8% individual productivity and +10% team productivity — but −8% throughput and −14% stability in the average implementation (the J-curve effect: temporary dip before improvements manifest as the platform matures). The cure is user-centricity — "platform as product" — with continuous developer- customer feedback.

AI as amplifier (the 2025 finding). The 2025 DORA Report — State of AI-Assisted Software Development — is the canonical reference for the talk's AI-coupling risk claim. 90% of respondents use AI at work (median 2h/day). AI adoption now positively correlates with throughput — and with higher instability, more change failures, more rework. "Individual productivity boosts are frequently lost to 'downstream disorder.'" When platform quality is high, AI's effect is strong and positive; when platform quality is low, AI's effect is negligible. The talk's framing — AI amplifies maintenance burden — is exactly this finding.

The metrics debate. Will Larson (lethain.com) argues write strategy first, then measure. Gergely Orosz & Abi Noda's January 2024 survey of 17 tech companies found no company uses DORA or SPACE wholesale; everyone uses context-specific blends. Lorin Hochstein (resilience engineering, ex-Netflix): "Resilience is about the stuff that isn't visible through the metrics." The talk's posture — name the failure modes, catalog them, accept that maintenance is engineering work — sits in exactly this debate.

Bibliography (SRE / DORA)

• Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site Reliability Engineering. O'Reilly. https://sre.google/books/
• Beyer, B., Murphy, N. R., Rensin, D. K., Kawahara, K., & Thorne, S. (Eds.). (2018). The Site Reliability Workbook. O'Reilly. https://sre.google/workbook/
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution.
• DORA / Google Cloud. (2024). Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/
• DORA / Google Cloud. (2025). State of AI-Assisted Software Development (2025 DORA Report). https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
• Larson, W. Measuring an Engineering Organization. https://lethain.com/measuring-engineering-organizations/
• Orosz, G., & Noda, A. (2024, January 16). Measuring Developer Productivity: Real-World Examples. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-bae
• Hochstein, L. Surfing Complexity blog. https://surfingcomplexity.blog/

---

3. Architecture Patterns Canon

Bounded Context and Anti-Corruption Layer (Evans 2003). Evans's Domain-Driven Design (Addison-Wesley) introduces the Anti-Corruption Layer at p. 364: "As a downstream client, you create an isolating layer to provide your system with functionality of the upstream system in terms of your own domain model. This layer talks to the other system through its existing interface, requiring little or no modification to the other system." The talk's "validate at the boundary" is the semantic-translation form of the ACL responsibility — ACL kicks in when upstream and downstream have different models that need translation; pure schema validation is a complementary boundary concern (closer to defensive programming / type narrowing). The platform's edge layer maps onto Evans's Open Host Service (p. 374) — the upstream half of a context map, with a published interface multiple consumers translate via their own ACLs.

Gateway pattern + Strangler Fig (Fowler 2002, 2004). Fowler's Gateway pattern (PoEAA p. 466) is the parent of every API-gateway and sidecar-proxy variant: "a simple wrapper… construct an interface that supports [what our code needs to do with the external system] clearly and directly." The talk's "centralize cross-cutting concerns at the edge" is Fowler's argument that adapter code lives in one named place. The Strangler Fig Application (Fowler, 2004; renamed 2019-04-29) IS the forced-migration pattern the talk describes: "gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled." Microsoft's Azure Architecture Center adopts the pattern verbatim (learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig).

Fitness functions (Ford, Parsons, Kua 2017; 2nd ed. 2023). Building Evolutionary Architectures formalizes architecture characteristics as continuously-tested constraints. A fitness function is "any mechanism that provides an objective integrity assessment of some architecture characteristic(s)" — classified along axes: atomic vs holistic, triggered vs continuous, static vs dynamic. The talk's "churn is a smell" is a textbook atomic, triggered, dynamic fitness function: commit-frequency-per-file over a rolling window, threshold-gated in CI. "Coupling accretes silently" has a direct answer: ArchUnit-style dependency rules + connascence audits, indexed in the 2nd edition's subtitle Automated Software Governance.

Sagas for async task orchestration (Richardson 2018; Ford et al 2021). Software Architecture: The Hard Parts catalogs eight saga patterns named by three binary axes — communication (sync/async), consistency (atomic/eventual), coordination (orchestrated/choreographed). The FastAPI→SQS→Worker→DynamoDB pattern matches Parallel Saga (async-eventual-orchestrated) in shape; whether it implements full transactional saga semantics (compensating transactions on failure) depends on the worker's design — the talk doesn't describe compensation explicitly, so the pattern is more precisely a workflow with the Parallel Saga shape. Richardson's saga entry (microservices.io/patterns/data/saga.html) is the canonical reference: "a sequence of local transactions… each transaction publishes a message or event that triggers the next transaction", with compensating transactions for rollback. The DynamoDB row is the orchestrator's persisted state machine.

12-Factor App, Factor V (Wiggins 2011). Factor V — "The twelve- factor app uses strict separation between the build, release, and run stages" — defines three immutable stages: build (codebase → executable bundle), release (build + config → tagged release), run (execute selected release). "Releases are an append-only ledger and a release cannot be mutated once it is created." The talk's three IaC layers — image / infra / runtime — map 1:1 onto Factor V's three stages.

AWS Well-Architected Framework. Six pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability). Operational Excellence prescribes async decoupling ("Implement loosely coupled dependencies", OPS-05) with SQS named explicitly. Reliability (REL08, "Implement change") requires IaC and immutable infrastructure as the named mechanism. Loosely coupled dependencies + graceful degradation + bounded retries are the three core distributed-systems patterns — all three present in the talk's architecture.

Architecture Decision Records (Nygard 2011). The lightweight ADR template — Title (numbered noun phrase), Context (forces at play), Decision (active voice), Status, Consequences — captures architectural decisions for future readers. Thoughtworks moved ADRs to Adopt in 2018. The skill itself can be read as an ADR-shaped archive: each principle is one decision with context and consequences.

Bibliography (Architecture Patterns)

• Evans, E. (2003). Domain-Driven Design. Addison-Wesley. ISBN 0-321-12521-5. Bounded Context p. 335; Anti-Corruption Layer p. 364; Open Host Service p. 374.
• Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 0-321-12742-0.
• Fowler, M. (2004; renamed 2019). "Strangler Fig Application." https://martinfowler.com/bliki/StranglerFigApplication.html
• Fowler, M., & Lewis, J. (2014, March 25). "Microservices." https://martinfowler.com/articles/microservices.html
• Ford, N., Parsons, R., Kua, P., & Sadalage, P. (2023). Building Evolutionary Architectures: Automated Software Governance (2nd ed.). O'Reilly. ISBN 978-1-492-09754-9.
• Ford, N., Richards, M., Sadalage, P., & Dehghani, Z. (2021). Software Architecture: The Hard Parts. O'Reilly. ISBN 978-1-492-08689-5.
• Richardson, C. (2018). Microservices Patterns. Manning. ISBN 978-1-617-29454-9.
• Richardson, C. "Pattern: Saga." https://microservices.io/patterns/data/saga.html
• Wiggins, A. (2011). The Twelve-Factor App. https://12factor.net/ | Factor V: https://12factor.net/build-release-run
• AWS. AWS Well-Architected Framework. https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
• Brown, S. The C4 Model. https://c4model.com/
• Nygard, M. (2011, November 15). "Documenting Architecture Decisions." https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions
• Microsoft Learn. "Strangler Fig Pattern." https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig

---

4. Modern Tooling (2026 Reality Check)

The Atlassian stack was built 2017-2025. The talk's tooling choices are honest about their era; this section says which are still current and which have rotated.

Envoy v1.38 (April 2026); xDS v3 final. Envoy's official versioning policy: v3 is the final major API version, supported "forever" — no v4 on the roadmap. The Atlassian-era custom xDS server (FastAPI polling S3) was a 2017 workaround; the 2026 canonical recommendation is `github.com/envoyproxy/go-control-plane` — official envoyproxy org, proto-synced upstream, embeddable. Istio Pilot, Envoy Gateway, Gloo, and Consul all build on it. Streaming gRPC + ADS (Aggregated Discovery Service) with Delta-xDS (incremental updates) is the production default for large fleets.

OSB v2.17 not deprecated, but effectively orphaned. The spec at github.com/openservicebrokerapi/servicebroker is technically alive (969 commits, low-volume issues, ongoing CF SMWG community calls), but OpenShift formally deprecated OSB in OpenShift 4 in favor of OLM (Operator Lifecycle Manager). For Kubernetes-native shops, Crossplane Compositions are the 2026 idiomatic substrate.

Crossplane 2.0 (August 12, 2025); v2.2 current. Composite Resources (XRs) and Composite Resource Definitions (XRDs) are the 2026 vendor- neutral platform-API pattern. Key 2.0 shifts: (1) Compositions can include any K8s resource (not just managed infrastructure); (2) namespace-first by default; (3) composition functions are now the only supported composition model; (4) new Operations type for one-off / scheduled / event-driven workflows.

Istio Ambient Mesh GA November 7, 2024 (Istio 1.24). Architecture: per-node ztunnel DaemonSet (Rust, L4 mTLS via HBONE) + waypoint proxies (Envoy, L7, per-namespace/service). Published savings: ~90%+ proxy resource reduction vs sidecars. Sidecars not deprecated — Istio explicitly: "Sidecars remain first-class citizens." Linkerd disagrees — their Rust micro-proxy (linkerd2-proxy) sidecars are so light that Buoyant benchmarks claim Ambient uses more total resources; they argue sidecars preserve a clean per-pod security boundary. The talk's "Envoy as sidecar" assumption is now a choice, not the default.

SMI archived September 25, 2023. The Service Mesh Interface consolidated effort into the Kubernetes Gateway API's GAMMA initiative (SIG-Network). Any 2026 design citing SMI primitives is using a dead spec; the canonical surface is now Gateway API HTTPRoute/ GRPCRoute/TLSRoute + GAMMA extensions.

Backstage v1.50 (April 2026); Spotify Portal GA Oct 2025. Build-vs- buy has tilted to buy or hybrid for non-Spotify-scale orgs. Port.io's published 3-year TCO for self-hosted Backstage at a 300-developer org: ~$3.25M. Gartner forecasts 80% of large engineering orgs will have platform teams by 2026 (up from 45% in 2022). The 2026 question is no longer "should we build this in-house?" but "what golden paths differentiate our buy/hybrid platform?"

SaltStack in decline. Acquired by VMware (2020), then Broadcom (2023). Now "VMware Cloud Foundation SaltStack" with commercial support through October 2028; OSS community future is contested (GitHub discussion #67028 documents the uncertainty). For new builds in 2026: prefer Ansible (Red Hat / IBM, dominant), or move to bake-don't- configure patterns (Packer + immutable AMIs).

Terraform Stacks GA at HashiConf 2025; CDKTF deprecated Dec 2025. The modern IaC composition primitive coordinates deployment of interdependent modules with linked Stacks for cross-stack outputs. OpenTofu (Linux Foundation, MPL-2.0) is the BSL-relicensing fork. Pulumi (typed IaC in TS/Python/Go/C#/Java) growing ~45% YoY in developer-heavy orgs.

WASM filters are orthogonal to the sidecar debate. Envoy's WASM filter chains (proxy-wasm ABI; V8/WAMR/Wasmtime runtimes) run inside Envoy (sidecar or ambient waypoint) — they replace per-language custom C++ filters, not the sidecar pattern itself. Istio formalized this with WasmPlugin CRD. For the Atlassian-era pattern, WASM is the natural place to land what used to be in-house Envoy filter forks.

Edge moved beyond the CloudFront model. Three architectural camps: Cloudflare Workers (V8 isolates, 330+ PoPs, sub-5ms cold starts; KV/R2/D1/Durable Objects/Queues/Hyperdrive on one bill); Vercel Edge Functions / Fluid Compute (V8 isolates + Node.js-subset Edge Runtime, 19 regions, dominant for Next.js SSR); Fastly Compute (Wasmtime). The 2026 convergence: placement (edge vs origin) is becoming a platform optimization rather than a deployment decision. A meaningful slice of what was sidecar-Envoy logic in 2017-2020 (auth, rate-limit, header rewrite, A/B routing) now lives in Workers / Edge Functions.

Bibliography (Modern Tooling)

• Envoy Project. xDS REST and gRPC protocol (1.39.0-dev docs). https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
• envoyproxy/envoy. Releases (v1.38.0 April 23, 2026). https://github.com/envoyproxy/envoy/releases
• envoyproxy/go-control-plane. https://github.com/envoyproxy/go-control-plane
• Open Service Broker API. https://github.com/openservicebrokerapi/servicebroker
• Red Hat. OpenShift 4 OSB deprecation. https://access.redhat.com/documentation/en-us/openshift_container_platform/4.1/html/applications/service-brokers
• Crossplane. Announcing Crossplane 2.0 (Aug 12, 2025). https://blog.crossplane.io/announcing-crossplane-2-0/
• Istio. Fast, Secure, and Simple: Istio's Ambient Mode Reaches GA in v1.24 (Nov 7, 2024). https://istio.io/latest/blog/2024/ambient-reaches-ga/
• CNCF. CNCF Archives the Service Mesh Interface (SMI) Project (Sept 25, 2023). https://www.cncf.io/blog/2023/10/03/cncf-archives-the-service-mesh-interface-smi-project/
• Backstage v1.50.0. https://github.com/backstage/backstage
• Spotify Portal. https://backstage.spotify.com/
• Tasrie IT Services. Port vs Backstage vs Cortex (2026). https://tasrieit.com/blog/port-vs-backstage-vs-cortex-developer-portal-comparison-2026
• HashiCorp. Packer 1.14. https://developer.hashicorp.com/packer
• HashiCorp. Terraform Stacks (HashiConf 2025 GA). https://www.hashicorp.com/en/blog/scale-infrastructure-with-new-terraform-and-packer-features-at-hashiconf-2025
• Broadcom. VMware Cloud Foundation SaltStack support through Oct 2028. https://knowledge.broadcom.com/external/article/413088
• Tetrate. Wasm extensions and Envoy extensibility. https://tetrate.io/blog/wasm-modules-and-envoy-extensibility-explained-part-1
• Buoyant. Sidecars or Sharing. https://www.buoyant.io/blog/sidecars-or-sharing-a-practical-guide-to-selecting-your-service-mesh

---

5. Staff+ Engineering Canon

Three pillars of the staff role (Reilly 2022). The Staff Engineer's Path (O'Reilly) organizes the role around Big Picture Thinking, Execution, Leveling Up. The third pillar (Part III) is the canonical citation for the talk's colleague-as-customer model. Its opening chapter is "You're a Role Model Now (Sorry)" (the parenthetical is Reilly's, addressing the passive role-modelling dimension); the companion chapter "Good Influence at Scale" covers the active form, including her framing that influence at scale is delegated through systems, not delivered through individual heroics — "Creating robots, policies, and processes that reinforce your message scales further than being a guardrail for individual colleagues." Her sponsorship reframe: "Opportunities can be much more valuable than advice. Share the spotlight in your team."

Mentoring vs teaching (Fournier 2017). The Manager's Path Chapter 2 ("Mentoring") opens: "An opportunity to mentor gives you a chance to learn how to be a manager — in a safe environment, as people rarely get fired for bad mentorship." The chapter distinguishes career mentoring from technical mentoring and warns against the Alpha Geek anti-pattern — the senior engineer who answers questions instead of growing the asker. The talk's "mentoring ≠ teaching" distinction is Fournier's exact framing.

Tech Lead archetype (Larson 2021). Staff Engineer (staffeng.com) defines four archetypes: Tech Lead, Architect, Solver, Right Hand. The talk's speaker — long-tenured in one stack, owning a system over many years, partnered with one or two managers — is unambiguously the Tech Lead archetype: "guides the approach and execution of a particular team. Partners closely with a single manager…the most accessible archetype to attain your first Staff engineering role." Tech Lead and Architect "work with the same people on the same problems for years, developing a tight sense of team" — the talk's exact pattern.

Curse of knowledge (Camerer/Loewenstein/Weber 1989; Heath brothers 2007). Coined in the Journal of Political Economy 97(5):1232-1254: "Better-informed agents are unable to ignore private information even when it is in their interest to do so; more information is not always better." Market forces reduce the bias by ~50% but never eliminate it. The Heath brothers' Made to Stick (2007) is the popularization vector, naming Curse of Knowledge as the "arch villain" of communication and illustrating with Elizabeth Newton's 1990 Stanford "tappers and listeners" experiment: tappers predicted listeners would identify their tapped songs 50% of the time; actual rate was 2.5%.

Radical Candor (Scott 2017). The 2×2: Care Personally × Challenge Directly. Four quadrants: Radical Candor (both high); Obnoxious Aggression (challenge without care); Ruinous Empathy (care without challenge — "by far the most common quadrant"); Manipulative Insincerity (neither). The talk's "diplomacy is an engineering skill" maps onto Care Personally; "anticipate conflict" maps onto Challenge Directly. The most-cited operational guidance: solicit feedback before giving it. Scott's prompt: "What could I do or stop doing that would make it easier to work with me?"

Andy Grove's leverage equation (1983). High Output Management: "A manager's output = the output of his organization + the output of the neighbouring organizations under his/her influence." This is the formal statement of the colleague-as-customer model. The senior engineer who spends more time helping colleagues than typing code is not deviating from output — they are maximizing it via Grove's equation. "If you gather and share information you're a manager. More specifically, a know-how manager" — the staff-IC equivalent.

Mentoring research (Kram 1985; Allen et al 2004). Kram's two- function model: career functions (sponsorship, coaching, exposure, protection, challenging assignments) + psychosocial functions (role- modelling, acceptance, counselling, friendship). Allen et al's Journal of Applied Psychology 89(1) meta-analysis: psychosocial benefits and subjective career satisfaction show stronger effects than compensation/promotion. The implication for "mentoring ≠ teaching": the value senior engineers create through mentoring shows up most reliably in the psychosocial dimension, not in API-tutorial outcomes.

Psychological safety (Edmondson 1999, 2018). Administrative Science Quarterly 44(2):350-383: "A shared belief held by members of a team that the team is safe for interpersonal risk taking" — safe to ask questions, admit ignorance, raise concerns. Edmondson's 51-team manufacturing study found psychological safety predicts learning behaviour, which mediates team performance. The book-length treatment is The Fearless Organization (Wiley, 2018). Note: the often-cited "four stages of psychological safety" is Timothy R. Clark's, not Edmondson's.

Bibliography (Staff+ Engineering)

• Reilly, T. (2022). The Staff Engineer's Path. O'Reilly. ISBN 9781098118730.
• Fournier, C. (2017). The Manager's Path. O'Reilly. ISBN 9781491973899.
• Larson, W. (2021). Staff Engineer: Leadership Beyond the Management Track. Stripe Press. https://staffeng.com/ | Archetypes: https://staffeng.com/guides/staff-archetypes/
• Camerer, C., Loewenstein, G., & Weber, M. (1989). "The Curse of Knowledge in Economic Settings." Journal of Political Economy 97(5):1232-1254. DOI 10.1086/261651. https://www.cmu.edu/dietrich/sds/docs/loewenstein/CurseknowledgeEconSet.pdf
• Heath, C., & Heath, D. (2007). Made to Stick. Random House. ISBN 9781400064281.
• Newton, E. L. (1990). The Rocky Road From Actions to Intentions (Doctoral dissertation, Stanford). Source of the tappers-and-listeners experiment.
• Scott, K. (2017). Radical Candor. St. Martin's Press. https://www.radicalcandor.com/our-approach
• Grove, A. S. (1983). High Output Management. Random House. ISBN 9780679762881.
• Kram, K. E. (1985). Mentoring at Work. Scott Foresman. ISBN 9780673156174.
• Allen, T. D., Eby, L. T., Poteet, M. L., Lentz, E., & Lima, L. (2004). "Career Benefits Associated With Mentoring for Protégés: A Meta-Analysis." Journal of Applied Psychology 89(1):127-136. DOI 10.1037/0021-9010.89.1.127.
• Edmondson, A. C. (1999). "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly 44(2):350-383. DOI 10.2307/2666999.
• Edmondson, A. C. (2018). The Fearless Organization. Wiley. ISBN 9781119477242.
• Hogan, L. (2019). Resilient Management. A Book Apart. https://resilient-management.com/ | Feedback Equation: https://larahogan.me/blog/feedback-equation/

---

How to cite this skill (with grounding)

When the skill informs a design decision, cite both the talk source and the canonical grounding:

Pattern X applied per architecture-design-principles skill

(~/.agents/skills/architecture-design-principles/), grounded in

[canonical source] — see references/06-canon-and-citations.md §N.

The contrast matrix in `07-contrasts.md` tracks where each pattern is canonical, novel, or controversial — useful when arguing the design in code review.

Contrasts — Where the Atlassian Patterns Sit Against Canon

For each principle the skill teaches, this file sorts the claim into one of three buckets vs the established canon:

• CANONICAL — the talk's pattern has a named, dated source in the

canon. Use the canonical name in code review and PRs.

• NOVEL — the talk extends or sharpens canonical patterns in a way

worth keeping.

• CONTROVERSIAL — the canon disagrees, or the canon's 2026 position

diverges. The talk's pattern may still be right for some contexts; the controversy is part of the design conversation.

The canonical sources cited below are detailed in `06-canon-and-citations.md`.

Contrast matrix

Where the talk extends canon

Forced migration as a refinement of Strangler Fig

Strangler Fig (Fowler 2004) describes the gradual replacement shape: a new system grows around the edges of the old until the old is fully strangled. The talk's contribution is the specific forcing function: "you can no longer expose your service publicly through the [old] load balancer." The old system kept working — for internal traffic. The forcing function was specific (public exposure) rather than total (delete the old thing).

This is a refinement worth keeping in the canonical lexicon: a specific forcing function is a wall, not a cliff. Teams can choose when to climb it; eventually they must. Total deprecation generates escape-valve work; specific forcing functions don't.

The novel claim is that this forcing-function mechanism is what made the migration feasible at all in a high-trust platform-team context. The canon's preferred lever (Humanitec's "Platform-as-a-Product": build it so good they migrate voluntarily) is more diplomatic but slower; the talk's lever is faster but requires organizational backing.

"Three IaC layers" as a 2026 update of 12-Factor V

12-Factor's Build/Release/Run was 2011-era guidance written for single-process apps deployed to Heroku-shaped PaaS. The talk's three- IaC-layer pattern updates this for fleet-scale infrastructure:

• Build (12-Factor) → Image layer (Packer/SaltStack → AMI)
• Release (12-Factor) → Infra layer (CloudFormation/Terraform

Stacks) + Runtime config layer (xDS / Sovereign / templates)

• Run (12-Factor) → Running fleet (the Envoy proxies receiving

config)

The novel contribution: 12-Factor doesn't distinguish between infrastructure provisioning and runtime configuration, because in 2011 those were the same thing (your env vars + your image = your release). At fleet scale they're not — VPCs change once a year, runtime config changes per pull request. The talk's three-layer split is the durable shape for 2026.

"Churn as smell" as an atomic fitness function

Building Evolutionary Architectures (Ford/Parsons/Kua 2017, 2nd ed 2023) introduces fitness functions but doesn't enumerate churn-rate as a canonical one. The talk identifies the symptom; the canon's mechanism (continuous testing, CI gating) provides the implementation:

# Atomic, triggered, dynamic fitness function: churn-as-CI-gate
git log --since="1 year ago" --name-only --pretty=format: \
  | sort | uniq -c | sort -rn | head -20 \
  | awk '{ if ($1 > THRESHOLD) print "CHURN: " $2 }' \
  | tee churn-violations.txt
test ! -s churn-violations.txt  # fail CI if any

This composes the talk's diagnosis with the canon's machinery. Neither half exists in the published canon, but the combination is implied by both.

Where canon disagrees with the talk

Sidecars in 2026

The talk's claim: "When the proxy can't do something natively, run it as a sidecar locally; same machine, low latency, contributable by other teams."

The 2026 canon's position is split:

• Istio Ambient (GA November 7, 2024) moves L4 to a per-node

ztunnel and L7 to per-namespace waypoint proxies outside application pods. Resource savings of ~90% vs sidecars. Istio's position: "most use cases will be best served with a mesh in ambient mode." Sidecars not deprecated, but not the default either.

• Linkerd doubles down on sidecars — their Rust micro-proxy is

~20-30MB vs Envoy's 50+MB; Buoyant's published benchmarks claim Linkerd's sidecars use less total resource than Istio Ambient. Their argument: sidecars preserve a clean per-pod security boundary that node-shared ztunnels dilute.

• The 2024 CNCF Annual Survey shows overall service-mesh adoption

dropped from 50% to 42% YoY — teams becoming more deliberate, not less.

The talk's sidecar claim is still valid in 2026, but it is now a deliberate architecture choice with explicit trade-offs, not the default. A 2026 design referencing "the Atlassian sidecar pattern" should also say which side of the ambient debate it chooses and why.

Open Service Broker vs Crossplane

The talk uses OSB as its consumer contract. In 2026:

• OSB v2.17 is not deprecated — the spec is still maintained at

github.com/openservicebrokerapi/servicebroker, with ongoing community calls in the Cloud Foundry Service Management Working Group.

• BUT: OpenShift formally deprecated OSB in OpenShift 4 in favor of

OLM (Operator Lifecycle Manager). The Kubernetes Service Catalog SIG is effectively dormant.

• Crossplane Compositions (Crossplane 2.0, August 12, 2025) are the

2026 Kubernetes-native equivalent of "platform team defines a resource shape, consumer teams self-service it."

For a 2026 greenfield Kubernetes-native platform: choose Crossplane XRDs + Compositions. For cross-platform federation or CloudFoundry shops: OSB still works. The talk's substance (a typed contract between platform team and consumers) survives; the specific OSB encoding is no longer the default.

Forced migration vs "Platform-as-a-Product"

Humanitec's State of Platform Engineering Reports (Volumes 1-3, 2022-2024; Vol 4 in 2025 by platformengineering.org / Broadcom) push the explicit thesis: "organizations that mandate adoption by top-down decree underperform those that build a platform so useful that teams choose it voluntarily." The talk's "forced migration via removed alternatives" cuts against this.

The resolution: both can be true depending on context.

• In a high-authority platform-team context (the talk's setting at

Atlassian, with executive backing to enforce a forcing function), forced migration via removed alternatives is faster and produces cleaner end state.

• In a low-authority platform-team context (most companies), forcing

functions generate revolt and destroy platform-team credibility. Voluntary adoption via product quality is the only path.

The talk's pattern is right given its prerequisites; the canon is right given other prerequisites. The skill should be explicit about which prerequisites apply.

Custom xDS server vs go-control-plane

The talk built Sovereign as a custom xDS management server in Python/ FastAPI. In 2017 this was the right call — no mature open-source xDS control plane existed.

In 2026, the canonical recommendation is `github.com/envoyproxy/go-control-plane` — official envoyproxy org, proto-synced upstream on every commit, V2 removed. Istio Pilot, Envoy Gateway, Gloo, and Consul all build on it. Building a custom xDS server from scratch in 2026 is legitimate for narrow use cases (e.g., a stateful-backend fleet with high IP/port churn) but is no longer the default.

If today's design calls for a "Sovereign-shaped" control plane, the 2026 starting point is go-control-plane + your own logic on top, not a from-scratch xDS implementation.

A note on age and freshness

The talk describes a system built 2017-2025. The talk's tools have aged differently:

This isn't a list of mistakes in the talk — it's a list of where the talk's specific tooling choices show their age. The patterns the talk teaches outlive any specific tool; the implementations don't.

How to use this matrix in code review

When defending a design that uses one of the talk's patterns:

1. Cite the canonical name from the matrix above (e.g., "Anti- Corruption Layer" instead of "validate at the boundary"). 2. If the bucket is CANONICAL, point at the canonical source — reviewers can verify on their own time. 3. If the bucket is NOVEL, name what's novel and why it's worth the extension (the talk's contribution). 4. If the bucket is CONTROVERSIAL, acknowledge the canon's counter-position and state why the talk's pattern still fits.

This is the operating discipline of grounded design: every pattern has a canonical anchor, and where you depart from canon you do so deliberately and with a stated reason.

Key Frames from the Talk

Eight key frames extracted from the talk at decision-illustrating moments. Each is a JPEG screenshot of the speaker's Excalidraw whiteboard at a specific timestamp.

Reading the diagrams

The whiteboard uses Excalidraw conventions:

• Rounded rectangles = services / components
• Circles = proxies (Envoy specifically)
• Arrows = data flow direction
• Cluster boxes = grouping (Open Service Broker, Sovereign, EC2,

AWS CloudFormation Template are all cluster names)

• Text annotations = labels and counts (e.g., "2000 proxies, 13 regions")

ASCII reconstruction

For an ASCII version that can be copy-pasted into specs/docs, see the "Reference Architecture" section in ../../SKILL.md.

Source: Talk Attribution and Chapter Map

Attribution

• Title: "I was laid off by Atlassian"
• Speaker: Vasilios Syrakis
• Date: 2026-05-10
• Duration: 40:05
• URL: https://www.youtube.com/watch?v=55pTFVoclvE
• Format: First-person retrospective, screen-shared Excalidraw whiteboard
• Speaker's history: ~8 years at Atlassian (2017-2025), platform engineer

on the edge / load-balancing team. Built and open-sourced Sovereign (an Envoy xDS management server in Python/FastAPI).

Why this is worth distilling

The talk is unusual in three ways:

1. Chronological build-up. The speaker shows what was built in the order it was built, including the wrong turns (Connection library → Flask → FastAPI). Most architecture content shows the final state and omits the sequence. 2. Specific tools named. Envoy, Hashicorp Packer, SaltStack, CloudFormation, FastAPI, DynamoDB, SQS, CloudFront, Route53, ACM, Connection (Python lib), Sovereign (open-sourced). This anchors the patterns to real implementations. 3. Non-technical postscript. The last 8 minutes cover diplomacy, mentoring, conflict, and the curse-of-knowledge. Most architecture talks omit this; this one centers it.

Chapter map (from YouTube)

The reference diagram

The complete architecture appears in the talk around 21:30 (see ../diagrams/01-full-architecture.jpg).

Reconstruction in ASCII appears in SKILL.md.

Components on the whiteboard:

• Open Service Broker cluster: FastAPI → SQS → Worker → DynamoDB; worker

also creates Route53/CloudFront/API-calls (the "Provisioning Task")

• Sovereign cluster (xDS control plane): FastAPI, Configuration block

(Context, Templates → Clusters, Routes, Listeners), reads from S3 bucket

• EC2 cluster: Envoy proxies (annotated "2000 proxies, 13 regions")
• AWS CloudFormation Template cluster: Parameters, VPC, Subnet, IGW,

SecurityGroup, AutoscalingGroup, NLB, IAM Role, Route53, KeyPair, ACM, feeding AMI

• Hashicorp Packer + SaltStack Configuration for AMI building

Open source artifact

Sovereign — Envoy xDS management server, Python/FastAPI. Vasilios mentions: "I open sourced this software and I called it Sovereign. You can actually go find that on Bitbucket. It's a public repo at least for now. I don't know if that's going to be the case always."

The design pattern is more durable than the specific repo. Modern equivalents:

• Istio Pilot (Go) — Kubernetes-native xDS server
• Solo.io Gloo (Go) — Envoy-based API gateway with control plane
• Envoy Gateway (Go) — official Envoy project

Stack summary

How to cite this skill

When this skill informs a design decision or recommendation, cite as:

Architecture & design principles distilled from V. Syrakis, "I was laid

off by Atlassian" (https://www.youtube.com/watch?v=55pTFVoclvE, 2026-05-10),

see ~/.agents/skills/architecture-design-principles/.