Increase efficiency with multi-tenant cloud software architecture

Often evolution in the performance or capabilities of software is driven by the business. Users expect a lot from modern software. The requirements for a satisfactory experience have grown and deepened. Solutions must be fast, available globally and reliable with varying traffic loads. Additionally, development solutions must be scalable and cost effective. Developers must be able to update the code, test it and deploy it to multiple locations with high precision and velocity.

To implement such software, teams must put considerable effort into the planning and development processes. In order to justify those efforts and make the software more efficient and reusable, we have started to steadily shift towards cloud computing. Yet businesses are still asking the question, how can a multi-tenant cloud application architecture help you increase efficiency and scale?

Benefits of Multi-Tenant Cloud Architecture

Today despite differences in data sets, solution functionality can be applied to multiple use cases — often with few alterations. That need has driven cloud providers to create innovative solutions and tools allowing development teams the ability to reuse hardware and optimize the cost of the infrastructure. However to take advantage of the opportunities the cloud provides, we need to adapt the architecture of the software we write. That new architecture must align with the specifics of the hosting environment and leverage the benefits of the cloud. That’s exactly where the multi-tenant architecture shines.

Multi-tenant cloud application architecture allows development teams to write code once, implement features in one codebase without duplication and serve multiple businesses/projects, while satisfying their security, performance and business needs. A tenant is a term used to refer to each client of the software.

Multi-Tenant Cloud Application Architecture Approaches

The Role of Cloud Computing and Its Types

The core function of cloud computing is to provide a physical infrastructure that can be easily shared. That makes the cloud an alternative to local “on-premise” hosting, which greatly reduces the costs and risks. By employing a cloud infrastructure, we shift our efforts from deploying and maintaining such environment to writing the actual software. This enables us to address the needs of the business more fully. Shifting responsibilities in this way can best be described as: The cloud provider exposes the environment as a service, and we use that service to host our software.

There are three primary models under which the cloud service operates:

• Software as as Service (SaaS) that is designed for end-users and delivered over the web. Multi-tenancy lives here.
• Platform as a Service (PaaS), which is a set of tools and services designed to make the deployment of those applications quick and efficient.
• Infrastructure as a Service (IaaS), which is the hardware and software that powers it all — servers, storage, networks and operating systems.

With the SaaS model, a provider licenses an application to customers. This happens either as a service on demand, through a subscription in a “pay-as-you-go” model or at no charge when there is an opportunity to generate revenue from streams other than the user. Those alternative revenue streams can be advertising, for example. The multi-tenant architecture is how we implement our software in order to become a SaaS.

Which Should You Choose: Single-Tenant vs Multi-Tenant

Single-tenant is basically a single instance of the software. Every tenant (client) has its own database and resources. Comparing between the single-tenant vs multi-tenant approaches, there is no sharing of resources with single-tenancy. When there is a new client, you need to set up its database, and often you need to incorporate changes to the code to accommodate business needs. Desktop applications and software that use old architecture often use this model.

Multi-tenant, on the other hand, describes a scenario where a single instance of the software serves multiple customers. Each customer uses the same software instance, shares the same resources and often the same database. The users of one customer represent a closed group, which is charged and handled as a single entity (tenant). Usually, the groups are members of different legal entities. Applications designed to serve multiple tenants with a single runtime instance are referred to as multi-tenant applications.

Multi-tenant applications seek to map the data set belonging to a particular tenant and to never expose data that does not belong to the tenant of the currently logged in user. This is achieved through data security and privacy restrictions.

Having multiple tenants allows you to deliver the service quickly without the need for additional software resources, database setup and code changes. The single-tenant vs multi-tenant choice becomes a no-brainer when you have multiple clients and similar functionality. The multi-tenancy drives down the costs of development and maintenance for all tenants in the long term and provides teams better control over the entire infrastructure.

Some of the benefits of using multi-tenant when choosing between single-tenant vs multi-tenant architecture include:

