How Support Works

Tensor9 BYOC support helps software vendors investigate the service adapters running in their customers’ environments. The vendor understands the application; the customer controls the environment and access; Tensor9 helps explain and investigate the adaptation between origin and target services. You do not need to establish fault before asking for help. This section describes service-adapter support and what its SLAs cover. It is not an availability promise for your entire application, the BYOC control plane or every resource in a customer appliance. Your signed agreement defines the coverage that applies.

​

Know the exact service adapter

A service adapter includes an origin and target service. DynamoDB to Firestore and DynamoDB to Spanner are different service adapters, even if the application uses the same AWS SDK for both deployments. Use the BYOC service catalog to find the selected mapping and supported operations. Distinguish calls that pass through an adapter from native protocols and resources that are mapped without a runtime adapter. A fabric SLA does not cover a path that never enters that fabric.

​

Who does what

The vendor is Tensor9’s customer for the BYOC product; the vendor’s customer hosts the appliance. Agree on who owns each operational task before a production rollout. The exact division between vendor and hosting customer may differ by contract. Record it explicitly; do not assume that owning a cloud account also makes its owner responsible for selecting the application’s adapter or implementing the application’s retry policy.

​

The standard adapter support boundary

The standard model covers the Tensor9 fabric between an origin request entering the covered adapter path and the origin-shaped response leaving it. That path can include substantial work before a target call, between several calls and after the target responds. Native target processing is a separate dependency. The adapter’s latency and availability commitments do not replace Google Cloud, Microsoft Azure or another provider’s terms. They also do not become an end-to-end application SLA. See Service Levels. Do not classify an entire failed request as a provider issue merely because a native call occurred. An adapter can cause a bad target request, apply the wrong mapping or mishandle a valid response. Those are adapter issues to investigate. A native provider delay does not excuse unrelated Tensor9 processing delays on the same request. Support remains available when the boundary is unclear. Failure attribution determines how the applicable commitment is evaluated, not whether the vendor may report a problem.

​

Example: one application, two customer environments

An orders-api release uses DynamoDB. One customer runs it on Google Cloud with Spanner; another runs it on Azure with provisioned Cosmos DB. The vendor needs to validate conditional writes, query behavior and recovery for both directed mappings. The Spanner customer monitors the native database’s capacity and query behavior. The Cosmos DB customer monitors RU consumption, throttling and partition distribution. The same application-level symptom can have different causes in the two environments. Tensor9 helps inspect the selected profile, interpret tuning and investigate what an adapter did. Evidence from one customer deployment does not establish the cause in the other. Keep the app release, appliance, adapter version, target mapping and time window with each report. Read the DynamoDB to Spanner and DynamoDB to Cosmos DB terms alongside the DynamoDB service reference.

​

Scaling the fabric and the target

An SLA-backed production fabric and a target database have distinct scaling limits. Adding target capacity does not remove every adapter bottleneck; adding adapter replicas does not remove target throttling or serialized work for a hot key. Define the supported workload by the origin operations your application completes, their sizes and feature modes, not only pod counts or target RPC rates. A batch API can generate many native calls, and a conditional update can require more adapter work than a simple read. The applicable agreement must identify the supported deployment, workload envelope and limits. A successful test-appliance request alone does not qualify production scale. See Scaling and Limits and the consolidated service-adapter SLA tables.

​

Work within the customer’s access controls

Use Explain and diagnostic evidence before requesting invasive access. BYOC uses the same service-adapter Explain protocol as Cloud Adapter; the customer does not need to install a separate product for an investigation. Customer approval, authorized report ownership and evidence-handling rules still apply. Opening a support case does not grant unrestricted access, authorize a write or allow customer data to leave the environment. Use the existing operations security and break-glass procedures when live access is needed.

​

Coverage and contact

Use your agreed support channel, or contact Tensor9. Your agreement defines response and escalation terms; no universal support response time is established here. If your application needs an arrangement extending beyond the standard adapter boundary, discuss it with Tensor9. Any additional scope must be agreed explicitly rather than inferred from the underlying cloud provider’s SLA. Getting Help provides a step-by-step incident handoff for vendors and hosting customers.