10

According to the definition available online is "Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers". It meann I have a Restaurant or School website and I provide access to different restaurant or school to use my application with their own data by using their credential I provide once they purchase my school management product. Like my website is like schoolmanagement.com and I provide different sub domains to different schools clients like school1.schoolmanagement.com & school2.schoolmanagement.com but the code is same behind both these subdomains. Both schools has different functionality or theme depend on their separate database. So I need to provide schoolmanagement.com for login and once my client login based on their login credential I redirect to their respective url e.g school1.schoolmanagement.com.

This is my understanding of multi tenant application. Is my understanding right? Is there any online multi-tenant application that I can go through.

  • 1
    What do you mean by "Is there any online multi-tenant application that I can go through."? Would you want to get the source, or try out as a tenant, or run as the host? As you note, domain hosting is a common multi-tenant example, with both large and small host companies. Google Apps for Business (or whatever the current branding is) is also a fairly wide spread multi-tenant app. – Kristian H Jun 24 '17 at 12:54
  • 1
    So far, you are in the right path. Mult-tenancy is regarding to the data ownership. The data is segmented by tenans (owners). The application use to be the same for a simple reason: economy of scale. The data storage could be also the same or it could be different for each tenan. The data is not shared-accesible among tenans (or usually they are not, so far I know). – Laiv Jun 24 '17 at 12:58
  • @KristianH thanks for the domain hosting example, I got it. – Nomi Ali Jun 24 '17 at 12:59
  • @Laiv So we can have different database for each client with their own separate configuration? – Nomi Ali Jun 24 '17 at 12:59
  • 1
    Yes. That's (IMO) the preferable way. But it's also the expensive one. When I say different databases they could be: a) Different schemas or db instances within the same RDBMS or b) totally different RDBMS. – Laiv Jun 24 '17 at 13:03
8

Yes, that's it. But wikipedia's definition is not general enough. It does not address multi-tier architectures or newer forms of architecture like SOA or microservices.

Multi-tenancy is about software systems and data isolation. Some examples:

  • a multi-tier system with a unique database can be multi-tenant. Example: a SAP system is composed of a database backend and a couple of web application servers that expose in a scalable manner web-services. It is multi-tenant: you can add a new customer without changing the running software installation, and several customers can use the system without ever knowing about each other. The data is completely isolated (proprietary technology).
  • your system is composed of one or several processes running webservices that are exposed to different customers via different domain names (but it's still the same processes that run it on the server). The data isolation is achieved with separate databases. It's definitively multi-tenant.
  • a microservice system could similarly run several loosely coupled sets of webservices, each using an own micro-database. If needed in order to scale up, you could start new clones of the same microservices and they would via some registering feature find their peers and automatically connect to them, offering to the user the behavior of a single application. Then there are two scenarios possible:
    • if, when you want to serve a new customer, you have to start a new separate set of microservices, and organize that the microservices for one customer only connect to the microservices relating to the same customer, then it's single-tenant.
    • but if you could serve new customers using the running instances (and new microservices would only be needed for performance), then it's multi-tenant
1

I'd say yes, your understanding is basically correct. The application is shared by multiple customers, and also each customers data is comingled in the database. Sharing the same code without having different customers' data comingled in the same database would probably not be considered multitenant.

  • 2
    @NomiAli No, I would not consider that multitenant. That's stamping out a separate environment for each customer. one of the benefits of multitenant is that the database and software are upgraded for all customers at the same time. One deployment, and everyone is on the newest version. What you're talking about is every customer having their own separated installation. I suppose you could have a shared codebase but different databases, but that would be foolish as you need to be super careful about your DB changes, making it more expensive, which defeats the purpose of multitenant. – Andy Jun 24 '17 at 13:19
  • 1
    @NomiAli A schema per customer would have even more drawbacks than a database per customer, its even more difficult to manage because you have to run the same scripts just changing the schema names. Again its not impossible, but the point of a multitenant application is to reduce the costs for the software vendor; the things you're asking about push them back up. – Andy Jun 24 '17 at 13:23
  • 2
    So if my lonely database, which holds all the tenans crashes or gets compromised... Where the cost reducing goes? And what happens when every tenan has different needs of resources and performance? What if they want to have access to the data storage? ... Yes. Different data stores per tenan and different schemas is multitenacy. Here the business strategy and the services we want to provide with to thd customer is more important than the implementation details. Multi-tenancy is a feature, a differential value. The closer is to the customers needs, the better. – Laiv Jun 24 '17 at 13:36
  • 2
    It might Interest you softwareengineering.stackexchange.com/q/340531/222996 – Laiv Jun 24 '17 at 13:41
  • 4
    You overstate the multi-database aspect a bit. Multiple databases is just a design decision; you can have multiple databases share the same schema and use a script to update them all simultaneously. All multi-tenant applications must separate each customer's data from the other customers; the mechanism by which this is done is an implementation detail, and depends on factors like the degree of isolation desired, etc. – Robert Harvey Jun 24 '17 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.