Multi-tenancy – what is it, why should you care?
I’m continuing on my jargon busting mission.
Today’s target: “multi-tenancy”‘ and it’s allegedly inferior sibling, “single-tenancy”
What do they mean, and why should you care? I’ll try to answer the second part of that question first from the perspective of “you” being a SaaS startup, and then from the perspective of a Customer.
What is it?
Desktop software was designed to be installed on your computer and only accessed by you and therefore only contain your data. So you are the single tenant. The only person living in that application/database. This is single tenancy.
Software that’s designed from the ground up for the web is designed to be used by lots of people. One application/database, but lots of people using it. (for the techies amongst you, I really do mean one database, not one instance of a SQL server but with multiple databases running in it). This is multi-tenancy.
It does seem that single-tenancy comes in two flavours: one set of code for the application (ie, one set of files serving the app), but multiple databases OR multiple sets of code as well as multiple databases. The former being only half as evil as the latter.
Why should you (a SaaS startup) care?
If you’re not using the multi-tenancy model you’re not getting even half of the benefits of operating a SaaS business model.
Would you rather have just one database/set of files to maintain, or one db/set of files for each individual user?
When it comes to support issues, do you want to have to consider whether or not the user has the most recent version of everything in their personal installation or would you rather everyone had the exact same thing?
When you have to roll out an upgrade, would you rather one single schema/file set to update or one for each individual customer.
And here’s the biggie: infrastructure…
So you can get lots of installations on one server. Let’s be generous and assume one server can support 1000 instances of of your application and database. Customer 1001 is going to cost you a fortune as you will need to bring on a new server for it.
As your customer base grows the cost of your hardware (whether leasing or buying) rockets, as does the time cost in maintaining them. With a multi-tenancy model you don’t have this issue. We’ve generated £100k+ revenue per month (thousands of users) from a single server costing <£1k a month. You just can’t do that with the single-tenancy model.
Why should you (a customer) care?
That’s simple – it costs the vendor a lot more to run a single-tenancy model. Guess who, ultimately, is going to cover that extra cost? And when you have support issues, you’re going to get them resolved much faster (for all the reasons stated above) by a multi-tenancy vendor than a singe-tenancy one.
I didn’t choose to rhyme, rhyming chose me
You will find lots of web-based applications that have a single-tenant arrangement. The supplier of the software has a whole list of reasons that they “chose” this model, but the truth is that they didn’t choose it. They came up with the list of reasons AFTER having the model (or “architecture” as we like to call it) decided for them.
The most common reason that they have this model forced upon them is because they took a product designed at first for the desktop and have then shoe-horned it into working on the web. The company didn’t know if this whole SaaS stuff would take off, it was a bit of a gamble. So to minimise the risk they decided not to write an application from scratch but instead use what they have.
A short-sighted and cheap way for them to dip their toes in the water.