THE BUSINESS-USERS GUIDE TO MULTITENANCY
Imagine a skyscraper, with the landlord having a master key. Within this skyscraper, the landlord is able to build as many units as they please, to be occupied by their tenants – each with their own unique lock. These tenants know only of their own unit, and are unaware of the other units, or what contents are stored within. Externally, each unit may look the same, but within, a new light fixture, a shag carpet, an island with a built-in sink – you get the picture. By now you’re likely wondering, “How does this relate to software”? Imagine the landlord is a solution provider and the units within the skyscraper are occupied by miscellaneous customers – i.e. tenants. Each tenant is given a unique, custom experience, with interactive, tailored dashboards, and their own database, but the solution provider hosts only one copy of the software. The solution provider has a client-facing analytics portal where each tenant is given access to their data (or a key to their unit), and theirs alone. This is multitenancy. Customers employing a multitenancy deployment scenario are able to easily create and manage their clients, who are separate from one another.
Multitenancy requires both a literal change to the application’s architecture, as well as a figurative change in the assumptions a data architect must make, when typically accustomed to single-tenancy solutions. This change results in a software structure that has the potential to maximize resource usage amongst tenants, and is capable of separating and differentiating unique tenant’s data. multitenancy deployment scenarios allow the solution provider the ability to easily manage and create tenants that are isolated from each other under a single deployment. Access to the solution is controlled by the provider for each individual customer. Each tenant is logically disconnected and isolated from one another, however they are physically integrated within the same application.
Most often, a multitenancy feature is utilized by a Software-as-a-Service (SaaS) provider who wishes to enhance their existing software’s BI and analytics capabilities via integration (such as with Dundas BI). This integration would allow the provider to offer their tenants an interactive and tailored experience – separate from each other. It’s important that multitenancy instances are relied upon if the application deployment is executed for external users whose existence should remain hidden from other users of the same system.
HOW CAN A MULTITENANT SOLUTION BE LUCRATIVE?
There are numerous benefits of hosting a multitenant solution. First and foremost, end-users are limited to the number of objects (dashboards, metric sets, data cubes, etc.) that their tenant is allowed to see. Any and all objects created by an end-user will not be visible to users of other tenants, resulting in complete separation and isolation. This is an important feature as it ensures greater security, despite tenants sharing the same instance. While on the topic of data security, multitenancy deployments allow the solution provider the option to use dynamic data connections by overriding them based on the tenant login, as well as the option to use custom attributes to filter data by the user/tenant.
In addition to this, multitenant instances offer preeminent commercial alignment and licensing control. This aspect is vital, as solution providers are able to match their different tenant’s license needs more specifically. Providers can ensure licenses are not shared by all tenants, but explicitly by those who purchased the license. The provider is able to monetize their analytics solution by selling the specific licenses to their tenants.
Another by-product of multitenancy deployment is the impressive reduction to maintenance. Seeing as the upgrades and conservation to one instance can be applied to all tenants, the overall cost of the solution should be lower, resulting in improved attractiveness of the solution for providers targeting customers smaller than enterprise-size.
However, hosting a multitenant solution is not a one-way street. From a tenant’s perspective, there are expectations the application must meet in order to be successful. A multitenant application should be available, scalable and elastic. Regardless of the number of total tenants using the solution, the presence and mobility of other tenants must not affect availability of the solution. Furthermore, a multitenant application’s value increases if it’s scalable. The ability to add and remove resources, as well as the ability to scale individual components, is highly advantageous. Elasticity is particularly important as it is becomes increasingly difficult to predict levels of resource demand amongst tenants in a multitenant application vs. demand in a single-tenant application.
multitenant applications are not new – when you think about it, some of the most popular web-services are using a multitenancy architecture. Salesforce CRM is a real-world example of this type of solution. What’s important to take away, is that these such applications have been able to maximize their resource sharing amongst users. multitenancy is not a complex concept, and if properly utilized, can offer tremendous performance and greater efficiency.