Explanation of Tenant Load Balancer in SaaS maturity model level 4

Question

I've already done some research about SaaS maturity level based on Gianpaolo SaaS maturity model.

Right now I got confused about SaaS maturity level 4. It said, it has a "Tenant load balancer" that dynamically calls a new application instance to serve load balancing for a SaaS application.

I want to know what this "Tenant load balancer" really means. How do we implement this "Tenant load balancer" in the real world or in an application server?

Can anyone give me some good explanation and an example, like an implementation in Java EE technology?

Answer 1

The key concept is horizontal scalability with load balancing. On a high level this is similar to an ESB/load balancer that is used in a SOA environment.

Below are some of the properties of Tenant Load Balanced SAAS deployment:

1) More than one instance of the SAAS software is running.

2) Tenant calls to the software could be processed by any of the instances. The load balancer takes care of routing the tenant requests to one of the instances based on load balancing strategies.

3) Scalability: There should be provision to add a new instance with little effort when the load increases beyond what can be serviced by the current instances. For example, in a cloud environment a new EC2 instance can be started and the SAAS application can be deployed on it. The load balancer can route additional calls to this new instance. This approach applies to non EC2 environment also.

The load balancer functionality could be provided by the ESB itself or via integration frameworks/hardware load balancer/software laod balancers.

The load balancing applies to backend stores too like databases, search index stores etc. Here is some info on the database setup in a SAAS environment, not load balancing in particular.

Answer 2

One way to implement Tenant Load Balancer:

1. Create multiple instances of the application - say A,B,C. Each with its own database.
2. Create one meta-database - this database has info on accounts, logins, etc.
3. Login interface is single. ie everyone logs on to same web interface.
4. When a user signsup, allocate him to one of the app instances (A,B or C).
5. When user logs in, authenticate against the meta-database and then redirect to specific instance.

So for example:

1. Login site is setup at www.example.com
2. App instances are available at a.example.com, b.example.com, c.example.com
3. To signup, user goes to www.example.com
4. To login, user goes to www.example.com
5. After successful login, user is directed to a.example.com or whatever his instance is.

This is how Salesforce.com does it. They have different instances for different regions and allocate clients these.