When Angelina Jolie plays in a feature, it’s reasonable to assume that she would be playing a close role to the meaningful relationship in the movie. In “Gone in Sixty Seconds”, Sara (Angelina Jolie) is the main star’s (“Memphis” Raines played by Nicolas Cage) girlfriend, however, Memphis’ closest relationship and most meaningful dialogs are not with Sara, but rather with Eleanor, a customized 1971 Ford Mustang Sportsroof. In the dramatic reunion between “Memphis” and “Eleanor”, he speaks to the car and touches it tenderly in the most romantic of moments.
Multi-tenancy is all about relationships, or more precisely, the lack of relationships between tenants. Multi-tenancy refers to an architecture where an application running on a server or designated hardware, serves multiple clients (tenants). Multi-tenant systems emerged hand-in-hand with the cloud rush. As more services move to the cloud and are offered as a hosted SaaS, multi-tenancy becomes more and more relevant.
Users are wary of a multi-tenant architecture due to one main reason – the fear that a single system serving a large number of organizations may present a viable security breach. That’s why multi-tenant applications are described by marketers with the following adverbs; separated, partitioned, segregated, non-bleeding, etc., implying that a user from one tenant can’t penetrate another tenant’s space served by the same application.
As the visualization trend grows, multi-instance architecture is being suggested as the ultimate remedy to the all multi-tenant architecture weaknesses. Multi-instance architecture is simple, adding a new instance of the application for each tenant/customer, eliminating the potential for any security breach. However, in life there are no free lunches and multi- instance modularity and elasticity come with a cost, some aspects of which can be listed here:
- Waste of Compute & Storage
- Multiple applications to manage
- High availability complexity
- Upgrades “One by One” instead of “One and Done”
- And more…
Tenant size in a multi-tenant architecture can vary and therefore the instance CPU, memory and interface allocations, should be optimized so as to not waste resources for small-sized tenants on the one hand and not to allocate too many instances for a single tenant/customer on the other. Multi-instance is like shopping in a mall with a bunch of $100 bills with no option to get back change. So when you buy a soda, you may lose $98. Similarly, it would be a great waste to allocate an instance with a capacity of 1,000 concurrent sessions to a small tenant for which 10 concurrent sessions are more than enough.
So how complicated is it to convert a single tenant system to a multi-tenant system? The “screwdriver fixer SW architect” intuitive reaction will be “piece of cake”. Let’s associate a “tenant ID” to all our internal and external tables and, hocus pocus, we have a multi-tenant system. This might work for some tenants who are not totally vertically separated. Tenants may have shared interfaces, for example, a multi-tenant SBC may have a number of tenants sharing a single interface or several interfaces of a SIP Trunk. The figure below shows a few of the possible use cases relevant for an SBC.
A multi-tenant system should be a fully scalable, “non-bleeding” partition per tenant running on a single shared physical entity. In should support per tenant configuration, monitoring, reporting, analytics, alarms and interfacing.
A real time system (e.g. SBC) should provide each tenant with optimal real time performance, as each session received by the system is classified and processed only through the tenant’s “orbit”.
Full flexibility should exist to move a tenant with its entire configuration between physical servers and physical locations, assuming extra server capacity is available on the site.
Multi-tenant options are many and should be chosen following a prudent analysis, otherwise, you may choose the most beautiful single instance and end up with bunch of tenants to foster.