Multi and Single Tenancy: Recap

Multi and single tenancy are two different deployment models for software as a service (SaaS) platforms. In a multi-tenant architecture, the SaaS platform serves multiple customers or tenants from a single instance of the software, with each customer’s data securely isolated from other customers' data. This shared infrastructure allows for economies of scale, reducing costs for both the SaaS provider and their customers. On the other hand, in a single-tenant architecture, each customer has their own dedicated instance of the software, with their own servers, databases, and resources. While this model provides greater flexibility and control over data and configurations, it also requires more resources and can be more expensive for both the SaaS provider and their customers. Ultimately, the choice between multi and single tenancy depends on factors such as security, scalability, flexibility, and cost, and should be made based on the specific needs of each customer and their use case.

Multi vs Single Tenancy Model in SaaS CIAM Platforms

In a multitenant SaaS platform, each customer’s data is isolated and segregated from other tenants, which makes it more secure and efficient than a single-tenant architecture. The platform uses a shared infrastructure, which significantly reduces the cost of maintaining and operating the application, as well as the time and resources spent on updates and upgrades. This model allows SaaS providers to deliver their services to a large number of customers while keeping their costs low and providing greater scalability.

One of the main benefits of multitenancy is that it allows customers to access a platform’s features and functionalities on demand, without the need for any additional hardware or software installations. It also provides greater flexibility, as customers can easily adjust their subscription levels based on their usage, without having to worry about any downtime or disruption to their services.

Another benefit of multitenancy is that it enables SaaS providers to offer more personalized services to their customers. With multitenancy, providers can easily customize their platform to meet the specific needs of each customer, without having to create separate instances of the application.

The difference between multitenant Customer Identity and Access Management (CIAM) platforms and single-tenant CIAM platforms is that the former serves multiple tenants, the latter serves only one. Multitenant CIAM platforms are designed to provide authentication and authorization services to multiple tenants, keeping their data segregated and secure. Single-tenant CIAM platforms are designed to serve a single tenant, and their resources are not shared with any other customer.

In conclusion, multitenancy is a powerful architecture approach that enables SaaS providers to deliver their services to many customers efficiently and securely, while providing personalized services and reducing their operating costs. While it requires careful planning and management, the multitenancy is an attractive option for SaaS providers who want to stay competitive in today’s market.

How Cloudentity Multitenancy Model Provides You With Most Flexible and Scalable CIAM Platform

Cloudentity multitenancy model gives organizations the freedom and flexibility to adjust our CIAM platform to any business needs. Depending on the requirements, organizations can create multiple tenants, each for a different purpose, or a single tenant with multiple workspaces and a separate authorization server connected to each workspace.

With Cloudentity as your CIAM platform, multitenancy provides the following possibilities:

• You can set up multiple tenants within different regions around the world ensuring the highest performance, availability, and reliability of our platform.

• Reflect your deployment pipeline by:

  • Setting up a desired tenant structure mixing Cloudentity platform tenants and their built-in subtenancy of workspaces

    For example, you can have only two tenants. One for non-production purposes like development, quality assurance, and staging, and you can manage access to specifc workspace using Cloudentity roles and permissions. The second tenant can be a tenant for production environment where only a limited set of people would have access to.

    Tenant Structure	Workspace Structure in Non-Prod Tenant

    This modernized approach requires less configuration effort to promote changes between different environments. Having non-production environments (workspaces) within one tenant means you can use client apps (or a single app) configured within the admin workspace to promote configuration between your environments using the import/export APIs. At the same time, you do not need to worry about unauthorized access to workspaces since you can control that using the built-in roles to delegate access to a given workspace.

  • Setting up multiple tenants each for a different purpose

    For example, you can have multiple development, quality assurance, staging, and production environments.

    

    Such an approach may require more work when it comes to promoting your changes between different environments.

• You can use one account to manage your organization’s tenants and later delegate administration to other admin users.

  For example, your DevSecOps administrator can set up the required tenant’s structure. Multitenancy allows you to customize each tenant to meet their specific needs and requirements, while still being able to manage them all from a single account.

• Promote configuration between different environments using Cloudentity export and import APIs.

  At Cloudentity, we take great care to provide freedom and flexibility for our customers to choose the best solution for their usecase. One of such options is using the GitOps approach and declarative configuration where all configuration is stored within a Git repository. You can, for example, use the acp-cd Helm Chart to declaratively configure tenants, promote configuration changes between deployments, and more.

  Learn More

  If you wish to learn more about importing/exporting tenants' configuration, migrating tenants, backing up tenants, or promoting configuration changes, check the following resources:

  • Exporting and Importing Cloudentity Tenants Configuration

  • Migrating tenants using import/export APIs and Promoting Configuration Changes to Different Environments

  • Declarative Configuration Import for Cloudentity Tenants

  • Backing Up and Restoring Tenants Configuration

• You can set up role-based access control and different permission systems.

  Cloudentity provides you with a possibility to set up different roles within your tenants or use predefined ones. You can have tenant administrators having the highest level of permissions and being able to administer all tenant’s, or you can, for example, have workspace administrators with permissions to access and administer only a given workspace.

  

Securely Utilize Multitenancy and Subtenancy Model to Create Production and Non-Production Environments

Utilizing multiple tenants to create staging and production environments and promote configuration from one tenant to another requires careful planning and management to ensure that all customers' data is secure and isolated from each other. Here are some steps to consider:

1. Create multiple tenants: Create separate tenants for non-production and production environments, each with their own databases, servers, and other resources. This ensures that any changes made to the non-production environment do not affect the production environment or any other tenant.

2. Utilize built-in subtenancy: Create dedicated workspaces for developers, quality assurance engineers, and staging environment within one non-production tenant for easier configuration promotion between environments.

3. Promote configuration changes: Once the staging environment is tested and approved, promote the configuration changes to the production environment. This can be done by using deployment tools or scripts that can automatically migrate the changes from one tenant to another.

4. Implement access control: Implement access control policies to ensure that only authorized personnel have access to the staging and production environments. This includes setting up role-based access controls and permissions.

5. Monitor and manage tenants: Monitor the tenants to ensure that they are running smoothly and are not causing any disruptions or errors. This includes regularly checking logs and performance metrics, and resolving any issues as soon as they arise.

6. Back up data: Implement a backup strategy to ensure that all tenant data is backed up regularly and can be restored in case of any data loss or corruption.

7. Test thoroughly: Thoroughly test any changes or upgrades before promoting them to the production environment. This includes testing the changes in the staging environment and conducting user acceptance testing before making any changes to the production environment.

Cloudentity multitenancy and subtenancy sounds good, right? Join us on the journey in making WWW more secure! Set up a free tenant… or multiple tenants! Sky is the limit.

try now