A couple of years ago, I faced some difficulties in choosing the right architecture for a SaaS-based web system. The idea of building a customized solution came up at the early stage. However, as the need of such system and the lack of an existing quotation system
that is intended for the businesses appeared. So we decided that each company will have its own data separated from the rest, which influenced the architecture that we chose. But before we define those, let's take a quick look at a couple of terms.
This is nothing but a tiny bit of introduction about the subject that I feel it's nice to share, and usually, those architectures are delivery models, and they have different variations and all sorts of layers and what not.
Software as a Service
I know, I know. This is not 2010 anymore, but SaaS remained one of the top delivery models out there. Software as a Service is a software delivery model in which the software is accredited on a subscription basis and is centrally hosted. It became a standard delivery model for many business applications like management information system (MIS), enterprise resource planning (ERP), customer relationship management (CRM), database management system (DBMS) software, and human resource management (HRM). SaaS usually is browser-based web application and accessed through the internet.
SaaS service model is one of the four foremost categories of cloud computing, along with Data as a Service (DaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Cloud architecture requires components to form the cloud computing. These components are consist of front-end platforms (fat client, thin client, or mobile device), back-end platforms (services, and storage), a cloud-based delivery, and a network (internet).
Multi-instance VS Multi-tenant
SaaSs are being built by IT upon four architectures mainly; those are multi-instance, multi-tenant, single instance, and flex tenancy. The result will not differ to the end user much, but it will vary regarding the architecture of the system, data and its access, the configuration, and user management. They both have a tendency to solve the same problem, however, multitenancy adverse to multi-instance.
In a multi-instance architecture, multiple companies will run their own separate instance of the application, with their own distinct database. Also, it could run on a different operating system (OS), and a different hardware platform, so it is very flexible. Each business will have access to its data separately from the other.
However, in a multi-tenant architecture, multiple companies will be using a single instance of the application, with a single database, running on the same hardware and same OS. This architecture does not give much flexibility but simplifies the process of adding features and fixing code bugs.
Many argued that the multi-instance be better than multi-tenant approach when it comes to cloud architecture, and according to many, this is how the enterprises run their mission-critical applications.
The following are two lists of the advantages and disadvantages of multi-tenant approach.
- Cost effective. Using the same infrastructure and resources.
- One shared cloud. The cloud provider sustains for all users.
- Time effective. It requires less time and resources for updates/upgrades a large number of users at a given instance.
- Always on the latest version. Changes take place in the whole environment and happen once for the system/application.
- Shared database. Any action that affects the multi-tenant database will affect all shared customers.
- Preventing exposure of data happens in the application layer. The developer team will be responsible for preventing data exposure from one client to another, which will sufficiently increase in terms of complexity.
- Any security breach has a massive effect as it will affect every tenant in the system.
- Not customizable. Tenants cannot customize the application to fit all their requirements.
Now, for multi-instance, here are the two lists.
- Data isolation. Each consumer has its database and infrastructure.
- Great flexibility and control of configuration and customization.
- High availability. If one instance is down due to infrastructure issues, it will not affect others.
- High scalability. Let it be in the case of an individual server, virtual machine, or container per consumer; it is always easy to add more resources including, but no limited to, memory, CPU, or cache.
- Ability to move consumers individually.
- Highly customizable. Updates and upgrades can be performed on individual customer instances where it fits the requirements and the needs of the user.
- It is harder to deploy changes to multiple instances.
- Not cost efficient when it comes to creating and configuring the environment such as the database or the application.