Posts Tagged Multi-tenancy
Posted by Gurpreet Singh and Raj Sethi in SaaS on May 2nd, 2011
In our conversations with companies, whether it is building new SaaS products or engineering legacy products to SaaS the question of multi-tenancy always comes up. Multi-tenancy is still a significant source of confusion and uncertainty when developing SaaS applications. We have encountered clients that have wasted considerable resources developing multi-tenancy when it should not have been a business priority, and others that have chosen the wrong development path not understanding that multi-tenancy was critical for their business. In this post we try to clear up many myths and confusions about multi-tenancy, and also provide a simple and practical classification of multi-tenant architectures that has helped us guide clients developing SaaS applications. In Part II of this post, we provide a model that can help companies decide whether to go multi-tenant or just develop a virtualized solution. Although, many consider a virtualized architecture to be pariah among SaaS, it is still a good option in many scenarios.
Multi-tenancy is a much abused term, so let’s provide an overview before we go forward. Applied, specifically to SaaS, multi-tenancy is an architecture that enables a single instance of an application to be securely shared among multiple organizations, also called tenants. The users of the application are employees or partners of the tenant/organization purchasing SaaS. Data of each tenant is private or can be shared depending on the nature of the application. A well designed multi-tenant architecture and operations automation are among the most critical elements in reducing operating costs for SaaS providers. The emphasis on well designed multi-tenancy is important. We do not wish to re-visit the green crystals debate, but a good multi-tenant architecture will facilitate automation in a host of areas, while poorly designed multi-tenancy can cause significant operational problems. Despite its benefits, and what many SaaS providers will tell you, multi-tenancy is usually never considered a driver for clients purchasing SaaS; its benefit should be viewed solely in helping the service provider reduce operations costs of a SaaS application – a very important driver for SaaS companies.
In our experience, we have found it helpful to divide multi-tenancy into two types. The first type of multi-tenancy addresses only sharing of tenants on a single instance of the application, and does not provide for any meaningful customization of the application for each tenant. We call this Compaction Driven Multi-Tenancy (CDM), and the goal of the architecture is simply to maximize sharing among tenants in order to reduce application delivery costs. The other type of multi-tenant architecture focuses not only sharing of the application instance among tenants, but also enables customization of the application at the tenant level. A great example of this type of multi-tenancy is Salesforce.com. We call this Compaction and Customization Driven Multi-Tenancy (CCDM). Just to clarify, by customization we mean features like changing the object model/database schema, workflows, user interfaces, business logic, and integration with external systems etc. for each tenant of the application. Also, these customizations are assumed to be done dynamically while the system is online.
Multi-tenant architectures that support customization (CCDM) are more complex and costly to develop than CDM architectures. The complexity in CCDM arises from the need to provide indirection points to support tenant specific code without changing the original code base, and the need to implement any tenant level persistence schema extensions from the original persistence schema. These customizations can be accomplished in many ways, a meta-data driven architecture being a choice we prefer. It is also important to understand that irrespective of multi-tenancy, all types of SaaS architectures have to address problems in the areas of Provisioning, Security, Scalability, Failover, Patch Management, Integration, Version Control etc. Solutions to these problems depend on a host of factors like SLA’s, application price, and other business practices, and become more complex to resolve due to the introduction of multi-tenancy. Thus, it is important for companies to carefully view business considerations before embarking on the development of multi-tenancy.
Transitioning from a CDM to CCDM architecture is a considerable amount of work. We have seen successful evolution in the past, for example with Salesforce.com. Over the years they have increased the application customization capabilities with considerable success, and now offer many these features as a part their Force.com platform offering.
Although we have not addressed multi-instance virtualized architectures in detail, they do represent an option for SaaS providers in many cases. Virtualized architectures are easier to develop, and multi-tenancy may not be an economically viable approach in many business cases. In part II of this post we address these issues, and provide a simple model that will help companies decide whether to invest in developing multi-tenancy or just choose a virtualized architecture for their SaaS applications.