Why Multi-tenancy is more than just a technology strategy
[Written by Jeffrey Vogel, Managing Director | Bulger Partners]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 differentiators when competing against non-SaaS or even hybrid SaaS alternatives in the marketplace. A look at the evolving use of the term and its most recent connotations has yielded somewhat surprising results.Salesforce first promoted the use and definition of multi-tenancy over ten years ago. By their account, pure multi-tenancy employs a shared database and share schema. All customers share an instance of a database using a singular schema. Furthermore, Salesforce determines when the software is upgraded, and all customers are upgraded at the same time. In practice, Salesforce has evolved to about eight instances of its software hosted in various geographies, and has about 5000 customers per instance.Other SaaS vendors, particularly those serving larger 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 server 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 most modern definition of multi-tenancy is logical multi-tenancy. Workday has rewritten the rules, focusing on capability rather than architecture. In their literature, rather than describe the physical architecture, workday focuses on the benefits and “the power of one”. While under the covers they clearly share 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. 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 all 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.