Cross-Cloud Dependency Allow-List

Summary

This ADR extends ADR-016: Cross Cloud Dependencies. ADR-016 establishes that a Cell must not depend on another cloud provider. This ADR keeps that as the default and defines the narrow, governed exception: a short, explicitly-named allow-list of cross-cloud dependencies that are tolerated for a defined transitionary period, each with a named owner and a sunset condition. The operating principle is contained by default, cross-cloud by exception.

Context

ADR-016 set single-cloud self-containment as the rule for Cells, for cost, resiliency, and clean separation. In practice, a small number of components are centrally GitLab-operated services that do not yet have a per-cloud equivalent, and Cells on the “other” cloud must reach across to consume them during the transition to a fully cellular, multi-cloud architecture.

The concrete, already-live example is the AI Gateway: Cells deployed to Dedicated on AWS today reach the GCP-hosted AI Gateway to serve Duo/AI features. This is a working, accepted dependency, not a defect. Treating ADR-016 as absolute would mis-describe the system we actually operate, and would give teams no sanctioned path for the genuinely-shared central services that have not yet been regionalised.

The risk to manage is not the existence of cross-cloud dependencies, but their uncontrolled growth. Without an explicit list and entry criteria, ad-hoc cross-cloud calls accumulate and the ADR-016 end state (two independent single-cloud stacks) becomes unreachable.

Decision

A component on one cloud provider may depend on a component on the other cloud provider only if that dependency is on the allow-list below. Everything not on the list remains subject to ADR-016 and must be self-contained within a single cloud.

The allow-list is expected to shrink over time, not grow. Adding an entry is an architectural decision recorded by amending this ADR (a new revision or superseding ADR), not an implementation choice made ad hoc.

Criteria for an allowed cross-cloud exception

An entry may be added to the allow-list only if all of the following hold:

1. No per-cloud equivalent yet. The component is centrally GitLab-operated and a per-cloud deployment is non-trivial or not yet funded.
2. Named owner and sunset condition. The dependency has a DRI and a documented condition that retires it (what makes it go away, and roughly when).
3. Bounded, understood traffic. Cross-cloud egress is modelled for cost and latency, not incidental.
4. Graceful degradation where possible. Failure of the link degrades the dependent feature gracefully rather than taking down the Cell, consistent with the resiliency rationale of ADR-016.

The allow-list (transitionary)

Any dependency not in this table must be contained within a single cloud.

Relationship to native cross-cloud replication

A component that keeps a single logical service across clouds via native data replication (for example, the GATE/Auth stack using YugabyteDB cross-cloud replication to maintain one GitLab.com realm) is not an allow-list entry. It makes no runtime cross-cloud call: each Cell talks only to its in-cloud replica. This is the preferred pattern for the genuinely-shared stateful case and remains compliant with ADR-016. The allow-list is reserved for runtime cross-cloud dependencies only.

Consequences

Positive

• Honest model. The documented architecture matches the system actually in production (AI Gateway from AWS Cells), rather than an idealised version of it.
• Controlled surface. Cross-cloud dependency becomes an enumerated, owned, time-bounded set instead of an emergent property nobody owns.
• Clear path to the ADR-016 end state. Each entry has a sunset condition, so progress toward two independent single-cloud stacks is measurable.

Negative

• Ongoing governance cost. The list must be reviewed and entries actively driven to sunset, or it ossifies.
• Residual cross-cloud cost and compliance exposure. While entries remain (AI Gateway in particular), cross-cloud egress cost and data-egress compliance scrutiny persist.

Mitigations

• Review the allow-list at each Cells architecture / CTO review; report movement of entries toward sunset.
• Require that every new entry arrive with its sunset condition already defined, not deferred.
• Prefer the native-replication pattern (GATE/Auth) over a new runtime cross-cloud dependency wherever the shared component is stateful.

Alternatives

• Keep ADR-016 absolute (no exceptions). Rejected: it contradicts the live AI Gateway dependency and leaves shared central services with no sanctioned transitional path.
• Allow cross-cloud dependencies case-by-case without a list. Rejected: this is the status quo failure mode — dependencies accumulate with no owner, no sunset, and no aggregate view, making the single-cloud end state unreachable.

View page source - Edit this page - please contribute.