In the early nineties multi-tenancy was relevant, a new breed of solution providers were emerging, led by Salesforce.com. The multi-tenant approach employed a software framework, which used a single instance of software running on a server that served multiple tenants; a tenant being a group of users who share a common access with specific privileges to the software instance. With a multi-tenant architecture, a software application is designed to provide every tenant with a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties.
In the 2000s, multi-tenancy underpinned almost all ‘Software as a Service’ (SaaS) enterprise application delivery – Salesforce was a pioneer of this approach. In fact enterprise software was designed and constructed with cloud deployment in mind. But why was this?
Fifteen years ago infrastructure was expensive. There was no cloud – at least not like we have today. This meant companies wanting to offer SaaS applications had to build and run their own costly data centres. Virtualization technologies were still in their infancy and there were no DevOps tools; making it hard or even impossible to automate instantiation of new instances. Meaning even more manually intensive activities.
Executives naturally tried to limit by means of software the usage of expensive resources such as hardware, software and people, that were needed in creating data centres.
[easy-tweet tweet=”Implementing multi-tenancy at both the application and database tier allows you to maximise utilisation of resources” hashtags=”cloud, multi-tenant, “]
Implementing multi-tenancy at both the application and database tier allows you to maximise utilisation of those resources. This is achieved by having more customers running on the same instances; limiting the number of instances required and allowing you to save on hardware and software licenses.
The past fifteen years has seen an ongoing debate about application multi-tenancy. Discussions focus upon software architecture, data models, practical problems with operations, data separations between tenants and so forth. All good topics that are worth discussing, however, in my opinion, what would be more pertinent would be to question the relevancy of multi-tenancy in the everything cloud age. At the risk of upsetting cloud purists my answer to the title of this article is no.
Times have changed
Today, 15 years or more after the creation of application and database multi-tenancy, things are different; the economic necessity for multi-tenancy at the application tier has disappeared.
We have huge clouds offering cheap infrastructure and tooling for automatic scaling in and out, creating new instances and tearing them down again without any of the manual interventions that used to be necessary. There are new services popping up every day, like databases being charged per transaction rather than per instance, which means you do not have to pay in the event the tenant is not using the database. You have availability zones offering service redundancy, ensuring that your application, services and database are – nearly – always available. Best of all, these cloud resources are very cheap, and there are lots of them.
[easy-tweet tweet=” vendors could and should question the value of retrofitting multi-tenancy into their database and application layers” hashtags=”cloud, multi-tenant, data”]
With all these new infrastructure technologies available at a low price, vendors could and should question the value of retrofitting multi-tenancy into their database and application layers. It may quickly turn out to be a bad investment compared to building installation and upgrading automation scripts into the underlying cloud management system for handling quick, on-demand instantiation of new tenants.
While there are many other reasons for updating existing software, simply adding multi-tenancy should no longer figure on the list. When building a completely new system, there is no reason not to design the application tier as multi-tenant, but it is not the overriding imperative it once was for a SaaS application. Rather than saving cost, as it did fifteen years ago, in some cases it may even add unnecessary complexity and overhead to the design of your application.
In summary
1. Do not refactor multi-tenancy into existing apps just for the sake of it.
2. Focus on installation and upgrade automation, so no human intervention is required to:
a) Instantiate new tenants
b) Conduct horizontal scaling
3. For new or major refactoring, include multi-tenancy into the architecture provided this does not add unwarranted complexity and overhead to your software.
Why would customers care?
They should not care – all they should care about is the SLA. So why is it that customers do seem to care about a software architectural construct? Salesforce and other SaaS pioneers greatly succeeded in persuading customers that multi-tenancy is a feature of the product rather than an architectural construct originally created to save operational costs for the software providers themselves.
Although I agree that fifteen years ago application multi-tenancy was important to lowering cost and therefore a great USP for the SaaS providers; today I’d say it doesn’t really matter.