“Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance.” (Wikipedia)

Multitenancy and software product lines

One way of looking at things is that multitenancy is one level above software product lines. You can use SPLE to produce something that works as multi-instance or multi-tenant. I suppose you might approach it in different ways. But you still want all the core principals of code reuse. And then whether you deploy as separate installations or one installation differentiated by certain parameters, you still need to be able to switch in different pieces of code as applicable.

I think the relationship is this: multitenancy requires SPLE. SPLE does not require multitenancy. Multitenancy is kind of a run-time variability, and is more of an operations concern than a develop concern. It definitely requires SPLE style development. But potentially the same SPLE development that the multi-instance requires anyway.

Multitenant vs multi-instance

“The key problem designing a multitenant system is deciding upon the right balance between providing tenant isolation (on the one hand) and the cost of providing such dedicated resources. Said a different way, you must figure out just how much of the resources can be shared amongst your tenants so that your solution works properly but is as cost efficient as possible. Typically, the more a resource can be shared amongst many tenants, the more cost efficient that solution is — so long as it still satisfies the performance and security requirements.” — Microsoft

The main benefit of multitenancy seems to be cost efficiency. And the main disadvantage seems to be complexity of design.

With multitenant, if one goes down, they all go down? With multi-instance, they’re segregated. Multi-instance is perhaps easier from an operations point of view.

So multitenancy is fairly difficult to do, and the main benefit is resource/cost savings. So if you’re not hitting any resource constraints with your multi-instance architecture, why bother doing multitenancy?

It feels like multitenancy would open a whole can of worms with security between customers. So unless it’s really beneficial, it seems simpler to go with multi-instance approach.

“One approach to supporting multiple distinct customers is to reject the multitenant route completely and allocate resources for each customer on demand. When you use this approach — called single tenant — you are automating the provisioning of dedicated resources for customers. If you imagine a spectrum of distributed application architectures, this approach represents completely tenant-dedicated resources on one side, with completely shared resources on the other.” — Microsoft

“When you build a multitenant application, you need to weigh the costs of resources against the isolation you want to provide each customer. It’s easy to think that you will need to consider which application and data resources are shared between customers and which are allocated exclusively to customers, but it’s important to realize that being multitenant is not an all-or-nothing proposition when it comes to resource sharing. In a service-oriented application, you are able to — and most likely will — mix and match which resources are shared between customers and which resources are exclusive to individual customers depending on your requirements. It’s worth emphasizing this again: You can decide which application services can be shared, and which cannot be — and to what extent they are shared. This gives you a tremendous amount of design flexibility. Use it.” — Microsoft

So if you do multitenancy in an architecture, where could you position it? You could have it at the client layer, the service layer, and the data layer. Each one of those places you could either host multiple tenants on one instance, or have an instance per tenant.

e.g. one mvc app running multiple tenants. One web service dealing with service calls from multiple tenants. And one data layer dealing with multiple tenants. And one DB or multiple DBs for each tenant.

I’d argue that until you hit a point where it becomes difficult having separate web services, don’t bother until then. get?


  • list of pro/cons for multitenant vs multiinstance
  • some examples of multitenant sites