Multi-tenancy in the Cloud: Architecture for the digital paradigm

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.

Tags: Cloud, Cloud Computing, Cloud services, Security, Technology