Multi-tenancy – Simplified

Recently I was having a conversation regarding multi-tenancy, and one of the responses I got – our application already supports multiple users, so it’s already a multi-tenant. Do multiple users mean multi-tenant – is that correct?

Before we even go further and explore multi-tenancy, lets understand difference between a user and a tenant.

  • User – User is smallest unit of classification. User can be independent or can belong to a role or a tenant. Simplest way to identify a user – user will have its own username and password to login into the system.
  • Role – Role is classification within a tenant and multiple users can belong to a role. E.g. within a system, a group of users may belong to an administrator role or sales role, etc. One role may overlap over another role, but a role can’t be a subset of another role.
  • Tenant – Tenant is the largest classification. Tenant is generally used to define a department, or an enterprise, which enforces their own policies or rules within a system. Each tenant will consist of different set of users. User is not shared across a tenant.

1

Apartment Society is a perfect example of a multi-tenancy. Apartment Society has centralized administration for security (CCTV, security at entrance, etc), electricity, water, and other facilities. These facilities are governed by the apartment association and shared by tenants. One apartment can be classified as one tenant, for whom the individual electricity/water bill is generated. But each apartment may have multiple users, i.e. family members staying within an apartment. And what is a benefit of an apartment – it provides security, privacy to a tenant, even if they are using shared resources of apartment society like electricity, water, parking etc.

So, what is Multi-tenancy with respect to Software?

When a single application is shared by multiple tenants (i.e. organizations or departments) is termed as multi-tenant application, considering each tenant is oblivious of another tenant. Multi-tenant application should be smart enough to have partitioning of data, compute and user experience based on each tenant.

Benefits of multi-tenancy

  1. Reduction of operational cost – as shared infrastructure is leveraged by multiple tenants.
  2. Centralized management – as shared infrastructure needs to be managed, rather than multiple infrastructures for each tenant.
  3. Reduces turn around time to on-board new tenant.

Things to be considered carefully while designing multi-tenant solution

  1. Data Privacy – strict authentication and authorization required, so that customers should only access their own data.
  2. Serviceability and Maintainability – single update to the application will affect many different tenants, so any update must be planned carefully.

What factors influence multi-tenant architecture?

Before we define a multi-tenant architecture, lets look at what factors will influence architecture patterns for multi-tenancy,

  1. Views – tenant can define styling of the application
  2. Business Rules – tenant can define their own business rules and logic
  3. Data Schema – tenant can define their own database schema for the application
  4. Users and Groups – tenant can define their own rules to achieve data/system level access controls
  5. User or System Load – each tenant may have different user-load requirements. E.g. Tenant-A has huge user base, and in comparison, Tenant-B & Tenant-C combined has a small user base.

Type of design patterns to implement Multi-tenancy

Multi-tenancy with a single multi-tenant database

This is the simplest form of multi-tenancy. It consists of single instance of app instance (both UI and business layers), along with single database shared across multiple tenants. Usually tenant data is segregated within the database using tenant key/ID.

2

Multi-tenancy with single database per tenant

Second form of multi-tenancy is – single instance of app instances (both UI and business layers), but database is segregated for each tenant. Cost will be higher than the first option, but operation complexity will reduce due to individual databases, and will make it easy to manage data schema changes for each tenant.

3

One of the solutions to implement this pattern is through Azure SQL Database Elastic Pool feature – https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-pool

Multi-tenancy with single-tenant business compute instances with single database per tenant

Third form of multi-tenancy is – single instance of UI app instance, but business compute layer and database are segregated for each tenant. Cost will increase more than the second option, but operation complexity will reduce due to individual databases and easy to manage business compute instances for each tenant. Will make it easy to implement and deploy business rules for each tenant.

4

With adoption of containerization and docker technology, it becomes easier to segregate compute instances, and even than manage them as one unit. Examples are Azure Service Fabrics and Kubernetes. Azure Service Fabric and Kubernetes are distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable micro-services and containers.

Multi-tenancy with single tenant compute instances with single database per tenant

Fourth form of multi-tenancy is – all three layers, UI app instance, business compute layer and database are segregated for each tenant. Cost will be highest for this option, but will provide complete segregation of security, privacy, compute and data for each tenant.

5

Hybrid Approach for Multi-tenancy

We looked at four different patterns to implement multi-tenancy. There is another factor that influence a lot in selection of patterns, i.e. user/system load for a tenant. Suppose user load for Tenant-A is so huge that we can’t share its instances with another other tenant. But user load for Tenant-B & Tenant-C can be shared within a single instance.  So, for these scenarios, you can consider hybrid approach, i.e. mix and match option 1 to 4. Example – for Tenant-A, go for segregated compute and database instances, but for Tenant-B and Tenant-C, you can go for shared compute instances.

