Skip to main content

​
Selection is not compatibility

A backend choice identifies where a service’s operations will be implemented. It does not promise complete support for the origin API. Read the operation coverage and differences for the selected mapping, including the behavior on which your application depends. The service reference under each cloud in the sidebar lists the mappings available for Cloud Adapter.

​
Read a mapping in the right order

When evaluating a service, read the mapping from left to right:
  1. Origin API: the service and operation your client sends.
  2. Backend: the target service that performs the work or stores data.
  3. Identity: the credentials that authenticate the origin caller and the separate identity used for backend access.
  4. State: resources, data, keys and policies that must survive restarts or upgrades.
  5. Evidence: response headers, target state and the documented error behavior.
The order matters. A backend name is not an operation guarantee, and an accepted request is not proof that a write reached the target.

​
Configuration is not a migration

A configuration file describes desired settings. Moving persistent data from one backend to another is a separate operation. Editing a backend name cannot, by itself, copy data or preserve resource identities. The configuration lifecycle therefore distinguishes a valid configuration from a supported transition to that configuration. The request directive namespaces have different purposes:
  • t9:tuning:<path> supplies a supported backend field.
  • t9:backend selects a backend where that mechanism is supported.
  • t9:ack:* records explicit acknowledgement of a named semantic difference.
An acknowledgement is not a performance knob. Do not add one merely to dismiss an error. See tuning.