Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Five issues to examine when considering cloud-based UC

Derek Yoo, CTO, Thinking Phone Networks | Aug. 20, 2013
There are different approaches to delivering UC in the cloud which has very important implications about the scalability of the platform and services it is supporting.

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.

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.


1  2  Next Page 

Sign up for Computerworld eNewsletters.