Complete Multi-Tenant – usually considered to be the purest form of multi-tenancy. This is also called “Shared Everything” model. As the name suggests, all the resources right from infrastructure, application and database are all commonly shared among all the tenants. Since all the resources are commonly shared between the tenants, it ensures optimal usage of all resources. Industry figure says, one can achieve upto 16x times cost efficiency compared to a single tenant model. While this model can give the utmost operating efficiency it also has inherent risks/complexities as outlined below.

– Requires a very complex architecture to implement multi-tenancyat all levels

– Creates a business risk as the data is shared between all tenants

– Difficult to provide customized data backup/restore services.

– Difficult to ensure equal distribution of load. For example, if Tenant A is heavily using the system and stores lots of data, compared to Tenant B who is minimally using the system and stores less data. In this scenario, there is a possibility that Tenant A can create bandwidth and other performance issues for other Tenants. But still there is no mechanism to limit Tenant A from utilizing excess resources.

Multi-Tenancy-Models

Single Tenant Database – In this model the application layer is commonly shared among all the tenants. For example, if the application server layer contains 4 clustered servers then all the 4 servers can serve any of the clients. However, when it comes to database it is separated by tenant. The level of separation is determined by the tenant architecture.

Different schemas within the same database – where each schema can contain the tables for the respective tenant

Different Databases within the same machine – Each tenant gets a different database. This gives the flexibility to provide specific services like customized back-up and restore services. For example, one of the tenants may request for backing up the DB every day night and email it to their FTP site. Supporting this request is easier in this model.

Different Databases residing on different machines – Independent machines are allocated for each tenant. This provides the highest level of security from a data isolation/storage perspective. This model also helps in dealing with varying level of usage scenarios. For example, if a tenant is going to use it extensively and the data growth rate is going to be extremely high then you might want to have an extra-large instance as your DB server. On the other hand for normal usage a medium instance should be sufficient. Of course, you will be charging the customer based on the infrastructure required for them. But the key is this model gives you the flexibility.

Single Tenant Application – This is the inverse of the previous model. Here the DB layer is kept common across all the tenants but the application layer is isolated. There are couple of scenarios where this model might come handy,

Metering – just like in the previous case for DB, if you want to meter the usage of this layer and charge the tenant accordingly then this model gives you that flexibility. You can also go for different instances for different tenants  depending on their need.

Customization – in case if your application is customized for a specific tenant, then this model allows you to run customized application for each of the tenants. Customization could be in the form of change in business logic, rules, display, etc. However, the DB layer remains constant across the tenants.

In case of any queries please feel free to drop me an email at [email protected]