SmoothSpan Blog

We’ve talked about the cost advantages multitenancy can bring, up to 16:1 compared to a single tenant per instance.  But how many tenants do we have to put into an instance to get those kinds of savings?  In other words, what metrics should we shoot for?

Once again, we can turn to statements made around Salesforce.com to get an idea.  For example, Michael Dell says that Salesforce was running 40 Dell PowerEdge servers at one point in time.  If we go back into Salesforce EDGAR filings, we can see that they had 6,700 customers (tenants) and 134,000 seats when running on the 40 Dell servers.

With a little math, we conclude that if we view the 40 servers as one instance, Salesforce was able to stack in 168 tenants per server, and 3,350 seats per server.  I’ve queried my contacts at various other SaaS companies and learned that this is pretty high in their estimation.  Admittedly, the CRM application is not very taxing on machine resources relative to a lot of other applications.  It’s basically fill in a form and keep track of the data with a little reporting.  Transaction rates are governed by the rate at which sales cycles change and are added, which is pretty slow among Enterprise transaction rates.  Based on that, let’s view Salesforce as the practical zenith.

It does seem like we can draw some conclusions pretty quickly.  Most virtualization strategies are not going to let you run 168 instances on a single server.  Figures I’ve head are in single digits.  If nothing else, virtualization means you don’t modify your software.  Virtualization is therefore good at sharing variable costs, those costs your software is designed to vary anyway, but not so good at sharing fixed costs. 

One of the SaaS vendors that uses virtualization mentioned a good example of this fixed versus variable cost issue.  He mentioned that adding a domain to an app server has a fixed minimum cost to them of 1GB of RAM.  His reaction to the SFDC figure was to say that running 170 zones (what he calls their virtual partitions) was a non-starter because it would mean the server needed 170 GB of RAM.  A true multitenant architecture could share the app server resource requirements across many tenants.

Note that this fellow I talked to wasn’t sweating it very much.  His business calls for fewer larger SaaS tenants than Salesforce.  Their average is in the hundreds of seats per tenant, not 20 or so like Salesforce, so they naturally have many fewer tenants.  All of this has to factor into your decision making when considering multitenancy versus virtualization for SaaS.

A last consideration is that even loyal multitenancy fans still keep multiple instances, each of them multitenant.  There are a variety of reasons to do this that boil down to operational convenience.  If nothing else, it’s easier to build and provision an instance and then migrate customers to it when doing upgrades.  Opinions vary on how many servers go into an instance, but vendors I talked to are thinking along the lines of 50 to 100 at the high end.

Utility computing infrastructure with painless scale up/scale down would have a bearing on this.  I’ll be writing more about that over time.