How to Create Scalable and Configurable Multi-Tenancy Applications

“Instead of 10 copies of the OS, 10 copies of the DB, and 10 copies of the app, it has 1 OS, 1 DB and 1 app on the server.” – CNCCookbook CEO, Bob Warfield on Multi-Tenancy.

What, you may ask, is a multi-tenancy application? A software application with the host software serving different tenants on a ‘single instance’. Single instance? A term for software that uses same code base, infrastructure and central updating capabilities. Multi-tenancy is not be confused with multi-enterprise and multi-users.

Be it a PaaS or SaaS environment, a multi-tenancy application’s scaling and configuration is architecture-dependent. An effective architectural style will help you save on administrative, maintenance and development expenses. Here are three varied SaaS database architecture solutions you can go for, as per requirements:  1. Saving tenant data in different databases is one way to go about it. This database architecture is best used when each tenant requires more leverage to scale. See self-explanatory image below:

1. Saving tenant data in different databases is one way to go about it. This database architecture is best used when each tenant requires more leverage to scale. See self-explanatory image below:
2. Multiple tenants are made part of one database, with a set of tables specifically assigned to each tenant, along with a distinctively created schema:
3. List the same set of tables in a single database. This architecture model is best used in large-scale document records and statistics. Multiple tenant data can thus be systemically, numerically arranged and retrieved:

Multi-tenant software can thus integrate with huge data centers and save costs on software setup and maintenance. Multi-tenant architecture has found a preference in certain fields in comparison to single-tenant architecture. Read more about multi-tenant architecture here.

Cloud Computing & Microservices

“Secure multi-tenancy is the key to utility computing, and now we can scale more securely.”   – Aisling MacRunnels CMO, JIVE Software.

1. Comprehending multi-tenancy is been seen as the first step to more customers going for cloud computing. With instantly available resources, easy accessibility to multiple resources to scalability options, cloud computing’s main asset is cost-saving. Unlike hardware arrangements, you only pay for specific usage. You may discard or add an element to the setup, anytime you like. The expenses are accordingly adjusted. Contrary to popular perception, small-time companies can afford cloud computing too. Read more about multi-tenancy and Cloud here.
2. Microservices concern breaking up larger projects into smaller independent modules, then having the modules perform highly defined tasks. Working with other modules using universally accessible APIs; microservices are finally an architectural solution; a handy solution when scaling any particular feature in a multi-tenancy application.

Multi-Tenant Applications: Scenarios & Solutions

Scenario 1: A cloud computing platform offers AWS to its clients along with a visual interface to scale and automate your respective application environments.

Solution 1: The cloud service provider allows the potential user to download a cloud management dashboard, enabling the tenant to use AWS and avail its services. Thanks to the architecture and algorithms, you are allowed to scale your multi-tenant application (architecture displayed above) as and when the requirement arises.  Microservices play a key part in the services too. One microservice performs a weekly process of fetching all public images from the cloud provider.

Identifying that a machine image is a newer version of an existing Amazon Machine Image (AMI) is a prime function it performs. Another microservice, the performs an hourly task of gathering statistics of each running AWS service. This allows data generation as to overloading/under-utilization of any service. The cloud service provider also curtails your expenditure, saving the user big time on costs.

Scenario 2: Regions and districts had exponential data, clients were not comfortable to have their data stored at a remote location.

Solution 2: Due to client concerns, the first iteration of the Database Architecture was modified. In the second iteration, a Master Database was used to store pointers for Tenant Databases. It was also used to store the Tenant Database location via IP address/URL. The architecture illustrated above made connecting client-side database servers easier. It also became easier to separate and migrate exponentially growing databases onto dedicated Amazon RDS instances. It was also easier to have shared database servers to host multiple limited-data entities. The architecture ensured that the Database Server location could be provisioned based on the client entity geolocation. Scaling database instances on demand was thus much easier for us.

So apart its merits of ensuring sustainable and efficient scalability, moving to a multi-tenancy architecture is critical for any software company. Would you agree?