IPA-119: Multi-Cloud Support by Default

Considering support for all cloud partners supported by Atlas, even if not considered in the first iteration of an API, avoids associated API spec rework and minimizes potential customer impact involved in versioning.

Guidance

1. API producers should default to multi-cloud support when implementing features.

   components:
     schemas:
       Backup:
         type: object
         properties:
           provider:
             type: string
             enum: [PROVIDER_A, PROVIDER_B, PROVIDER_C]
           region:
             type: string

   Why:

   The provider field accepts every partner the platform supports, so a feature built on this schema works across all of them from the first release.

   components:
     schemas:
       Backup:
         type: object
         properties:
           region:
             type: string

   Why:

   The schema hard-codes a single provider implicitly by omitting any provider field. Adding a second provider later forces a breaking change to a model that was shipped as single-provider.

   1. Identify the feature's request and response schemas and the operations that expose them.

   2. Inspect the backing implementation and configuration to determine which providers the feature can actually serve, not only what the spec admits.

   3. Confirm the spec admits every supported provider — an open provider field or enum covering all partners — rather than encoding one provider.

   4. Report any feature whose schema or implementation is limited to a single provider without a documented reason.

2. API producers may support only one cloud provider at implementation and note that behavior in documentation.

3. API producers should consider the API design in the context of all currently supported cloud partners, to avoid later rework.

   components:
     schemas:
       StorageTarget:
         type: object
         properties:
           provider:
             type: string
           bucket:
             type: string
           region:
             type: string

   Why:

   The fields are common to every partner, so the same shape holds as providers are added and no per-provider variant of the schema is needed.

   components:
     schemas:
       StorageTarget:
         type: object
         properties:
           providerAResourceName:
             type: string
           providerAAccessKeyId:
             type: string

   Why:

   The schema is shaped around one provider's identifiers. A second partner cannot reuse these fields, forcing a new model and a version bump that designing for all partners up front would have avoided.

   1. Collect the schemas, parameters, and operations that carry provider-specific data.

   2. For each, check whether the shape is generic across partners or modeled around one provider's concepts and identifiers.

   3. Compare the design against the full set of currently supported partners and determine whether each could be expressed without a new model.

   4. Report any field, parameter, or schema that would require restructuring or a new version to admit another supported partner.

4. API producers should prefer vendor-neutral terms.

   components:
     schemas:
       Backup:
         type: object
         properties:
           blobStorageUri:
             type: string
           blobStorageRegion:
             type: string

   Why:

   Blob storage is a neutral term that reads the same regardless of which partner fulfills the request, so the field names stay accurate as partners are added.

   components:
     schemas:
       Backup:
         type: object
         properties:
           s3Uri:
             type: string
           s3Region:
             type: string

   Why:

   The field names borrow one vendor's product name for a concept every partner provides. The names become misleading once a different partner backs the same feature.

   1. Enumerate field names, parameter names, enum values, and descriptions across the spec.

   2. Flag any token that names a specific vendor or a vendor's branded product (for example a vendor object-storage brand) where a generic concept is meant.

   3. For each flagged token, identify the neutral equivalent that describes the concept rather than the vendor (object or blob storage instead of a branded bucket service).

   4. Report any vendor-specific term used for a concept that is shared across partners.

5. Lint rule ↗

   When using a provider field or parameter, API producers should not define a default value.

   components:
     schemas:
       Backup:
         type: object
         required: [provider]
         properties:
           provider:
             type: string
             enum: [PROVIDER_A, PROVIDER_B, PROVIDER_C]
           region:
             type: string

   Why:

   The provider field has no default, so the caller states the provider explicitly and adding a new partner does not silently change which provider an unset value resolves to.

   components:
     schemas:
       Backup:
         type: object
         properties:
           provider:
             type: string
             enum: [PROVIDER_A, PROVIDER_B, PROVIDER_C]
             default: PROVIDER_A
           region:
             type: string

   Why:

   The default pins the provider to one partner when the field is omitted. As partners are added the baked-in default skews usage toward the original provider and obscures the choice from callers.