Tenancy models¶

Tenancy models refers to "where" and "how" your tenants will be placed.

We support various hosting models to decide "where" tenants will be placed and meet your custom needs:

Your Account: Deployed in your (aka service provider) account
Bring Your Own Account (BYOA): Deployed in your customers' account
Omnistrate Account: Deployed in Omnistrate's account

We support various deployment models 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.

Info

Together, hosting model and deployment model govern the tenancy model for a given SaaS. You have the option to mix and match depending on your custom needs.

Note

Note that a modern day SaaS may offer multiple tenancy models to your customers depending on the requirements.

Now, we will dive deep into each of those tenancy models in detail. First, we will cover the hosting models and then the deployment models:

Hosting models¶

Deployed in your (aka service provider) account¶

Most common hosting model is to deploy in your own account and provide a fully-managed experience to your customers.

Many SaaS services like Slack, Stripe, GitHub are offered in this model.

Here is a reference architecture:

Bring Your Own Account (BYOA)¶

Your customers requires that data stays in their account due to security and migration cost. To support them, you have to host your application in their account as a fully-managed solution.

The BYOA tenancy model exactly addresses this use-case by seamlessly establishing the trust relationship between your account and your customers' accounts enabling the deployment and management of resources.

We follow the industry standard secure techniques to reverse the connection to prevent any inbound connections to your customers' account, encrypted channel through TLS and OAuth to secure the connectivity between your customers account and your account.

Many SaaS services like Databricks, RedPanda BYOC are offered in this model.

Note

There are several terms for BYOA mode in the industry and they are all somewhat related.

Bring Your Own Cloud (BYOC)
Bring Your Own VPC

Here is a reference architecture:

Deployed in Omnistrate account¶

If you are a young startup or not that familiar with the cloud or don’t want to deal with the hassle of even creating the cloud account, you can also use Omnistrate hosted mode to deploy your data plane with us.

Note

Please note that you will incur additional infrastructure charges if you are hosting your data plane in Omnistrate's account.

Here is a reference architecture:

Deployment models¶

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 services like RDS, Confluent, MongoDB are offered in this model.

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

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:

To achieve this, you can combine multiple Docker 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 Docker 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 Docker 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:

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 service components 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

The requested memory can also be specified as an API param. This can be done by setting the resourceRequestMemoryAPIParam to the corresponding api param key in x-omnistrate-compute tag.

services:
  postgres:
    x-omnistrate-compute:
      resourceRequestMemoryAPIParam: resourceRequestMemory
    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

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 services like Hubspot, Pulley, Zendesk are offered in this model.

API Reference¶

For API reference, please see this and this