I’ve been quite curious over the last year at the differing definitions of multi-tenancy that are given by multiple SaaS vendors. Admittedly not being a SaaS expert, or an expert in building and housing a multi-tenant application, I’ve found the contrasts to be a bit confusing. Apparently one can call themselves a SaaS vendor, but do almost nothing more than the old ASP vendors did when they would install an organization on a separate box and do some scheduled upgrades and maintenance for them. Fortunately, one of my favorite bloggers wrote some descriptions of what he’s finding In the SaaS marketplace.
First-degree multi-tenancy (e.g. Salesforce.com). Here, “all customers are served from a single infrastructure in which every component is shared, all the way down to the tables in the database” This purist approach is often called “shared schema multi-tenancy because the database structure is defined by the schema and if everyone’s data is stored inside that structure then by definition, everyone is sharing the same schema.”
Second-degree multi-tenancy (e.g. Intacct, a financial systems SaaS provider). This approach is similar to first-degree, but it “uses replication much more broadly than Salesforce.com to distribute its shared-schema instances across large numbers of server clusters.” A key advantage of this approach is that it can use low-cost hardware (e.g. Linux on Intel) rather than large Unix or Linux servers with massive databases. It also allows customers to operate on different versions of the system, based on which cluster they reside upon, giving some flexibility on when they upgrade to newer versions.
Lesser-degree multi-tenancy (e.g. Oracle, and others). There are many variations of this type, with the shared services primarily involving shared server infrastructure. Each customer has a separate database instance. This approach provides maximum flexibility to the customer but gives up much of the scalability and economic advantages of multi-tenancy. It appears that SAP’s greenfield SaaS offering for small business, Business ByDesign, is taking this approach. ((Scavo, Frank. June 18, 2008. :SaaS: Degrees of Multi-Tenancy.” Retrieved from http://fscavo.blogspot.com on July 13, 2008.))
I things I’d add one more after lesser degree multi-tenancy. This is the SaaS vendor who thinks that they can still be SaaS and not offer multi-tenancy at all as an option. I’ve seen this on just a couple of occasions, and while I’m not sure the vendors qualify as true SaaS vendors, the market for SaaS is new enough that I’m not going to be the one to attempt to sort it out.
2 responses to “Degrees of SaaS”
Even these degrees have shades. Salesforce operates across a number of individual data centers (see them at trust.salesforce.com) for example. I doubt everyone is sharing the same schema (as when one data center has issues, it only impacts the data and customers in that data center). However, clearly many people (in each of the data centers) are sharing the same schema.
IMHO, multi-tenancy should really be a means to an end. The question should really be about the “service”. The reason that multi-tenancy becomes important is that the cost of running a SaaS operation with multiple databases is expensive and ultimately that will either increase the price or decrease the service. The key for any software vendor selection should be the value they offer you and a piece of that value has to be tied to their viability. If your software vendor does not have a viable business model you are not going to get the value of their software for long.