26

According to the definition available online, "Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers". It means 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 school clients like school1.schoolmanagement.com & school2.schoolmanagement.com but the code is the same behind both these subdomains. Both schools have different functionality or theme depending 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?

5
  • 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, 2017 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, 2017 at 12:58
  • @KristianH thanks for the domain hosting example, I got it.
    – Nomi Ali
    Jun 24, 2017 at 12:59
  • @Laiv So we can have different database for each client with their own separate configuration?
    – Nomi Ali
    Jun 24, 2017 at 12:59
  • 2
    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, 2017 at 13:03

3 Answers 3

14

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
2

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.

13
  • 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, 2017 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, 2017 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, 2017 at 13:36
  • 2
    It might Interest you softwareengineering.stackexchange.com/q/340531/222996
    – Laiv
    Jun 24, 2017 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. Jun 24, 2017 at 13:46
0

Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. Tenants may be given the ability to customize some parts of the application, such as the color of the user interface (UI) or business rules, but they cannot customize the application's code.

In a multi-tenant architecture, multiple instances of an application operate in a shared environment. This architecture is able to work because each tenant is integrated physically, but logically separated; meaning that a single instance of the software will run on one server and then serve multiple tenants. In this way, a software application in a multi-tenant architecture can share a dedicated instance of configurations, data, user management and other properties.

Please refer to https://whatis.techtarget.com/definition/multi-tenancy for more info..

As in your case, every school members subscribing to your site will be authorized on the basis of tenancy roles and permissions and will be provided access to their respective databases via same application. A single application which is connected to multi-databases. If you create a subdomains for every school then that makes it fall back to same Single Tenancy model.

I hope this answers your question.

1

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