• Web access to commercial software
• An application managed from a central location
• An application that is delivered in a “one to many” model
• End users who are not required to handle software upgrades and patches
• Application Programming Interfaces (APIs) that allow for integration between different software and often between different vendors

Scaling Your Software with Multi-Tenancy

Building software that utilizes multi-tenancy principles inherently boasts better code reuse while retaining performance, security and scalability.

The most important aspect of multi-tenant architecture is how the data is organized in your application. This should be carefully considered when deciding which data model to use.

Multi-Tenancy Architecture Case Study

At MentorMate, we often leverage the power of the multi-tenant approach. It reduces costs to us and our clients. We designed and built our HR management system with multi-tenancy in mind. It was created to serve our company, and in the future other companies, to improve the hiring process.

Choosing a Multi-Tenant Data Model

The figure below shows three different database designs used for achieving multi-tenancy data architecture. Every approach has its own pros and cons.

Dedicated Database

This approach allocates a new database for every new tenant. Separating tenant data in different databases is the simplest way of achieving isolation. It will allow you to extend the database of your choice if your software logic also allows for it. This database design tends to lead to higher costs for hardware and maintenance. You need to consider that you are also limited by the number of databases that the server can support. This solution is good for clients that have strong requirements for data isolation and also when the number of clients is not too large.

In the case of our HR management software, we expected to have many tenants. Having extremely strict data isolation is not a requirement, and this particular approach would have meant higher costs for us and for our clients. Each of them would require a separate database, expensive in a cloud environment. The dedicated database data model would not have been the right approach in this scenario.

Dedicated Schema

This approach involves storing all tenants in a single database and separating every tenant by creating a different schema for its tables. In this way, each tenant will have its own set of tables within the same database. This database design keeps the hardware cost low by using the same database for all tenants.

Applying this data model to our HR management system would have required applying extra effort toward building a mechanism to switch between table schemas thereby increasing our development costs. We decided to not use the dedicated schema data model.

Shared Table

This approach involves storing all tenants’ data in the same database using the same schema for all tables. A special column is added to associate each record with its own tenant. Usually, that column is named TenantId and points to a specific tenant by using a foreign key. The hardware cost is still low, but you may need some additional development to ensure the tenant data is never accessed by another tenant.

Keeping our business needs in mind when building the HR management system, this approach was the best choice for us. Because we had one database where we were storing all tenants’ data, it kept infrastructure cost low.

We separated different tenants by using the TenantId column. We needed to ensure only data privacy, and we built a mechanism to provide the desired security level. This led to reduced development hours and infrastructure costs that perfectly fit our needs.

The only serious challenge that would arise due to our decision would be a drastic increase in tenants with lots of users and data. Then, access times would slow. Though, we have found clever ways to overcome this challenge. One tip is to use software like Elasticsearch to speed up certain operations.

How to Choose the Right Multi-Tenant Architecture Approach?

A few things can be considered when choosing the database model for your SaaS application.

Number of Tenants

If you expect to have hundreds or thousands of tenants, you will more likely want to reduce the hardware costs and to choose an approach like the shared table or the shared schema models. That was our case. We expected to have many tenants using our HR management tool, and that’s why we wanted a “more shared” solution.

Stored Data

If you expect your tenants or the majority of them to store a very large amount of data, you more likely will want to use a dedicated database model for your application.

Security Requirements

Some tenants like banks and others dealing with sensitive information would not even consider your application if you don’t provide them with a dedicated database and ensure the necessary security level to guarantee that their data will be safe.

Conclusion: Multi-Tenant Architecture

As we saw earlier, each of the three data models has its own pros and cons. You need to carefully consider the number of your tenants and their business needs when designing that important layer, the database. In some scenarios, choosing the right approach may not be as easy. If your application will store tenant-sensitive data, you will need a larger development effort to build the security strategy before it can be ready for production. Multi-tenant architecture gives to you the power and versatility to build your application with resource-sharing in mind.

Original post can be found here.

Innovate with us. Click here to access all of our free resources.
Authored by Martin Dimitrov.