There are more ways than one to develop a web application to meet different needs. Sometimes, a separate instance of the application is installed for each customer, in a setup known as a single-tenancy. While in multi-tenanted applications, a single instance of the software and the supporting infrastructure serves multiple users in a multi-tenancy architecture. Here every customer or tenant shares the software application and a single database. In a multi-tenant architecture, the application is designed to segregate the configuration and data to ensure every tenant works with a customized virtual application instance. The software is intelligent enough to know who the data belongs to once the data in the database gets tagged as belonging to one user or another.
Multi-tenant applications are mainly grouped into three type of users. Admins who have top-level access and are the clients who own the site. Then come the managers, the resources from the company, who manage the projects and users at the company level and finally the end users of this application. Each page will be accessible to users depending on their authorizations. Users might be given the ability to customize certain parts of the application, like the color of the user interface (UI) or business rules, but they cannot customize the application's code.
Advantages of Multi-tenancy:
Multi-tenancy reduces cost by sharing same power resources and software across its clients. The software requires licenses and support, and the cost for this will increase if you need to buy them for each customer, as in the case of single-tenancy. Shared infrastructure will automatically lead to lower costs.
In a multi-tenant application, you’ll only have to monitor and provide administration for a single platform, unlike single-tenant applications where you have to manage different sets for each client. This way a multi-tenant SaaS provider can deliver more efficient and effective support, including problem resolution and troubleshooting.
A multi-tenant architecture will make it easy for you to increase your capacity when more strength & power is required. The total capacity of the entire system increases and becomes more scalable when you bring in new hardware to the platform, not for merely a single client but all associated clients. Adding features for a single client makes it available to other clients.
Upgrading the software version or system resources for multi-tenant applications are easy since there is a single, centralized place for up gradation, installation and more.
Disadvantages of Multi-tenancy:
A multi-tenant app has lesser flexibility than a single-tenant app to set low-level configurations. This might not be a problem for you, but if your application requires a lot of customization for each new tenant, then a multi-tenant app might not be the best solution.
A multi-tenant app is more complex than an equivalent single-tenant app, whose configuration can remain essentially static. In a single-tenant application, you don't require any code to detect which tenant a web request is intended for or to protect your clients from the leakage of data between tenants. The log formats are simpler since logs are segregated with a separate instance of the application for each client.
Since a multi-tenant application is backed by a single database, running on a single server, it has lesser areas prone to failure, but those failure points can prove a lot more disastrous. All tenants experience loss of service When the database for a multitenant app is unavailable, unlike when a single-tenant application instance breaks. It brings down a single tenant. Other instances continue unaffected.
How to create a multi tenant Rails app?
Apartment is a top Ruby library known for separating tenant data. Simply put, you can create tenants using Apartment, and to each tenant, the library will automatically assign a new isolated schema. The creation of isolated database instances is also possible with Apartment. Apartment will provide you tools to help you handle multiple tenants in your Rails application. While still allowing some data to exist in a common tenant, If you need to have certain data sequestered based on company or account, Apartment can help. Apartment will allow you build Rails-based SaaS apps with partial or full white-labeling right from the beginning. To get the most out of Apartment, consider using a PostgreSQL database.
Now how does Apartment work? Apartment fetches data from the schema corresponding to the elevator: domain, subdomain, or full host name. Using these elevators, the library analyzes each request to the database. Apartment segregates tenants by subdomains, by default, but you can set it up to use domains quickly. Keep in mind, when it comes to a shared schema, Apartment doesn’t work. Your development team only needs to assign IDs to tenants and send database requests with those IDs to implement a shared schema approach, and if you’re going to provide subdomains or custom domains for your clients, you’ll need Detectify. For modern Rails-based SaaS apps, you’ll want more flexibility. Here’s where Detectify comes into the picture. Detectify can build database requests using both subdomains and domains. Detectify, when sending a URL-based request to the database also lets the app ignore routes. Overall, Detectify proves to be a more advanced multi-tenancy gem than Houser.
Multi-tenancy is more often than not a misunderstood and misused term. Multi-tenancy is an architectural approach enabling a single instance of an application to be shared among multiple organizations or users, also known as tenants and is applied only to SaaS. The core principle here is, it is the single instance of the application which is being shared. Hence, multi-instance architectures aren't the same as multi-tenant architectures.
Anything which is poorly designed will never work ideally, but here more than most cases, a poorly designed multi-tenancy will do you no good whatsoever. This is because a poorly designed multi-tenancy can hinder the core function of it, which is the reduction of operations costs, by impacting automation among other things. The development of a multi-tenant Software as a Service application with Rails goes further than just designing the database layer. If you choose the perfect database architectures at the beginning itself, it will be a lot easier to develop, scale and support your web application in the long run.