Architecture

Cloud Adapter is a runtime translation layer between software that speaks an origin cloud API and the native services selected for its target environment. The request path stays inside your environment. The local Tensor9 CLI configures and operates that runtime, but does not proxy application traffic.

​

The request path

Each request crosses three adapter stages:

1. API endpoint. Your existing SDK, CLI or infrastructure tool sends an origin-shaped request to the configured Cloud Adapter endpoint.
2. Service adapter. The selected origin-to-backend mapping interprets the request and translates its supported behavior.
3. Target client. Cloud Adapter calls the native target service using the backend identity configured for that mapping.

The response follows the reverse path. Cloud Adapter translates the target result into the origin API’s response shape. When emitted, diagnostic response headers can supply correlation identifiers or narrowly defined request-effect evidence. A cloud adapter is therefore composed of service adapters. Each service adapter owns one origin-service-to-backend mapping; the cloud adapter gives those mappings one operating boundary for a particular origin-to-target direction.

​

The operations path

The local Tensor9 CLI reads the installation’s configuration, validates changes and coordinates setup and updates. Configuration has two scopes:

• Cloud adapter configuration defines settings shared by the installation, such as its origin and target clouds, networking and deployment shape.
• Service adapter configuration selects a backend and supplies the settings needed for one service mapping.

Both scopes feed the runtime, but neither sits in the application request path. This separation lets the CLI stop after an operation while the adapters continue to serve traffic. See Configuration and Operations.

​

Identity and trust boundaries

Cloud Adapter crosses distinct security boundaries. Treat them separately: An origin-shaped request does not inherit permission to the target service. Likewise, a target-cloud credential does not decide who may call the adapter. Apply least privilege independently at each boundary and keep provisioning credentials separate from runtime credentials.

​

Where state lives

Application data belongs to the selected target service. For example, an S3-to-Cloud Storage adapter stores objects in Cloud Storage; it does not keep a second object copy inside Cloud Adapter. Cluster deployments also use a PostgreSQL coordination store. That store coordinates adapter processes; it is separate from the application data held by target services. Inventory, back up and recover those stores according to their different roles. Configuration is another durable input. Keep it under review and change control, because changing a backend can change data ownership and migration requirements even when the file remains syntactically valid.

​

How deployment changes the topology

The request translation remains the same across deployment choices. What changes is how the runtime is arranged: Adding processes improves process availability or throughput; it does not expand a service mapping’s operation coverage. Review the selected service adapter’s reference page before choosing a deployment shape.

​

Observe a request

Use tensor9 explain to inspect how a request maps to its target behavior without sending it through the full deployment. During live diagnosis, combine that explanation with the adapter’s response headers, runtime logs and the resulting target-service state.