Multi-tenant Application

Multi-tenancy is an architecture in which a single instance of a software application runs on a server and serves multiple customers. Each customer is called a tenant.

Multi-tenancy can be economical because software development and maintenance costs are shared. It can be contrasted with single-tenancy, an architecture in which each customer has their own software instance and may be given access to code. With a multi-tenancy architecture, the provider only has to make updates once. With single-tenancy architecture, the provider has to touch multiple instances of the software in order to make updates.

Figure 1: Multi-tenant Architecture

Figure 2 : Detail overview of multi-tenant application architecture

A multi-tenant application needs to be carefully designed in order to avoid major problems. It:

needs to detect the client (or tenant) that any individual web request is for;
must separate persistent data for each tenant and its users;
has to segregate configuration for each tenant;
cannot allow cached data (e.g. views) to leak between tenants;
requires separate background tasks for each tenant;
must identify to which tenant each line of log output belongs.

Figure 3 : Single-tenant and multi-tenant application

Advantages of Multi-tenant application

1. REDUCED MAINTENANCE COSTS

A multi-tenant application is a single codebase, installed in a single location (a single server or pool of servers), and potentially relying on a single instance of each backing service (cache, database, log, etc.). When an end-user reports an error, developers don't need to determine first on which instance the error occurred before replicating and debugging. A single source of application logs helps here, too. And when a fix is ready, it gets committed into the (only) repository, and re-deployed to the (only) server/pool – so all tenants benefit from the fix immediately and simultaneously.

2. NCREASED SCALABILITY

Imagine a situation where an application is set up for two clients, and each client generates about 1.5 server's worth of load. If the application is deployed separately for each client, it takes four servers (two each) to handle the total load. On the other hand, a multi-tenant application could be installed on just three instances to handle the same load. With more tenants, the advantages of a multi-tenant architecture grow even further.

Disadvantages of Multi-tenant application

1. INCREASED COMPLEXITY

A single-tenant application is simpler than the equivalent multi-tenant app. There doesn't need to be any code to protect against data leakage between tenants, or to detect which tenant a web request is intended for. Its configuration can be essentially static. With a separate instance of the application for each client, logs are segregated, so the log format can be simpler.

2. REDUCED DISTRIBUTION OF RISK

By running on a single server (or pool), backed by a single database, a multi-tenant app has fewer points of failure – but those failure points have a greater effect. When a single-tenant application instance breaks (say, the database goes down), it brings down a single tenant; other instances are able to continue unaffected. When the database for a multi-tenant app is unavailable, all tenants experience loss of service.

3. REDUCED FLEXIBILITY ACROSS TENANTS

A single-tenant, multi-instance app has greater flexibility to set low-level configurations (of the server hardware or OS, or of the web server, or the application itself) than a multi-tenant app. This won't be a problem for many applications, but if the application needs a high degree of customization for each new tenant, a multi-tenant app might not be the best solution.

References

http://whatis.techtarget.com/definition/multi-tenancy

https://quickleft.com/blog/introduction-to-designing-multi-tenant-web-applications/

http://www.devx.com/webdev/Article/44977

http://jesusgilhernandez.com/2012/12/13/multitenancy-architecture/

Note :- I am writing this post as a reference to remind me that what I learned. And the content on this post may be taken from any other source and I will reference it also. I write this post thinking that it will be easy to remind me the learning things clearly and it might be very helpful to other interested people online.

Role Based Access Control

In computer systems security, Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. Roles are defined according to job competency, authority, and responsibility within the enterprise. It is used by the majority of enterprises with more than 500 employees, and can implement mandatory access control (MAC) or discretionary access control (DAC).

Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members or staff (or other system users) are assigned particular roles, and through those role assignments acquire the computer permissions to perform particular computer-system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department.

Three primary rules are defined for RBAC:

1. Role assignment: A subject can exercise permission only if the subject has selected or been assigned a role.

2. Role authorization: A subject's active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.

3. Permission authorization: A subject can exercise permission only if the permission is authorized for the subject's active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.