Tenancy Types¶

What Tenancy Types are Supported by Omnistrate¶

Omnistrate supports three distinct tenancy types to meet different isolation, cost, and operational requirements:

• Dedicated Tenancy (OMNISTRATE_DEDICATED_TENANCY): When using this tenancy type on you docker compose specification each tenant deployment instance gets dedicated infrastructure
• Multi Tenancy (OMNISTRATE_MULTI_TENANCY): When using this type on you docker compose specification multiple deployment instances, from different tenants, share infrastructure resources with logical isolation
• Custom Tenancy (CUSTOM_TENANCY): For Helm, Kustomize, Terraform and OpenTofu deployments where tenancy is defined within the components themselves and not controlled by Omnistrate

Each tenancy type serves different use cases and provides varying levels of isolation, cost efficiency, and operational complexity.

Dedicated Tenancy¶

In Dedicated tenancy model, each tenant deployment receives their own dedicated infrastructure stack (VMs). Omnistrate manages the provisioning, scaling, and lifecycle of these dedicated resources while ensuring complete isolation between tenants.

How Omnistrate Dedicated Tenancy Works¶

Complete Isolation: Each tenant gets their own virtual machines, storage, and network resources. No sharing occurs between tenants at the infrastructure level.

Customization: Tenants can customize their infrastructure configuration, including instance types, storage options, and network settings.

Security and Compliance: Provides the highest level of security and is suitable for enterprise customers with strict compliance requirements.

Omnistrate Management: While infrastructure is dedicated per tenant, Omnistrate still handles provisioning, monitoring, scaling, and maintenance operations.

Use Cases: Dedicated tenancy is ideal for enterprise customers, regulated industries, high-security requirements, and scenarios where performance isolation is critical. Many SaaS products like Amazon RDS, Confluent Cloud, and MongoDB Atlas dedicated clusters use this model.

Configuration Example:

x-omnistrate-service-plan:
  tenancyType: 'OMNISTRATE_DEDICATED_TENANCY'

Multi-Tenancy¶

In Omnistrate's multi-tenancy model, multiple customer instances share the same underlying infrastructure while maintaining logical isolation. Omnistrate handles the orchestration, resource allocation, and tenant isolation automatically.

How Omnistrate Multi-Tenancy Works¶

Resource Sharing and Bin-Packing: Omnistrate automatically places multiple tenant instances on the same virtual machines based on resource requirements (CPU, memory). This bin-packing approach maximizes resource utilization and reduces costs.

Automatic Scaling: When resource demands exceed the capacity of existing VMs, Omnistrate automatically provisions new virtual machines and redistributes workloads as needed.

Logical Isolation: Each tenant's workload runs in isolated containers with defined resource limits and requests, ensuring one tenant cannot impact another's performance.

Configuration Example:

x-omnistrate-service-plan:
  tenancyType: 'OMNISTRATE_MULTI_TENANCY'
services:
  postgres:
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 50M
        reservations:
          cpus: '0.25'
          memory: 20M

You can also configure resource requests and limits as API parameters:

services:
  postgres:
    x-omnistrate-compute:
      resourceRequestMemoryAPIParam: resourceRequestMemory
      resourceRequestCPUAPIParam: resourceRequestCPU
      resourceLimitMemoryAPIParam: resourceLimitMemory
      resourceLimitCPUAPIParam: resourceLimitCPU
    x-omnistrate-api-params:
      - key: resourceRequestMemory
        name: Memory Request
        description: Memory Request for the Postgres instance
        type: String
        modifiable: true
        required: true
        export: true
        defaultValue: 100M
      - key: resourceRequestCPU
        name: CPU Request
        description: CPU Request for the Postgres instance
        type: String
        modifiable: true
        required: true
        export: true
        defaultValue: 100m
      - key: resourceLimitMemory
        name: Memory Limit
        description: Memory Limit for the Postgres instance
        type: String
        modifiable: true
        required: true
        export: true
        defaultValue: 2048M
      - key: resourceLimitCPU
        name: CPU Limit
        description: CPU Limit for the Postgres instance
        type: String
        modifiable: true
        required: true
        export: true
        defaultValue: "4"

Architecture Selection: You can specify processor architecture using the platform attribute:

services:
  postgres:
    platform: "linux/arm64"  # Default is X86_64

Use Cases: Multi-tenancy is ideal for cost-effective SaaS offerings, free tiers, and scenarios where moderate isolation is sufficient. Many SaaS products like Redis Cloud or MongoDB Atlas free tiers use this model.

In-App Multi-Tenancy¶

If your application is already tenant-aware, you can group tenants into cells for enhanced security and fault tolerance. Each cell is a single application instance supporting a small group of tenants.

Many SaaS products like HubSpot, Pulley, and Zendesk use this cell-based multi-tenancy model.

Custom Tenancy¶

Custom tenancy is used for Helm, Kustomize, Terraform and OpenTofu deployments where the tenancy model is defined within the deployment components themselves, rather than being controlled by Omnistrate.

How Custom Tenancy Works¶

Custom-Defined Tenancy: The tenancy model, isolation boundaries, and resource allocation are defined within your Helm charts, Terraform configurations, or Kustomize overlays.

Omnistrate Orchestration: Omnistrate handles the deployment, lifecycle management, and scaling of your components, but respects the tenancy rules you've defined.

Flexibility: You have complete control over how tenants are isolated, how resources are shared or dedicated, and how scaling occurs.

Component-Level Control: Different components within your service can have different tenancy models based on your specific requirements.

Use Cases: Custom tenancy is ideal when you have specific tenancy requirements that don't fit the standard multi-tenant or dedicated models, need fine-grained control over resource allocation, or are migrating existing infrastructure-as-code deployments to Omnistrate.

Choosing the Right Tenancy Type¶

The choice of tenancy type depends on your specific requirements for isolation, cost, compliance, and operational complexity. You can also mix different tenancy types within the same service for different tiers or customer segments.