SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Does the Cloud make Single-Tenancy OK for SaaS?

Posted by Bob Warfield on April 15, 2009

Multi-tenancy and all its flavors seems to be on people’s minds lately.  I just finished going back and forth with Phil Wainewright on some of the nuances of multi-tenancy and how it impacts the cost model for SaaS.  Phil’s post was on some of the sophisticated nuances of multi-tenancy as expressed by some of the latest announcements from the SaaS Vatican,

More recently, it has come to my attention both through my fellow bloggers of the Enterprise Irregulars as well as via a trackback to my blog post that there are those who are now saying the Cloud has made the world safe for SaaS vendors to forget multi-tenancy and plunge ahead with single-tenancy.

Not so fast! 

Color me skeptical.  If you don’t have a multi-tenant architecture, you’re going to argue it isn’t necessary.  That doesn’t make it right.  Before we get too far along, let me define multi-tenancy:

Multi-tenancy is a software architecture that allows multiple tenants to be hosted on a single box (or cluster of boxes) just as easily and economically as a single tenant could be hosted on the same configuration.

The bloggers taking the position that single tenancy is good enough hoist a variety of flags in support of their position, but for me, it boils down to answering one simple question about your SaaS business and its customers:

Fundamentally, do you have an application that can successfully run multiple tenants on a single box or not? 

If a single box has enough horsepower to run multiple customers for your app, the argument for single-tenant is completely (pardon my near-pun) untenable.
Salesforce runs 55,000 customers on 1,000 commodity servers.  You just aren’t going to be able to do that with a single tenant architecture no matter how much virtualization you choose to run.  If nothing else, virtualization runs afoul of a fixed cost/variable cost phenomenon very quickly.  A lot of the basic system software allocates fixed overhead, whether we’re talking about your DB server, your app server, your web server, or whatever.  Virtualization does not share the resources required for the fixed overhead, only the the variable costs.  Multitenant shares the fixed overhead too.  Those variable costs put an upper limit on the number of tenants you can shove onto a single box, no matter how small the tenant’s needs may be.
The new articles maintain that the Cloud fixes all this through the magic of elasticity.  Really?  That’s hogwash.  The Cloud at best and if you really architected your app to take full advantage of elasticity may help a little bit.  But most of the problem is database, and elasticity and databases so far remain a very hard technical problem to solve.  Try dynamically varying your partitioning and/or federation scheme to really scale up and down in real time in the Cloud.  It’s hard enough to get apps to scale to arbitrary Enterprise needs at all.  Try doing that in real time so you get multitenant cost savings?  Good luck!
So if you can’t run an average of 55 customers on each of 1000 servers like Salesforce, how many can you run without multitenant?  3?  5?  10?  What does that do to your cost versus true multitenant?  What does that do to the overhead of maintaining the servers?  What does that do to your cost of delivering the service and to the resultant cost model you have to saddle you customers with?  What does that do to you competively if you’re up against a company that does have the true multitenant cost advantage?
One example on the cost subject that I am familiar with:  a lot of the Social Software companies wind up charging by page views or total participant seats.  In many ways, this is anathema to community where you should do everything you can to encourage participation and not penalize it.  This is especially true for outwardly facing communities where the company wants a predictable cost model and can’t imagine being charged by their continually changing customer base or especially the changing usage patterns of that base.
In fairness, there are some business model + company + market + architecture combinations where it wouldn’t matter because you can’t run multiples on a single box.  If you’re strictly selling to organizations that can’t run on a single box no matter what, single tenant is fine.  Perhaps this is what these other bloggers are saying, but I’m skeptical any Enterprise 2.0 app would have that requirement, and that’s the kind of software these bloggers are describing.  FWIW, Helpstream will run 150 customers and nearly 400K seats on a single box loaded to about 10% of capacity.  That’s nothing though.  Look to the Googles, Facebooks, Amazons, eBays, Twitters, and similar big web properties to see real capacity.  Now combine that kind of capacity with multiple tenants.  It is a powerful competitive position to be in.

As I say, one can imagine combinations where you couldn’t combine multiple tenants onto a single box.  A honking big transaction processing ERP app might be one.  For another, at Callidus, I had customers using as many as 150 CPU’s to generate all the sales commission calculations for a huge salesforce.  To give an idea, we had telcos paying 20K sales reps and insurance companies paying 250K reps.  That’s a lot of transactions paid to a lot of people!  But those kind of Enteprise deals are very unusual for SaaS companies, and that kind of app is pretty unusual too because of the number of transactions being processed and the complexity of the business logic.  Still, such apps could be successful in those markets with single tenancy.
The articles go on to talk about the advantages of being able to customize these multiple instances.  Frankly, that scares me too, because the whole SaaS model really starts to break apart there when you decide to radically customize each instance.  It may be a value add, but it is a radically different value add than SaaS.  In fact, at that point, it’s a hosted ASP model, not SaaS.  Useful for some organizations, but there is a reason that model never achieved broad market appeal. 
Lastly, let’s talk about the whole security business.  This is the 800lb Red Herring in the room.  The minute you go SaaS or Cloud, you have outsourced that problem.  You can listen to vendors argue all day long about which architecture is “safer”, but that is an over simplification of the myriad factors that matter to the point it is just marketing and not substance.  It has as much to do with process as code architecture, which is why most of the security related standards like SAS70 and HIPAA don’t spend a lot of time on software architecture so much as the processes that surround that software.  Don’t take my word for it.  Look at what happened to Amazon around the whole AmazonFail incident for lack of process on an area that didn’t even involve any code.  Their problem was due to a data change.

