Multi-Tenancy Explained

This post is an aggregation of a lot of valuable resources that I found on the internet when I was trying to understand Multi-Tenancy. The pictures are attributed to their respective authors. Please look at the References at the bottom of the post.

What is Multi-Tenancy?

Multi-tenancy is the ability to run multiple customers on a single software instance installed on multiple servers to increase resource utilization by allowing load balancing among tenants, and to reduce operational complexity and cost in managing the software to deliver the service.

Multi-tenancy is not multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations.

A multi-tenant architecture, would expect a software application to virtually partition its data and configuration so that each client organization works with a customized virtual application instance.
Tenants on a multi-tenant system can operate as though they have an instance of the software entirely to themselves which is completely secure and insulated from any impact by other tenants.

Strategies of Multi-Tenancy

Three buckets of multi-tenancy strategies:

• Physical Separation. Physical separation relies on giving each tenant his own dedicated hardware resources.
• Virtualization. Virtualization is about using software to create application hosting environments that provide logical boundaries between each tenant.
• Design the application to be multi-tenant aware. The third strategy is to design different aspects of the application to automatically adjust its behavior differently for different tenants at runtime. Here multi-tenancy is a first class consideration in application design.

Advantages of Multi-Tenancy

1. Helps scalability: Scaling the application means maximizing concurrency, and using application resources more efficiently—for example, optimizing locking duration, statelessness, sharing pooled resources such as threads and network connections, caching reference data, and partitioning large databases.
2. Cost and effort saving: over and above the basic economies of scale achievable from consolidating IT resources into a single operation.
   Increase resource utilization by allowing load balancing among tenants,
3. Reduce operational complexity and cost in managing the software to deliver the service.
4. Everyone’s data can be backed up in one operation by backing up a single instance.  The operations costs are then lower due to economies of scale and increased opportunities for automation.
5. The tenant can expect to have a unique UI branding, business rules, workflows along with secure, partitioned and extensible data model and customized access control.
6. There is a possibility for different tenants on the same multi-tenant platform to share data. Think EDI.
7. Maximizing advantage from future enhancement in processor speed and other infrastructure.

Maturity model for Multi-Tenancy

• Ad Hoc/Custom- At this level, each customer has its own customized version of the hosted application, and runs its own instance of the application on the host’s servers.
• Configurable- the vendor hosts a separate instance of the application for each customer (or tenant) , vendor meets customers’ needs by providing detailed configuration options that allow the customer to change how the application looks and behaves to its users.
• Configurable, Multi-Tenant-Efficient – the vendor runs a single instance that serves every customer, with configurable metadata providing a unique user experience and feature set for each one.
  Authorization and security policies ensure that each customer’s data is kept separate from that of other customers.
  A significant disadvantage of this approach is that the scalability of the application is limited. Unless partitioning is used to manage database performance, the application can be scaled only by moving it to a more powerful server (scaling up)
• Scalable, Configurable, Multi-Tenant-Efficient- the vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer’s data kept separate, and with configurable metadata providing a unique user experience and feature set for each customer.
  Appropriate data partitioning, stateless component design, shared metadata access are part of the design.

CASE | SalesForce.com

Customization of application behavior, rather than being done by modifying application code, is done instead by configuring application metadata that is invoked on a user-by-user basis

Instead of customizing the application in the traditional sense, then, each customer uses metadata to configure the way the application appears and behaves for its users.
The challenge for the architect is to ensure that the task of configuring applications is simple and easy for the customers, without incurring extra development or operation costs for each configuration.

Metadata representation is extended to the deepest levels of database definition, custom business logic and fundamental design of user interface appearance and behavior.

Data partitioning is most important. Is the data partitioned per tenant for salesforce?

Strong separation between the application logic and their datasets.

Instead of hard-coding data tables and page layouts, developers on a multi-tenant platform define attributes and behaviors as metadata, which functions as the application’s logical blueprint.

More details on SalesForce.com Multi-Tenant Architecture

Supporting Multi-Tenancy at Presentation Layer

• Presentation services of a multi-tenant  platform: Users of Tenant get dedicated entry point with unique branding.
• Tenant isolation ensures that the user populations of the individual tenant cannot access the business service and information of the other tenants of the platform.
• Branding ensures that when an end user accesses a channel destination or authenticates with a channel, the end user is presented with a look and feel specific to his or her subscriber.
• All presentation components must support tenant-specific settings in a range from name-and-value pair configurations, such as tenant IDs, tenant-specific look-and-feel, with settings to indicate which form fields or action buttons should be rendered to end-users.

Supporting Multi-Tenancy at Business Layer

Each tenant of a multi-tenant platform is identified by a unique, platform-wide tenant ID.
The implementation of the services at the business layer must use the tenant ID to provide variability for service subscribers and individual end-users.
How?

• Metadata: Features of an application which can be configured during runtime, are defined in the form of Metadata (it could be an XML file stored on hard drive or a backend database).
• Metadata Services: A set of programmatically accessible services are designed that provides an interface to access/modify the metadata.
• An Engine: The business layer of the application is an engine that runs the business processes defined on the basis of metadata.

Supporting Multi-Tenancy at Data Layer

• Dedicated Tenant Database
• Shared Database, fixed extension set

• Shared Database, custom extension set (another table with key value pairs)

Concerns with Multi-Tenancy

1. Security and inappropriate data access
2. Impact of other clients on their system performance
3. Inability to establish and pay for their own, higher service levels (common among large companies)
4. Being forced into an upgrade
5. Inability to support the level of client specific configurations and even customizations as necessary
6. Inability to obtain client level user acceptance testing
7. Inability to determine the precise production/go live dates for the system.
8. If the number of users in a tenant are large, e.g. >1000 users then the multi-tenant advantages start loosing steam as they may need a separate hosting with separate maintenance etc.

References

1. SmoothSpan Blog, http://smoothspan.wordpress.com/2007/10/28/multitenancy-can-have-a-161-cost-advantage-over-single-tenant/
2. SmoothSpan Blog, http://smoothspan.wordpress.com/2008/06/20/degrees-of-multi-tenancy-degrees-of-green-crystals/
3. Multi-Tenant Data Architecture, Frederick Chong, Gianpaolo Carraro, and Roger Wolter, http://msdn.microsoft.com/en-us/library/aa479086.aspx
4. SalesForce.com, http://www.salesforce.com/platform/why-ondemand/muti-tenant-platforms/
5. A few more

Tagged: Multi-Tenant Architecture, Muti-Tenancy, Scalability

Posted in: Architecture