Skip to main content
A service adapter exposes an origin service’s API and uses a backend service to carry out supported operations. Your application connects to the adapter’s endpoint. The adapter translates the request, uses the configured backend identity and returns an origin-shaped response.
An application sends an origin-cloud API request through Tensor9 Cloud Adapter to a native target service and receives an origin-shaped response.An application sends an origin-cloud API request through Tensor9 Cloud Adapter to a native target service and receives an origin-shaped response.

​
Example: S3 to Google Cloud Storage

Suppose an application uses PutObject to write report.pdf to an S3 bucket named media. Cloud Adapter handles that request as follows:
  1. The application’s S3 client sends the bucket name, object key, bytes and metadata to the adapter endpoint.
  2. The S3 service adapter translates the S3 request to a Google Cloud Storage request.
  3. The adapter calls Cloud Storage with the target identity configured for the deployment.
  4. Cloud Storage writes the object to gs://media/report.pdf.
  5. The adapter returns an S3 success response and ETag to the client.
An application sends an S3 PutObject request through Tensor9 Cloud Adapter, which translates it to a Google Cloud Storage request, writes the object, and returns an S3 response.An application sends an S3 PutObject request through Tensor9 Cloud Adapter, which translates it to a Google Cloud Storage request, writes the object, and returns an S3 response.
Object bodies remain in Cloud Storage. Cloud Adapter keeps bucket configuration separately so S3 bucket operations can retain their requested state and apply supported settings to the target bucket. GetObject, HeadObject, ListObjectsV2, multipart upload and other operations each have their own published behavior. See the S3 to Google Cloud Storage service profile →

​
Example: DynamoDB to Azure Cosmos DB

A database request requires more adaptation than an object write. Consider this conditional update to an item in the orders table:
  1. The DynamoDB SDK sends the operation, typed attributes, update expression and condition to the adapter endpoint.
  2. The DynamoDB service adapter parses the request and identifies the logical table and partition route.
  3. It preserves the DynamoDB item types and maps the requested behavior to Cosmos DB.
  4. Because this request uses a conditional SET, the adapter runs a partition-scoped stored procedure that reads the item, evaluates the condition, applies the update and checks the resulting item size atomically.
  5. Cosmos DB commits the document update. A concurrent write conflict remains retryable rather than appearing as a failed DynamoDB condition.
  6. The adapter returns DynamoDB attributes, status or a DynamoDB-shaped conditional error.
A conditional DynamoDB UpdateItem request passes through Tensor9 Cloud Adapter, which parses the DynamoDB request, maps the logical table and key, executes an atomic Azure Cosmos DB write, and returns a DynamoDB response.A conditional DynamoDB UpdateItem request passes through Tensor9 Cloud Adapter, which parses the DynamoDB request, maps the logical table and key, executes an atomic Azure Cosmos DB write, and returns a DynamoDB response.
Other request shapes take different paths. Eligible conditional removals can use native PATCH. Requests involving a local secondary index, a complex expression or an old image on condition failure can use an ETag-guarded read-modify-write. The same service profile defines how reads, queries, secondary indexes, streams, TTL and table operations behave. It also identifies important boundaries, including numeric precision, pagination and DynamoDB multi-item transactions. See the DynamoDB to Azure Cosmos DB service profile → The origin client and the backend use different credentials and authorization systems. Configuring a target-cloud credential does not establish who may call the adapter. Review both sides before exposing an endpoint.

​
Compatibility is specific

An adapter can support one operation without supporting every feature or option of that operation. Check the service reference for required configuration, supported operations and known differences. Adaptation also has a direction. An S3-to-Cloud Storage mapping does not imply that a Cloud Storage client can use S3 through the same adapter. Nor does one successful request establish all the behavior your application depends on.

​
Management APIs and data planes are different

Cloud Adapter handles supported calls to an origin cloud API. It does not automatically proxy every protocol that a target service exposes. An S3 management request and an application’s native database connection are different paths and may have different identities, endpoints and consistency behavior. This is why the Guides begin with API clients and infrastructure tools rather than promising that every application protocol is proxied. Native application traffic does not always pass through a service adapter. For example, adapting an infrastructure-management API is different from proxying every database query or network packet. The request path depends on the service and mapping.

​
Service adapters and cloud adapters

A service adapter covers a specific origin service and backend. A cloud adapter groups service adapters for a particular origin-to-target cloud direction. You can start with a single service and add others as your workload requires them. The deployment model supports a single process, multiple coordinated processes and a provisioned installation. The deployment choice does not change the meaning of a service mapping.

​
See what the adapter is doing

Tuning tags let supported origin requests supply target-native choices. Diagnostic response headers help interpret a response. tensor9 explain describes adaptation behavior without requiring you to infer it from implementation details. Begin with key concepts, or evaluate an adapter against your application’s operations.