Skip to main content
Before running a tensor9 command, install the CLI, set T9_API_KEY, and verify your customer account. Online commands are authenticated and their adapter detail is limited to mappings your account is entitled to use.
A service adapter includes both an origin service and a target service. The target service is also called the backend. For example, Amazon S3 → Google Cloud Storage is one service adapter; Amazon S3 → Azure Blob Storage is another. GCS alone names a backend, not a complete service adapter. The origin tells you which API and behavior the adapter must provide. The target tells you which service it uses to provide them.

​
One origin can have several service adapters

An AWS application can continue calling DynamoDB while you compare different adapters for that origin: These adapters share the origin API but have different implementations, capacity models and operating requirements. The mapping is directional: support for S3 → GCS does not establish support for GCS → S3. Check the profile for the exact origin and target pair. In the Choosing an Adapter articles, the origin is usually already fixed by the application. Comparing backends in that context means comparing service adapters for that same origin. “Choose Cloud SQL for DynamoDB” is shorthand for choosing the DynamoDB → Cloud SQL for PostgreSQL service adapter, not for replacing the application’s DynamoDB calls with SQL.

​
Identify both sides in a trial

The single-service command names both services explicitly:
This selects the S3 → GCS service adapter for the process. Prepare the target identity and configuration using the S3-to-GCS example before running it. It uses real target-cloud resources. An installation does not need a redundant configuration entry for every pair. Where the origin and target environment resolve a single compatible backend, that selection can be inferred. Explicit choices and pre-provisioned dependencies still need the settings described in Configuration Files. Inferred selection does not change the meaning of a service adapter: the effective mapping still has both an origin and a target.

​
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 public service profiles distinguish three kinds of request directives: target tuning, backend selection, and explicit acknowledgement of a named semantic difference. Check the exact directive names, accepted values, and scope for the directed adapter before using the licensed binary. An acknowledgement is not a performance knob. Do not add one merely to dismiss an error. See tuning.