Mutli Tenancy - multi tenant apps and frameworks

time to read 2 min | 396 words

Previously on the Multi Tenancy series:

Tobin Harris asks:

I'm interested in learning the difference between a multi-tenanted application and a framework.
For example, Ruby on Rails is a bit like a multi-tenanted application for developers. Each application has the same core modules, the same folder structure, and broadly the same architecture.
Rails also has a set of key extension points. You add your own views, controllers and models. You download the plugins you want to add pre-built slices of functionality.
In Rails, they've found useful extension points to where the variability can go.
Is this completely different to how you might build a multi-tenanted application? Could you build a "framework" that provides the core functionality, with appropriate extension points? And then just use that framework to build a multi-tenanted application at a good pace?

In general, multi tenancy applies when talking about specific business domain, not with a specific technical domain. There is also the idea of single-instance/many-tenants, which we also need to consider. In short, the comparison is between apples and oranges, because the drive that may lead to similar ideas comes from a totally different perspective.

A multi tenant application is focused on giving a base line functionality and then allowing the user to customize it further. Most business applications have this need. Consider a helpdesk application, the workflow and behavior is different from system to system, but the baseline functionality (tracking calls, SLA, escalations, etc) is shared.

A framework gives me an empty shell to work with, with a default install of a multi tenant application, I can already do something. In other words, the main difference is where the value lies.