Lack of Multi-tenancy: A Broken Business Architecture?

Nov 4, 2010 by Sinclair Schuller

A couple of months back, there was a rekindling of good debate around multi-tenancy, it’s importance (or lack thereof), and who benefits most (if at all) from multi-tenancy. Cost angles as well as soft dollar angles were discussed, as was a good overview of the importance of multi-tenancy being represented in the aggregation of data into a single, digestible source and the value that creates all on its own.

For anyone who has read SaaSBlogs before, you probably know that I’m a passionate supporter of single instance, multi-tenancy as the architecture of choice in most situations (there are some good edge cases). Clearly, I side with the proponents of multi-tenancy in most of these debates, but I want to tackle something different this time. Typically, the supporting evidence is anchored on cost savings and efficiency that multi-tenancy brings to the table. Let’s look at the multi-tenancy discussion through a different lens: that of a business architecture.

We rarely consider the ramifications of software architecture decisions on fundamental business processes. Most software to date has been developed in a vacuum because the cost of operations and delivery have typically been borne by the customer, not the software company that created the product. I find that SaaS vendors are surprised when I discuss their technical decisions in terms of how it impacts their ability to sell in a most real sense. Let’s start with a simple example: offering free trials or running a beta program.

Free trials are used to provide prospects with some sort of evaluation period of your software so that they may make an informed buying decision. Beta programs give prospects and existing customers early access to new offerings, or to changes in existing offerings existing customers already subscribe to. In the on-premises world, this was a simple thing to do because you shipped bits to customers at no cost to you. As a SaaS provider, things are different: for both of these use cases, the SaaS provider must bear the incremental cost of delivery of each prospect or customer that asks for a free trial or entrance to a beta without associated revenue. The SaaS provider, being responsibility for delivery, now takes on the full operating burden that the customer used to take on to run an on-premises free trial or beta.

Now you ask “Sinclair, so where does multi-tenancy fit in?” If you understand multi-tenancy, you know that it drives up the ratio of the number of customers that fit on a given physical or virtual infrastructure by forcing resource sharing within application stack components. A “tenant” is a meta-construct that does not require physical boundaries for isolation. This means that the incremental cost of acquiring a new customer is as close to $0 as possible, and can remain at $0 if the customer posts little activity. Everything from your Oracle/SQL Server licenses to your physical or virtual infrastructure costs are spread across customers. A single instance per tenant model, even in a virtualized case, is severely broken in this respect. Let’s use a more concrete thought experiment to understand this.

Let’s say that we decided to use Amazon’s EC2 to virtualize our offering to provide for tenant isolation; that is, we create an EC2 virtual machine instance for each customer to our SaaS offering. As of the writing of this post, a small Linux EC2 instance costs $0.085 and a small Windows EC2 instance costs $0.12. Let’s use this and some other assumptions  to build a model to understand what free trials in a non multi-tenant world due to Customer Acquisition Cost (CAC) and the payback period of the CAC. Since Apprenda is in the .NET world, we’ll focus on Windows instances. This means that for every hour of a free trial we run for a single prospect, we pay $0.12. Offering a 1 month trial is quite typical. Now let’s assume that a customer earns us $250.00 in monthly revenue (for the sake of realism, maybe we earn $50.00 per seat per month, and the average deal size is 5 seats). Furthermore, let’s also assume that for every 20 prospects that try our SaaS offering, 1 decides to buy, giving us a 5% conversion ratio. Our model would look as follows:

(bigger)

Since our conversion ratio is 5%, the increase in cost for acquiring a single customer is $1,752.00 in the Windows case! Where does this number come from? Well, there were 19 trials that did not convert to paying customers. Running a 1 month free trial for those prospects cost $87.60 a piece!. The revenue generated by the single converted customer must account for the money spent on the 19 lost prospects. To add even more perspective, if we are generating $250.00 in monthly revenue from that customer, you’d have to keep that customer on board for 7 months in order to recover the money spent on CAC. In fact, that’s being kind and saying that every dollar of revenue can be spent on recovering CAC. This is incorrect, because in reality, you’d have to keep spending $87.60 per month for that EC2 instance for your new paying customer, which needs to be taken off the top of the $250.00, with gross profit applied to CAC recovery. This would stretch out to over a year, and we haven’t even accounted for the remaining customer acquisition cost (you know, the sales and marketing dollars you spent attracting new leads and closing deals). This is not feasible! Sure, you could shorten the trial, maybe ask the customer to foot an evaluation bill, or boost conversion by double, or all of these. At the end of the day, those are all extra hurdles  you could do without, and would be a band-aid that would simply reduce the pain a tiny bit.

Even on the LAMP stack, the results are terrible. You save a couple of months on CAC recovery; big deal. The fundamental problem is that this sort of “architecture” is not built for a more sophisticated delivery model, and “throwing hardware at it” is costly. Lacking multi-tenancy could really cripple your business architecture. This is just the tip of the iceberg. Things that should be simple, like effectively rolling out upgrades, managing orphaned trials, being able to build a revenue stream from data aggregation, are all hampered. We could probably find lots of ways that an ASP approach breaks down your ability to run a business or tune your sales and marketing, but this simple example seems to work as a good illustration of the types of problems to expect.

This topic is close to my heart because of SaaSGrid. As most of you know, SaaSBlogs isn’t really a place where I try to plug our platform, but it’s just so interesting to think that our customers don’t have to worry about multi-tenancy as they can inherit a single instance, multi-tenant architecture from SaaSGrid and avoid these problems without having to spend an additional 6 or 7 figures and 10 or more months in additional project time to get this sort of architecture like some of the older SaaS companies had to achieve good results like this or being able to show people how SaaSGrid can rollout an upgrade across 40,000 end users and a few thousand customers in a matter of 8 minutes because of the multi-tenancy it can inject into otherwise plain web app architectures.

As a SaaS provider, have you experienced similar results painted in the thought experiment? Have you considered issues like this prior to architecture planning? I’d love to hear your thoughts!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3500+ members and is growing every day; make sure you’ re not missing out and join today!