Skip to content

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:

Hosted SaaS Arch

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:

BYOA SaaS Arch

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:

Omnistrated SaaS Arch

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:

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 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.

Typically, multiple tenants are grouped together to form cells and each cell need to be isolated from one another. The shared tenancy model addresses this use-case by handling security challenges, managing tenants across cells and providing the framework to build tenant-aware application for the efficient deployment and management of resources across tenants.

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

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

We also support specifying the memory request as an API param. You can do this 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

API Reference

For API reference, please see this and this