SaaS multi-tenant options

Rajesh Ranjan looks at the different multi-tenancy arrangements that can be set up with SaaS offerings

There has been a great deal of debate about multi-tenancy and SaaS. Everyone has an opinion – and rightly so. I was discussing this with budding SaaS enthusiasts recently, and just about half identified SaaS with multi-tenancy.

So what does the other half think? The questions that were thrown at me included:

• What do you mean by multi-tenant application?
• Does single code base qualify any application as multi-tenant?
• Isn't multi-tenancy just another technical solution that is SaaS?
• What does SaaS have to do with multi-tenant architecture?
• Isn't multi-tenancy a database term?

Broadly, people gave the following three options when it comes to multi-tenancy:
• Single database, single schema with shared table space across tenants
• Single database, individual schema for each tenant
• Single database instance per tenant

Aren't we talking about databases here? What happened to the discussion of SaaS? In today's technical world, you so often start discussing one topic but end up either narrowing it down to one single idea or widening it to include a broad range of subjects.

It is important to understand that everyone has different needs and recognises any topic with their respective needs. This is the glass half full versus half empty syndrome.

What does multi-tenancy mean for different people? It means multiple tenants per schema for IT operations, it means single code base for developers, it means a selling point for sales people, but the most important group, that actually is not worried about multi-tenancy, is the customer.

You may find this surprising but it is true.

Usually when customers buy a SaaS product, they have already made up their mind on sharing space with other so-called "tenants". Though a customer is a tenant, in SaaS terminology they are not usually referred to as such by those outside the technical team.

They know it is a single code base application, serving multiple customers, and they are OK with that. Some bigger customers that have an IT team will know the meaning of "tenant". They know how they are "housed" and may have some preferences as to how they would they liked to be housed.

It may affect their decision, but it is one of the requirements and products offering a solution for that housing need – which will be shortlisted in a competition to win the order.

Some purists go on to say that your SaaS product must be able to handle all scenarios, so it can cater to all kinds of multi-tenancy needs. In reality this is very difficult to achieve.

You can always design a shared table space database model and then use a central configurable database to indicate which tenant has purchased what option. You can charge customers based on the options they choose, on how they are willing to be housed, and have differential pricing based on the infrastructure and operation cost metrics.

However, if you have many combinations to address, it may be difficult for your IT operations team to manage. Indeed, in some cases it might even negate the cost advantage, and we have not even talked about performance yet.

Choose a multi-tenancy model that suits you and your customers. Talk to your prospective customers about how they would like to be housed, discuss this with your IT operations team to figure out the complexity of each option, and engage an engineering team to provide technical depth to the solution.

But essentially it is your customer's business call – that of a collective business entity.

Rajesh Ranjan is programme director for product engineering services at MindTree