Multi-tenancy in the Cloud: Architecture for the Digital Paradigm
  • Blog
  • Technology

Multi-tenancy in the Cloud: Architecture for the Digital Paradigm

Yashasvi Raykar

It’s a SaaS world today. Most of the traditional software development involved the installation of separate software product instances for each of the customers. Software providers would install the software packages developed (or configured) for specific clients. Over the last few years, the world has started shifting from in-house infrastructure to cloud-based solutions. Software products have since started becoming what the industry calls “Multi-Tenant Applications”.
Multi-Tenancy is a way of architecting and developing software products with one source code base, one server instance, etc. Multi-Tenancy is achieved using the various frameworks, and concepts like convention over configuration, AOP based programming etc. Typically, any application developed with aspects of multi-tenancy can also be deployed on-premise or on collocated servers.
In this blog, we discuss the various architectural options for Multi-tenancy and the key considerations for choosing one over the other

When data segregation is key
Multi-tenancy applications are developed with a single instance of code and a single instance of a database when segregation of data is critical.
We can take the bill payment application of a financial services provider as an example. A Bill Payment use case with multiple third-party services for payment gateway interactions is shown below. The application interface abstracted through the business-driven design and domain-specific language that it could make use of any specific interfaces like bill desk, visa, etc. depending on the choice made by the tenant. This is segregated based on the tenant key. The technical customization in terms of themes, color combination etc. are also made based on the tenant key being shared.
This type of architecture makes implementing new features very easy as large logic changes can be ring-fenced within the specific component and hence there is less maintenance.

When ease of licencing is key
Single Database type of multi-tenant architecture is preferred when the customer is ok to keep the data outside the premises and data security is not a major concern. However, the license and maintenance cost needs to be minimal.
A single database is created, and all data is stored here. Each record is assigned a tenant key, and only data belonging to that tenant is accessible. Access is restricted by the application software.

The single database instance approach has low cost since the cost of maintenance is not transferred to the tenant. This model gives the benefit to the tenant to bring up / shut down the application with various licensing modules.
Data consistency, integrity and availability is provided by the company developing the application and the Cloud-based infrastructure makes the sizing and scaling easier.

When Security is Key
Multiple Databases – Alternatively, a separate database can be used to store each customer’s data. Access to the database is then restricted by using SQL login credentials.

The multiple databases approach used again uses the same tenant key however the tenant itself will be only one in the system. In very specific cases with very high data security applications or to meet the tenant expectations the multiple database approach could be used but with a single code instance.
The multiple database instance approach provides complete data integrity and segregation of the tenant data. Customization is easier as each tenant uses a different database instance.

In Summary
The modern-day products specifically serving multiple tenants are developed typically considering the multi-tenant architecture. There are two areas where the decision path fork out entirely depends on the security of data over licensing. The various deployment architecture is considered. The key point which is central to this is tenant data.
The configurations and the deployment of the application are typically done using the automated testing and the deployment mechanisms.
A case in point:

We recently developed two applications, one for a mortgage boutique shop and another alternate financial service provider on their endeavour of building a product for their end clients. The usage of the multi-tenant application was such an essential part of the exercise in high-level design that the various UI, product line and other services were customized to its fullest possible extent using the multi-tenant architecture.
We went through the above decision-making process with the client, worked with client’s business teams to understand what were the Key considerations – Security, Licensing or data segregation. When Security considerations won, we designed and built the product with multiple database architecture.

Let us help you design and build with a multi-tenant architecture

Related Articles

January 14th, 2021

Build Your Future on Cloud

by Opteamix Read more

December 16th, 2020

Migrate to Cloud – It’s About Time!

by Kishore Naidu Read more

November 30th, 2020

Rise Above With The Cloud

by Opteamix Read more

October 20th, 2020

Infrastructure as code – What and Why?

by Kishore Naidu Read more

Freshest Articles

February 24th, 2021

The Need for Quality Engineering

by Arun AlagappaRead more

February 23rd, 2021

Reshape Your Technology Landscape with Quality Engineering

by OpteamixRead more

February 19th, 2021

RPA and AI: How do They Work Together

by Ryan SpurlockRead more

Engage Deeper

Opteamix is a digital automation technology consulting firm with deep expertise in Application Development, Robotic Process Automation, AI, DevOps, Enterprise Mobility, and Test Automation Services. We are headquartered in Denver, Colorado with a wholly-owned delivery center in Bangalore, India.