This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
If you're considering cloud-based unified communications (UC) services, sooner or later you're going to have to weigh the difference between multi-tenant vs. multi-instance architectures. At first glance you may wonder, "If it works, why should I care?" But this design question cuts to the core of fundamentally different approaches to delivering UC in the cloud, and has very important implications about the scalability of the platform and services it is supporting.
Within the unified communications community, vendors typically fall into both camps. The following is a brief review of the differences between these architectures focusing on some key issues to evaluate when looking at an architecture for delivering cloud UC services.
[ALSO:Unified communications buyers guide]
The concept behind the multi-instance approach is relatively straightforward. In a typical scenario, a server-based premises PBX is virtualized using VMware or similar technology in a data center. In this scenario, each customer or "tenant" receives their own VM. The VM environment is then wrapped with other services, such as PSTN access and billing and operational support systems (B/OSS), which are the tools that need to be included with a UC feature set to create a cloud service.
This approach tends to be advocated by premises-based PBX vendors and the reason is clear. They can take their existing premises solution and re-purpose them in the cloud. The real strength of this approach is that the premises-based feature set, which PBX vendors in particular have been developing for quite some time, can be quickly brought to bear in the cloud.
The multi-tenant approach differs from the multi-instance approach in that there is one instance of the platform that serves all of the customers simultaneously, across a shared infrastructure consisting of many VMs. Generally speaking, a UC vendor must develop their platform to be multi-tenant from the start. It's very difficult to take a single-tenant design and retrofit multi-tenancy after the fact. In a multi-tenant architecture, there isn't a reliance on VM boundaries separating customers. Instead, logical controls are utilized in the underlying code to separate the tenants.
So what are the key issues when looking multi-tenant architecture vs. a multi-instance architecture? Here are the top five:
* Scalability. Being able to serve many UC endpoints with the same amount of infrastructure is inherently going to lower costs for the end user. Multi-tenant architectures are inherently more scalable than multi-instance ones from a UC load perspective. It takes vastly less VMs to support a multi-tenant architecture than a multi-instance architecture, and the delta in the number of VMs grows as more and more tenants are added to the platform. By sharing the same infrastructure across all tenants, providers obtain load sharing efficiencies and avoid the overhead of running operating systems for all the tenants.
* Fault Tolerance. Unified communications is a business critical application making built-in fault tolerance a must have. Multi-tenant based platforms have built-in fault-tolerance that multi-instance platforms do not have. In a multi-tenant architecture, customers are served from clusters of nodes performing the same function. If a particular node goes down, the work will be handled by other nodes that are still up and operating normally. In the multi-instance architecture, the service provider must setup backup/failover VMs that have the correct tenant configuration on them. Further, the provider has to make sure that the configurations for these VMs stay up to date with the production VMs.
* Ease of Development and Management. Enterprises need to be able to not only add new features, they need to be able to easily test them and provision them. A multi-tenant platform is easier to develop and manage because there is only one code base and all of the tenants are on the same version at all times. Contrast this with the multi-instance architecture where potentially different tenants could be on different code versions. Keeping a single code base is essential to making sure service provider engineering effort and feature development stays productive and testing, provisioning, and troubleshooting can be handled efficiently.
* Ability to Integrate B/OSS. The importance of integrated B/OSS to create a scalable cloud UC platform cannot be stressed enough. It's much easier to implement B/OSS tools around a UC feature set if there is one instance of the software and a common version to integrate to. This is not to say a service provider can't create a B/OSS toolset for a multi-instance architecture, it's just much harder to do since all those VMs are potentially running different software code versions that will need to be managed. Software configuration data often resides in the VM itself, so data from the B/OSS to the VM instances and vice versa must be constantly synchronized for user initiated changes.
* Track record. Look around at a range of Software as a Service (SaaS) / cloud providers that have achieved some degree of business scale and ask yourself if they have a multi-tenant or multi-instance architecture. Most successful cloud services companies have multi-tenant platforms. An example is Salesforce.com. Do Salesforce.com customers receive a dedicated instance of Salesforce.com in a VM when they sign up? Not at all. Instead, Salesforce.com and many other operators understand that a multi-tenant architecture is the way to create a scalable cloud platform from which to deploy services.
Don't be surprised if the issue of multi-tenancy vs. multi-instance hasn't come up in your discussion with UCaaS vendors. But given the impact of the choice and the interest of analysts, it will likely become an important evaluation tool as UCaaS continues to grow in usage.
Derek Yoo is Chief Technology Officer at cloud communications service provider Thinking Phone Networks.
Read more about lans and routers in Network World's LANs & Routers section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.