Skip to content

Tenancy Types

We support various Tenancy Types to decide "how" tenants will be placed and meet your custom needs:

  • Dedicated tenancy: Dedicated infrastructure stack for every resource.
  • Resource-shared tenancy: Shared infrastructure across tenant resources.
  • Multi-tenancy: Multi-tenancy across your customers.

Now, we will dive deep into each of those Tenancy Type in detail:

Dedicated Tenancy

In dedicated tenancy, we create a dedicated infrastructure stack for each resource deployed in your account. This allows your tenants to customize and have infrastructure level isolation for greater security and resiliency.

Many SaaS Products like RDS, Confluent, MongoDB are offered in this model.

Here is a reference architecture, here Res refers to resource:

Dedicated Tenancy

To configure dedicated tenancy in docker compose, you can specify the tenancy type as OMNISTRATE_DEDICATED_TENANCY in the x-omnistrate-service-plan tag. Below is an example.

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

Resource-shared Tenancy

There are times where you want dedicated tenancy with shared infrastructure across different selected resources to save on cost. One example use-case will be move all the non-critical resources on the shared infrastructure and keep critical infrastructure as dedicated.

Here is a reference architecture, here Res refers to resource: Resource Shared Tenancy

To achieve this, you can combine multiple Container Images into one and using supervisord to manage the processes is a common approach. Here's a step-by-step guide to achieve this:

1. Create a Dockerfile
You'll need to create a new Dockerfile that will incorporate all the dependencies and scripts from your existing Container Images.

FROM ubuntu:latest  # or any base image you prefer

# Install supervisor
RUN apt-get update && apt-get install -y supervisor

# Copy the scripts or binaries from your existing Container Images
COPY script1.sh /app/
COPY script2.sh /app/
# ... add more scripts as needed ...

# Copy the supervisord configuration
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

CMD ["/usr/bin/supervisord"]

2. Create a supervisord.conf
You'll need a configuration file for supervisord that specifies how each script should be run.

[supervisord]
nodaemon=true
loglevel=info

[program:script1]
command=/app/script1.sh
autostart=true
autorestart=unexpected
exitcodes=0,1

[program:script2]
command=/app/script2.sh
autostart=true
autorestart=unexpected
exitcodes=0,1

# ... add more programs as needed ...
In the above configuration:

  • autorestart=unexpected ensures that if any of the processes exit unexpectedly (i.e., with an exit code not in exitcodes), supervisord will not try to restart it.
  • exitcodes=0,1 specifies the expected exit codes. If a script exits with a code other than 0 or 1, supervisord will consider it unexpected and will terminate.

Multi-Tenancy

In this tenancy model, multiple tenants can share the underlying infrastructure to provide a cost-effective solution to your customers.

Here is a reference architecture, here Res refers to resource: Multi Tenancy

To configure multi tenancy in docker compose, first specify the tenancy type as OMNISTRATE_MULTI_TENANCY in the x-omnistrate-service-plan tag. Then configure the requests and limits for the Resources in the deploy tag. Below is an 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

Please see the Kubernetes Resource Management for Pods and Containers documentation for more information regarding the configuration of requests and limits.

Resource requests and resource limits can be specified as API parameter values. x-omnistrate-compute accepts values for requests (resourceRequestMemoryAPIParam and resourceRequestCPUAPIParam) and values for limits (resourceLimitMemoryAPIParam and resourceLimitCPUAPIParam). You will also have to define corresponding API parameters. Here is an example with all values set:

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"

Omnistrate will select the best instance type to host the service based on the CPU and Memory requirements, so that multiple instances and components of the service will coexist in the same virtual machine. When the number of service instances/tenants exceeds the supported by the provisioned infrastructure a new virtual machine will be provisioned automatically.

If you want to use a specific processor architecture you can define this on the docker compose spec platform attribute. By default Omnistrate will select instance types using X86_64 processor architecture.

services:
  postgres:
    platform: "linux/arm64"

Many SaaS free tier like Redis or MongoDB are offered in this model.

In-App Multi-Tenancy

If you have an application thats already tenant aware, that's awesome. You can combine group of tenants to form a cell for security and fault-tolerance. You can use use Omnistrate to create and manage your cells.

Basically, cell is a single application instance that supports small group of tenants.

Many SaaS Products like Hubspot, Pulley, Zendesk are offered in this model.

API Reference

For API reference, please see this and this