Recently we have run across a slew of inquiries regarding multi-tenancy strategies. A little research indicates that the definition of multi-tenancy has evolved quite a bit since it was first applied to SaaS models over 10 years ago. Pure SaaS players often use their adherence to multi-tenancy fundamentals as a competitive differentiator when competing against non-SaaS or even hybrid SaaS alternatives in the marketplace. A look at the evolving use of terminology and its most recent connotations has yielded somewhat surprising results.
To provide some historical context, Salesforce.com first promoted the use and definition of multi-tenancy over ten years ago. By its account, “pure” multi-tenancy employs a shared database and shared schema. All customers share an instance of a database using a singular schema. Furthermore, Salesforce claims that when its software is upgraded, all its customers are upgraded en force. In reality, Salesforce has evolved to about eight instances of its software hosted in various geographies, and has about 5,000 customers per instance.
Other SaaS vendors, particularly those serving large customers, began employing a slightly different model of multi-tenancy. Under the clustered multi-tenancy approach, a customer might have a somewhat dedicated instance of the software and database. However, every customer has the same software and same schema, just separate instances. When even the smallest customer can justify the CPU and database resources of a dedicated physical or virtual server, the economies of scale of sharing hardware resources in the pure Salesforce model no longer provides an obvious advantage. Thus, vendors such as Netsuite have developed the clustered approach where a cluster serves a large customer or a group of smaller customers, but typically no more than a few hundred. The software and schema are replicated, thus every customer is on the same version of the software and typically are upgraded simultaneously, although this approach allows the vendor to stage upgrades potentially not upgrading all customers simultaneously.
Another approach championed by Oracle is virtual multi-tenancy. Larry Ellison once said “multi-tenancy is a hack that predates virtualization.” With this approach, databases and application servers are not shared. Each customer has dedicated virtual instance (which might share physical servers). Schemas and application code are identical, but tremendous coordination and tooling are needed in order to fully support simultaneous vendor-managed upgrades. In practice, this approach looks a lot like dedicated hosting, and has been used by vendors who are gradually transitioning to SaaS offerings from more traditional on-premises ones.
Finally, the latest definition of multi-tenancy is logical multi-tenancy, which promotes the abstraction of application capabilities from the underlying architecture. Workday is the poster child of this approach focusing on its platform’s benefits and “the power of one.” While under the covers Workday no doubt shares infrastructure and databases, the details are not revealed. Instead the focus is on sharing the same code base across all customers, vendor-managed upgrades, and the power of the community that can be built when all customers are using the same version of the same product.
The importance of multi-tenancy is often exaggerated, particularly by traditional multi-tenant vendors when competing against legacy vendors trying to move to cloud. What we have learned is that evaluating vendors on solely that criterion is shortsighted. In fact, what should matter to a customer is the cost of the product or service, the vendor’s ability to provide seamless vendor-managed upgrades, how well the vendor meets the performance SLAs, and the vendor’s adherence to strict security and privacy standards. If a vendor can do this they meet the test of logical multi-tenancy and can succeed in the SaaS business model, regardless of the details of the underlying technology architecture.