6

So in end, multi-tenant architecture will help you serve everyone, from small customer to large enterprise, using shared resources, reduced cost and brings operational efficiency.

Cloud Agnostic – Not a myth anymore, just architect solution differently

Vendor Lock-In – a term which every IT decision maker is either talking and thinking about. No one wants to be locked with one cloud provider but like to have flexibility to move around or at-least have an option to move around enterprise workloads between different cloud providers.

Multi-Cloud Strategy

Knowingly or unknowingly many organizations already find themselves of adopting multi-cloud strategy. Meaning they are using different cloud providers for their multiple workloads, example – one workload in AWS and another workload in Azure, but don’t have the flexibility to move workloads from AWS to Azure or vice-versa.

1

Example of Multi-cloud strategy

Within the above multi-cloud strategy example, if IT wants to move Workload-2 from Azure to AWS, it will not be straightforward, and it will require some effort. Reason for that – because Workload-2 was not designed to be cloud agnostic.

So, what is Cloud Agnostics?

A workload that can be migrated seamlessly around different vendor clouds will be called a true cloud agnostics workload. But is it possible to be true cloud agnostic? Yes, it is, you just have to design and architect it to be cloud agnostic. But before we look into how to design a cloud agnostic solution, let’s look at different models in the way a workload can be cloud agnostics.

Dev/Test and Production Segregation

Running development and testing on one environment and production on another environment is one of the most common scenarios. Benefits of this setup is, running development and testing on cloud environments which are cheaper and don’t require scalability, and only use Production where scalability is required.

2

Example of Dev/Test and Production segregation

Disaster Recovery in another cloud platform

Leveraging another cloud provider for Disaster Recovery environment is the most useful scenario for being cloud agnostics. It requires running production environment on one cloud provider and running same copy of application on another cloud provider. If production environment goes down, all requests should be diverted to DR environment hosted on another cloud provider. While designing this cloud agnostics DR strategy, you have to keep RTO (Recovery Time Objective) and RPO (Recovery Point objective) in mind and design it accordingly, which will drive decisions like – how frequently data sync need to happen across DR site, etc.

3

Example of Disaster recovery in another cloud platform

Production in multi-cloud (truly cloud agnostic)

It requires running application simultaneously on different vendor clouds and both sites are up and running simultaneously and sharing user load. Benefits of this approach is – in case one cloud provider runs into issue and goes down, your workload is still up and running without any or with minimal RPO (Recovery Point Objective) impact. Only drawback of this approach will be – cost, as you will be paying double to both cloud providers. But it’s an ideal solution of business mission critical applications.

4

Example of Production environments in multi-cloud

How to architect workloads to be cloud agnostics?

Before you decide designing your solution, you need to understand what all services are common across different cloud providers. To understand that, you can categorize cloud services broadly within three categories,

  1. Base Services – Services which has become standard to provide any cloud-based services, such as virtualization, networking etc.
  2. Broadly Accepted Services – Services which has been industry accepted and mostly available across all cloud provides. Example of these type of services are, Dockers, Kubernetes, MongoDB, PostgreSQL, etc. As the cloud adoption increases, you will see more an more services getting moved within this category.
  3. Unique Services – These are services which are unique to each cloud provider and becomes their selling point and differentiator. Examples of these are AWS Lambda, Azure IoT Hub, Azure Cognitive Services, etc.

5

Segregation or categorization of services

Now to design/architect your solution and be cloud agnostic, prefer to choose services from first two categories. If you choose to use any of the unique services provided by cloud providers, in that case you are automatically tied up with that provider and you are no more cloud agnostic.

Managed Services

Question arises, if you restrict yourself up to broadly accepted services, in that case you may miss out most of the managed services provided by cloud platforms. If any of the managed service provides huge advantage in comparison to building on your own, in that case it makes sense to use it, rather than not using it for the sake of vendor lock-in. If you still want to be vendor independent, in that case there are two options,

  1. Look for managed services which accepts common protocols. Example of this is – Azure Cosmos DB, which can be accessed using MongoDB wire protocol. So, your application can have flexibility to leverage Azure Cosmos DB using MongoDB APIs within Azure, while also leveraging Mongo DB in AWS, getting a benefit of managed service within Azure.
  2. Second option is to have your own layer of segregation before leveraging managed services, so that you can switch to another provider later.

6

Example of custom providers for different cloud platforms