Overview
Cloud providers offer similar services under different names and APIs:- AWS RDS PostgreSQL vs. Google Cloud SQL vs. Azure Database for PostgreSQL
- AWS S3 vs. Google Cloud Storage vs. Azure Blob Storage
- AWS ElastiCache vs. Google Memorystore vs. Azure Cache for Redis
How service equivalents work
When you create a release for a specific appliance, Tensor9 compiles your origin stack through several steps:1
Analyze origin stack
Tensor9 identifies all cloud-specific resources in your origin stack.
2
Map to functional equivalents
Each resource is mapped to its functional equivalent based on the target form factor.
3
Map resource definitions
The resource definition is mapped to use the target cloud’s provider and API.
4
Preserve configuration semantics
Configuration semantics (storage size, instance type, performance characteristics) are preserved in the mapping.
5
Generate deployment stack
A deployment stack ready to deploy in the target environment is generated.
Service equivalents registry
Tensor9 groups services into equivalent sets based on their function. When compiling for a specific form factor, Tensor9 automatically selects the appropriate equivalent from the target environment.| Service Category | AWS | Google Cloud | Azure | DigitalOcean | On-Prem |
|---|---|---|---|---|---|
| Containers | EKS, ECS | GKE | AKS | DOK | Kubernetes |
| Functions | Lambda | Cloud Functions | Azure Functions | Functions | Knative (unmanaged) |
| Networking | VPC | VPC | VNet | - | - |
| Load balancing | Load Balancer | Load Balancer | Load Balancer | Load Balancer | Cloudflare (optional) |
| DNS | Route 53 | Cloud DNS | Azure DNS | DigitalOcean DNS | Cloudflare (optional) |
| Identity and access management | IAM | IAM | IAM | - | - |
| Object storage | S3 | Cloud Storage (GCS) | Azure Blob Storage | Spaces | Backblaze B2, MinIO (unmanaged) |
| Databases (PostgreSQL) | RDS Aurora PostgreSQL, RDS PostgreSQL | Cloud SQL PostgreSQL | Azure Database for PostgreSQL | Managed PostgreSQL | Neon, CloudNative PostgreSQL (unmanaged) |
| Databases (MySQL) | RDS Aurora MySQL, RDS MySQL | Cloud SQL MySQL | Azure Database for MySQL | Managed MySQL | PlanetScale, MySQL (unmanaged) |
| Databases (MongoDB) | DocumentDB | Atlas MongoDB | Cosmos DB (MongoDB API) | Managed MongoDB | MongoDB Atlas, MongoDB (unmanaged) |
| Caching | ElastiCache | Memorystore | Azure Cache for Redis | Managed Redis | Redis Enterprise Cloud, Redis (unmanaged) |
| Message streaming | MSK (Managed Streaming for Kafka) | Confluent Cloud, Kafka (unmanaged) | Event Hubs (Kafka compatible) | Confluent Cloud, Kafka (unmanaged) | Confluent Cloud, Kafka (unmanaged) |
| Search | OpenSearch Service | OpenSearch (unmanaged) | OpenSearch (unmanaged) | OpenSearch (unmanaged) | OpenSearch (unmanaged) |
| Workflow | MWAA (Managed Airflow) | Cloud Composer | Azure Data Factory | Astronomer, Airflow (unmanaged) | Astronomer, Airflow (unmanaged) |
| Analytics | Amazon Athena | BigQuery | Azure Synapse Analytics | Presto (unmanaged) | Presto (unmanaged) |
Third-party managed equivalents (Backblaze B2, Neon, PlanetScale, MongoDB Atlas, Redis Enterprise Cloud, Confluent Cloud, Astronomer) require your customers to bring their own credentials and accounts with these services.
Mapping examples
Here are concrete examples of how Tensor9 maps services during compilation.Example 1: AWS to Google Cloud
When compiling an AWS-based origin stack for a Google Cloud appliance: Origin stack (AWS):The deployment stack below is for illustration purposes only.
An actual deployment stack is a lot more complicated, and does not simply contain resources as is shown below.
- Replaced
aws_db_instancewithgoogle_sql_database_instance - Replaced
aws_s3_bucketwithgoogle_storage_bucket - Replaced
aws_elasticache_clusterwithgoogle_redis_instance - Preserved configuration (storage size, memory, instance tiers)
- Maintained the
instance_idvariable for resource uniqueness - Injected replacement service endpoints into application containers (no code changes required)
Example 2: AWS to private Kubernetes
When compiling an AWS-based origin stack for a private Kubernetes appliance: Origin stack (AWS):The deployment stack below is for illustration purposes only.
An actual deployment stack is a lot more complicated, and does not simply contain resources as is shown below.
- Replaced the EKS cluster with a Kubernetes namespace
- Replaced AWS RDS with CloudNative PostgreSQL (CNPG) operator
- Replaced S3 with MinIO for private object storage
- Adapted configurations to Kubernetes-native patterns
Example 3: AWS to Azure
When compiling an AWS-based origin stack for an Azure appliance: Origin stack (AWS):The deployment stack below is for illustration purposes only.
An actual deployment stack is a lot more complicated, and does not simply contain resources as is shown below.
- Replaced Lambda with Azure Functions
- Replaced RDS PostgreSQL with Azure Database for PostgreSQL
- Replaced S3 with Azure Blob Storage (storage account + container)
- Preserved environment variables and references between resources
- Injected replacement service endpoints into application containers (no code changes required)
Wire compatibility and endpoint injection
Service equivalents in Tensor9 are wire compatible, meaning your application code doesn’t need to change when deploying across different cloud providers. Tensor9 achieves this through endpoint injection:No code changes required
When services are functionally equivalent, they speak the same protocol:- PostgreSQL databases all use the PostgreSQL wire protocol, whether running on AWS RDS, Google Cloud SQL, or Azure Database for PostgreSQL
- Redis caches all use the Redis protocol, whether running on AWS ElastiCache, Google Memorystore, or Azure Cache for Redis
- Object storage services all support S3-compatible APIs, whether AWS S3, Google Cloud Storage, Azure Blob Storage, or MinIO
- Functions all support the same invocation patterns, whether AWS Lambda, Google Cloud Functions, or Azure Functions
pg for PostgreSQL, redis for Redis, boto3 for S3-compatible storage). These libraries work the same regardless of which cloud provider hosts the underlying service.
Emulation for certain services: For services like object storage and functions, Tensor9 provides an emulation layer to compensate for a lack of wire compatibility. For example, Azure Blob Storage doesn’t natively support the S3 API, so Tensor9 deploys an S3-compatible emulation layer that translates S3 API calls to the native cloud storage API. Similarly, function invocation patterns are normalized across Lambda, Cloud Functions, and Azure Functions. This emulation is transparent to your application code.
Endpoint injection
What changes between cloud providers is the service endpoint - the hostname and port your application uses to connect to the service. Tensor9 automatically injects the correct endpoints into your application containers: Origin stack definition:DATABASE_HOST and connects - it doesn’t need to know whether it’s running on AWS, Google Cloud, or Azure.
What your code sees
From your application’s perspective, connecting to a PostgreSQL database looks identical across all clouds:Configuration mapping
When mapping services, Tensor9 preserves the semantic meaning of your configuration:| Configuration Type | How Tensor9 Maps It |
|---|---|
| Storage and capacity | Disk sizes are mapped to equivalent tiers in the target cloud. Memory allocations are mapped to appropriate instance types. Performance characteristics (IOPS, throughput) are matched where possible. |
| Networking | VPC configurations are mapped to equivalent network isolation constructs. Load balancer types (internal vs. external) are preserved. Security group rules are mapped to cloud-specific firewall rules. |
| High availability and resilience | Multi-AZ deployments are mapped to equivalent availability zone configurations. Read replicas and standby instances are configured appropriately. Backup and retention policies are maintained. |
| Access control | IAM roles and service accounts are created with equivalent permissions. Encryption settings (at-rest, in-transit) are preserved. Authentication mechanisms are adapted to target cloud patterns. |
Managed vs. unmanaged services
The service equivalents registry includes both managed and unmanaged service options. The choice depends on the target form factor:Managed services
When available in the target environment, Tensor9 uses cloud provider-managed versions of services (databases, caches, message queues). Managed services include built-in backups, monitoring, and updates handled by the cloud provider.Third-party services
Third-party managed services (e.g., MongoDB Atlas, Confluent Cloud) are available across all deployment environments, including private. These services are hosted externally and accessed over the network.Unmanaged services
For environments where cloud provider-managed services aren’t available, Tensor9 can use unmanaged equivalents:- Kubernetes operators (e.g., CloudNative PostgreSQL)
- Self-hosted open-source software (e.g., MinIO, Redis)
- Containerized versions running on the appliance
Single origin stack for multiple environments
Service equivalents enable you to maintain a single origin stack that deploys to multiple target environments. Changes to your origin stack propagate to all supported form factors during compilation without requiring separate codebases per cloud provider.Form factor and service availability
Not all services are available in all form factors. The form factor defines which managed services are available in the target environment. For example:- AWS: Full access to AWS managed services (RDS, S3, ElastiCache, etc.)
- Google Cloud: Full access to Google Cloud managed services (Cloud SQL, GCS, Memorystore, etc.)
- Private Kubernetes: Kubernetes-native services, operators, and third-party managed services (e.g., MongoDB Atlas)
Unsupported AWS services
While Tensor9 supports many AWS services, some popular AWS services are not currently supported for cross-cloud deployment:| AWS Service | Service Category | Recommended Alternative |
|---|---|---|
| EC2 | Compute (VMs) | ECS Fargate, EKS, or Lambda |
| DynamoDB | NoSQL Database | DocumentDB (MongoDB-compatible) |
| EFS | File Storage | EBS volumes or S3 for object storage |
| SQS | Message Queue | MSK (Kafka) or application-level queuing |
| SNS | Pub/Sub Messaging | MSK (Kafka) or application-level pub/sub |
| Kinesis | Stream Processing | MSK (Kafka) |
| EventBridge | Event Bus | MSK (Kafka) or application-level events |
| Step Functions | Workflow Orchestration | MWAA (Managed Airflow) |
| API Gateway | API Management | ALB/NLB with application routing |
| Cognito | Authentication | Application-level authentication |
| AppSync | GraphQL API | Application-level GraphQL server |
| Redshift | Data Warehouse | Amazon Athena or BigQuery |
If you need a service that isn’t listed here or in the service equivalents registry, please contact [email protected] to discuss your requirements.
Limitations and considerations
Unsupported services
Unsupported services
Some popular AWS services are not currently supported for cross-cloud deployment. See Unsupported AWS services for the full list and recommended alternatives.
Provider-specific features
Provider-specific features
Some cloud-specific features may not have direct equivalents across all providers. For example:
- Azure-specific features like Cosmos DB multi-model APIs
- Google Cloud-specific services like BigQuery ML
- Use a more generic service type that’s available across clouds
- Include conditional logic in your origin stack
- Define form factor-specific overrides
Performance characteristics
Performance characteristics
While Tensor9 maps configuration semantically, exact performance characteristics may vary between clouds due to differences in:
- Hardware specifications
- Network architecture
- Storage backend implementations
Application code portability
Application code portability
Service equivalents are wire compatible, so your application code doesn’t need to change when deploying across different cloud providers. Tensor9 handles endpoint injection and provides emulation layers where necessary (e.g., S3-compatible APIs for non-AWS object storage). Your application code uses standard client libraries that work the same across all clouds.
S3 API compatibility
S3 API compatibility
When deploying to Azure appliances, Tensor9 provides S3-compatible API emulation for Azure Blob Storage. The emulation supports common S3 operations but has limitations compared to native AWS S3:Supported S3 operations:
GetObject- Download objectsPutObject- Upload objectsDeleteObject- Delete objectsDeleteBucket- Delete bucketsDeleteObjectVersion- Delete object versionsListObjects/ListObjectsV2- List objects in a bucketListBuckets- List all bucketsListObjectVersions- List object versionsGetPresignedUrl- Generate pre-signed URLs for temporary access
Google Cloud Storage and MinIO (used in private/on-prem deployments) provide native S3 compatibility and support a broader range of S3 operations beyond this list.
Resource naming
Resource naming
Some clouds have stricter naming requirements than others. Ensure your origin stack uses the
${var.instance_id} suffix for resource names to maintain uniqueness, and avoid special characters that may not be supported in all clouds.Best practices
Check the service equivalents registry
Check the service equivalents registry
The service equivalents registry defines which services can be mapped across form factors. If your origin stack uses a service not in the registry, that service cannot be mapped and you will need to use an alternative that is supported.
Test across form factors
Test across form factors
Create test appliances for each form factor you intend to support. This validates that service equivalents work correctly for your specific use case.
Evaluate cross-cloud behavior
Evaluate cross-cloud behavior
Evaluate how your application performs across different form factors using the observability feature.
Related topics
- Deployments: Learn how compilation uses service equivalents
- Form factors: Understand how form factors define available services
- Origin stacks: Create portable infrastructure code
- Appliances: Deploy to different cloud environments