Parent folderOpen Confluence

RWS Architecture article

ADR-017 Service Mesh: ambient-first target default (production exception request)

The platform aims to offer a multi-cluster service mesh capability on top of OpenShift Service Mesh 3. The preferred architecture pattern is to host control planes on dedicated ser

  1. Typeadr
  2. Statusdraft
  3. Domainplatform
On this page
  1. Context and Problem Statement
  2. Decision Drivers
  3. Considered Options
  4. Decision Outcome
  5. Default topology (target)
  6. Exception gates (exit criteria)
  7. Next Decision Trigger
  8. Positive Consequences
  9. Negative Consequences
  10. Pros and Cons of the Options
  11. Option 1 – Sidecar mode as production default
  12. Option 2 – Production exception for ambient mode (working direction)

Context and Problem Statement

The platform aims to offer a multi-cluster service mesh capability on top of OpenShift Service Mesh 3. The preferred architecture pattern is to host control planes on dedicated service-mesh control plane clusters so workload clusters remain “data plane only” by default.

Ambient mode is attractive as a default posture because it reduces per-pod overhead (no sidecar injection) and aligns with the Red Hat Advanced Cluster Management sizing goal. Red Hat OSSM 3.2 release notes announce GA for the core ambient components (ztunnel and waypoint), while the OSSM 3.2 ambient installing guide still labels ambient mode as Technology Preview and warns that ambient/sidecar coexistence has not been thoroughly validated. Support varies by feature and topology and must be anchored to the OSSM 3.2 feature support tables for the selected OSSM release/topology.

We need an explicit decision record that:

  • prevents architecture notes from accidentally presenting Technology Preview functionality as a supported production default, and
  • captures the intended default topology and the governance needed to adopt ambient mode in production.

Decision Drivers

  • Preserve workload cluster sizing targets in a Red Hat Advanced Cluster Management posture.
  • Provide baseline L4 mTLS and L4 policy enforcement with minimal per-pod overhead.
  • Support selective L7 governance (routing/authz) where needed, without forcing sidecars everywhere.
  • Keep clear tenant isolation boundaries (administrative boundary, trust domain, blast radius) as defined in topic-openshift-service-mesh-architecture.
  • Stay within Red Hat support boundaries (avoid treating Technology Preview as “standard production”).
  • Avoid unsafe operational defaults (especially around ambient/sidecar coexistence limitations).

Considered Options

  1. Sidecar mode as production default; ambient mode only in non-production pilots until it is GA/supported.
  2. Request a production exception for ambient mode and treat ambient as the target default posture, gated by validation and explicit risk acceptance.
  3. Delay mesh rollout until ambient mode is GA/supported.

Decision Outcome

Current working direction (draft): Option 2 - request a production exception for ambient mode, with explicit gates.

This ADR does not claim ambient mode is supported for general production use today. Instead, it records that we will request an exception because ambient mode best aligns with the platform’s control plane sizing and operational posture.

Default topology (target)

  • Control plane model: control planes run on dedicated service-mesh control plane clusters (external/central control plane topology where appropriate).
  • Baseline boundary: default to “shared mesh per environment” (Option C in topic-openshift-service-mesh-architecture) to bound trust domain and blast radius by environment.
  • Tenant/domain isolation: use separate meshes/trust domains (Option B) where required by compliance or blast radius constraints.
  • Data plane posture:
  • Target: ambient mode with waypoint proxies for L7 features.
  • Until the exception is approved and validated: sidecar mode remains the production default.
  • Treat ambient+sidecar coexistence as vendor-unvalidated/unsupported in OSSM 3.2 unless Red Hat explicitly documents support for the exact topology; internal validation cannot change vendor support posture. Prefer separate meshes for sidecar-required cases (see OSSM 3.2 ambient docs).

Exception gates (exit criteria)

Production ambient use is gated by all of the following:

  • An explicit exception approval by Platform Architecture (and any required security/operations review).
  • A version-pinned evidence package confirming the OSSM support level and constraints for the intended OSSM release.
  • Successful PoC results and runbooks as defined in WP-18 Service Mesh and maintained in topic-openshift-service-mesh-architecture.
  • A documented rollback path to sidecar mode (separate mesh boundary; revision-based upgrades where supported, noting RevisionBased upgrades are NA for ambient mode in OSSM 3.2 per the OSSM 3.2 ambient mode table).

Next Decision Trigger

  • Decision owner: Platform Architecture.
  • Promote to accepted when all exception gates are met for a version-pinned OSSM release and production governance approval is recorded.
  • If support boundaries remain insufficient for required workloads, keep sidecar as default and record the reassessment date before 2026-03-15.

Positive Consequences

  • Aligns the service mesh default posture with the HyperShift “minimize per-cluster overhead” goal.
  • Makes the production support boundary explicit and reviewable.
  • Forces validation and a rollback plan before production rollout.

Negative Consequences

  • Requires exception governance and additional validation effort because ambient is Technology Preview.
  • May delay production rollout if support level or coexistence limitations block required use cases.
  • Increases complexity if some workloads require sidecar-only meshes while the ambient posture matures.

Pros and Cons of the Options

Option 1 – Sidecar mode as production default

  • Good: Clearly within current GA support boundaries.
  • Good: Avoids Technology Preview risk.
  • Bad: Higher per-pod overhead and operational complexity across many namespaces.

Option 2 – Production exception for ambient mode (working direction)

  • Good: Best fit for “low overhead” and centralized control plane goals.
  • Good: Enables incremental L7 adoption via waypoints.
  • Bad: Requires explicit governance and validation due to Technology Preview status.

Option 3 – Delay mesh rollout

  • Good: Avoids adopting Technology Preview functionality.
  • Bad: Blocks service mesh outcomes (mTLS baseline, policy, telemetry) for workloads that need them in Phase 1.

Links and References