How Service Adapters Work

A service adapter lets your application use an equivalent service in your customer’s environment. You define your application and its infrastructure once. Tensor9 adapts that infrastructure to each customer’s cloud and, where supported, handles the API differences so your application can keep its existing client libraries. The Service Catalog describes the service mappings available for each target cloud. Your application can, for example, manage a database through the RDS API while sending SQL queries directly to the target PostgreSQL server. A VPC adapter handles network-management calls; the customer’s cloud handles the application’s network traffic. Choose the cloud your application is written for, then look for your customer’s cloud in the target columns. Adaptation has a direction: support for SQS on Azure Service Bus does not imply support for moving a Service Bus application to AWS. Each service page explains its target services, supported operations and differences that affect applications. The Service Catalog marks mappings that include the Max adaptation. At Max, the Tensor9 service adapter answers supported cloud API calls inside your customer’s appliance.

​

Adaptation Tiers

Where both tiers are available, Infrastructure only is an option for applications that do not need the runtime adapter. For example, a PostgreSQL application can connect directly to Cloud SQL after Tensor9 updates its endpoint. If it also calls the RDS API to create or modify databases, it needs Max support for those operations. S3 illustrates a different case. Even when the target supports the S3 protocol, an AWS client signs requests for AWS. The adapter directs those requests to the target and signs them with the customer’s credentials. Protocol compatibility alone does not remove this runtime dependency. When the origin and target clouds are the same, the stack runs natively.

​

A stack’s tier depends on its services and API calls

Your stack requires the highest tier needed by any of its services. Consider an application with these requirements on Google Cloud: This stack requires Max for SNS. Adding runtime EKS or RDS management calls also requires their Max adapters; the first two rows describe workloads that only use the provisioned cluster or database. You can reduce the required tier by removing or replacing a service that needs Max. An optional alerting topic may be a reasonable tradeoff; a database central to the application may not be. Changes to the origin stack affect every customer deployment, so assess that choice for the whole application. Declaring IAM roles and policies does not by itself require Max. At Infrastructure only, Tensor9 translates them into the target cloud’s permissions at build time. Those permissions can be broader than the original AWS policies. See AWS IAM for the differences between native permission translation and runtime authorization. Send us your origin stack and target cloud, and we will report its tier and the services that determine it. Selecting a tier yourself and previewing the resulting deployment is (private beta).

​

How the Tensor9 adapter works

The adapter runs inside your customer’s appliance, in their cloud account or private environment. It authenticates supported origin-cloud requests, translates them into target operations and returns the response format the client expects. For an S3 request on Google Cloud, the objects live in the customer’s Cloud Storage bucket. For an adapter built on a database, the database stores the service’s records in a schema managed by the adapter. The service page explains which resources hold the data and who operates them. Management operations can take time. An adapter may record a requested change, create or update native resources, and report progress through subsequent API reads. The service’s operation table describes which calls are supported and where the target behaves differently. Supported API-compatible mappings keep the application’s existing client libraries. Some mappings require a different client or offer only part of the origin service’s behavior; their pages state those differences. The adaptation tier describes the runtime components involved, not a guarantee that every operation is equivalent. At Max, cloud API calls depend on the adapter as well as the backing service. That does not put every database query or network packet through the adapter. Each service’s architecture explains the request paths it handles.

​

Find an adaptation

The Service Catalog also lists services we do not adapt. If a mapping you need is absent, ask us about the specific service and target cloud.

​

Terms used here

• Origin stack: the infrastructure configuration your application starts with, such as Terraform, CloudFormation, Helm or Docker Compose.
• Appliance: the system Tensor9 deploys into the customer’s cloud or private environment.
• Service adapter: the adaptation of an origin service onto a target, at Infrastructure only or Max.
• The Tensor9 adapter: the runtime component that answers supported origin-cloud API calls at Max.
• Customer: the organization hosting your software in its own infrastructure.
• You: the software vendor defining the application, its origin stack and the target environments you offer to customers.

​

Related topics

• Deployments: how compilation uses service adapters
• Form factors: which services an environment can provide
• Appliances: what gets deployed into the customer’s environment
• How Tensor9 works: how Tensor9 prepares and deploys an application