You must have come across umpteen articles talking about the technical aspects between a single tenant model and multi-tenant model. But the fact is that the decision between single tenant and multi-tenant is a strategic one and more often decided by the business factors rather than the technical factors.

However, some of them tend to overlook the business aspects while making this decision. While single tenant may seem to be an attractive proposition for quickly moving to SaaS model without too much of risks/investment, it brings in a lot of overhead which many a time people realize only when they are bitten by the raising operational costs.
In the interest of those who are already confused between single tenant and multi-tenant – my addition (definition) to your confusion.

Single Tenant Model – Each customer gets a separate instance of the software which runs on a logically isolated hardware environment.

Multi-Tenant Model – All the customers are served from the same common software instance and hardware infrastructure.
Let’s further focus on the single tenant model. The key point to note here is this model requires a proportional increase in the resources (software, hardware and all other necessary aspects to service a customer) in line with the increasing customer base. In simple words, if you have 10 customers today you need 10 logical servers and tomorrow if this grows to 100 customers then you need 100 logical severs. Not to forget the rest of the resources, which will also keep multiplying.
Let’s further delve in to the resources to get better clarity,

1. Hardware CapEx – This is straight forward as you saw from the previous example. However, the situation can be worse when you need more than one server/machine to deploy your application. For example, if your product follows service oriented architecture then most likely you may want to have your service layer on a separate machine. or say you have a separate reporting engine that works asynchronously then again you will most likely deploy it in a separate machine (so that the live transactional ones are not affected). In this scenario you will soon end up becoming a premium customer for your hardware vendor.

2. Software Licenses – Your product would probably use a set of licensed DB/tools/utilities/third party components/etc. Most of these licenses are server based licenses, which means you need to buy them for every instance that you are setting up. This is one reason why people choose open source tools to reduce this overhead cost.

3. Implementation Cost – Most of the single tenant versions (which probably would have been working in a on-premise model earlier) do not provide sophisticated levels of customizability/configurability. While they support the basic level of changes through settings, your customers may want beyond that. Therefore, the implementation time for tweaking your product to meet the customer expectations is going to be considerable. From what I have seen this ranges anywhere between 2 weeks to 6 months (depending on the complexity of the product and the client requirements).

4. Running cost – Rapid breeding of your hardware systems are going to pose you a big challenge on the Saas operational expenses (OpEx). This includes everything ranging from your power consumption, (rack) space cost, system admin person, infrastructure monitoring tools, OS upgrades, Anti virus softwares, etc. One other key challenge is the product upgrade. You need to replicate all the release engineering steps (backup, deploy, test, etc.) ‘n’ times, where ‘n’ is your number of customers. Automating your release engineering process may help you bring down this cost.

5. Software Maintenance Cost – It’s fair to expect that your customers are going to ask for changes down the line, if not big ones definitely a small set of enhancements. Now, you don’t have a choice other than to do these changes on the instance that was given to that particular customer. Else, if you intend to maintain a single copy of your product then you will have to do it on the common product and rollout that change across to all the instances, which again is a big overhead. So, you will naturally end up having a large maintenance team to carry over these activities, which is not adding much value to your business.

This is not to support one model over the other, rather the point is to be aware about the pros and cons in each model and be more objective in your strategic decision. As you saw, Single Tenant model is attractive to begin with but you will have to work on your multi-tenant solution to meet your growing customer base.

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