BTW, the multi-tenancy imperative gets stronger constantly due to the multicore crisis.  We no longer get faster cpus (i.e. faster clock speeds) every 18 months according to Moore’s Law.  Instead, we get twice as many cores.  The easiest way to take advantage of more cores?  You guessed it: stack more tenants into the same box. 

For more, read Michael Dunham’s excellent post over on Haut Tec.

12 Responses to “Does the Cloud make Single-Tenancy OK for SaaS?”

  1. ssacks said

    Seems to me that one of the main reasons for multi-tenancy is to minimise the overheads of upgrading to new versions/patch bugs/etc – if every user is on its own box, that seems like a lot of upgrades if you have a substantial user base.


  2. […] meme” spread across blogs recently too – read more about the subject in Bob Warfield’s article on the SmoothSpan Blog.  It is a well-written response to the misconceptions that have been springing up. Share and […]

  3. mhug said

    All these technical reasons in favor of multi-tenancy are well put together, and to be frank I agree with them very widely. I would particularly emphasize the fact that support and maintenance is a paramount element in a software vendor business model: if you run a single tenant architecture you cannot help but ending up maintaining X versions of your app, which drives your costs up, and sooner or later it will impact the customer bill.

    There’s another two points though imho: I believe that there are functionalities (namely “collaborative” funtionalities) that cannot be easily delivered in a single tenant architecture, while they are rather natural in a multi-tenant context, especially cross-customers collaboration. Think of anything that’s more or less close to a market place kind of functionality. I’m not saying it is not possible with single tenants, it’s just not natural, and will ultimately not be maintainable.

    Besides nobody expects a bank to run one deposit account only; wy should a software vendor?

  4. smoothspan said

    Mhug, the opportunity for cross-customer collaboration is an excellent one. Any kind of reporting across tenants is a related case, as is the case where for whatever reason a single customer may even desire to own multiple tenants. All of these have come up in real world situations I’ve been exposed to.

    Thanks for bringing that up!

  5. […] why single tenant is needed (and feasible) for SaaS based on the public cloud.  Paul Warfield weighs in on the economics (economies of scale) of SaaS that argue for multi-tenancy instead of single […]

  6. rnugent said

    Bob, you run all of Helpstream on one box? Then why did you feel the need to move that box to AWS?


  7. smoothspan said

    Ray, we don’t run it all on one box. The figures I quote above are from a load test we ran just prior to moving production that shows we’re capable of running on one box.

    As for why we run on Amazon, there are a whole host of reasons that have been covered such as this:

    In addition to it being considerably cheaper (we now estimate about 70% cheaper), there is considerable operational flexibility and it performs better than our old datacenter implementation too.

  8. markbyers said

    At we have been using multi-tenancy for 9 years – there is no comparison when servicing smaller businesses – the leverage, as stated in the smoothspan blog, is massive.

    The other effect to consider is the ratio of subsciber users to resource using users – we are finding because we are using web-based foundations (serve and POST) – that any one time the ratio can be as high as 100/1 eg at any one time a 1000 users only look like 10 users to the service, even though they may all be logged on. If you don’t have multi-tenancy (even with virtualisation) you effectively you have a massive amount of your resource idle at anyone time.

    The question is not about virtualisation vs traditional but more about what is the foundation layer of the application – eg is it a pure web-based foundation or a “PC” based foundation – as that has the greatest impact of how far you can leverage your resources and the economics of it.

  9. […] Comments Oracle compra Sun: a… on Oracle Buys MySQL, Java, and s…markbyers on Does the Cloud make Single-Ten…People Over Process … on Oracle Buys MySQL, Java, and s…tic616 on Oracle Buys MySQL, […]

  10. […] you either have in mind a very interesting application + customer combination (some do exist, and I have written about them), or you just don’t understand.  10x the hardware to handle the “before you put in data” […]

  11. […] you either have in mind a very interesting application + customer combination (some do exist, and I have written about them), or you just don’t understand.  10x the hardware to handle the “before you put in data” […]

  12. […] Does the Cloud make Single-Tenancy OK for SaaS? « SmoothSpan Blog. […]

%d bloggers like this: