Designing for the Cloud – Challenge #2 – Ease of Provisioning
In part three of our blog series on the 6 major challenges of designing contact center technology for the cloud, we focus on the challenge of making the provisioning of infrastructure easy.
SIP infrastructure for a cloud service provider is multi-faceted – with clusters of media servers, Session Border Controllers (SBCs), WebRTC gateways, etc. – and its key functionality is complex, making provisioning an often painful process. Consider that…
- the media servers (assuming a mature contact center stack) will provide full B2BUA functionality – end-to-end call management, network interworking, hiding of private addresses, etc. This means that clustering is a whole lot more complex than just running N+1 instances of the media server.
- each media server must be configured
- to accept bridging calls from other media servers in the cluster
- for calls entering and exiting the network, for all network edge devices/services
- each network edge service needs
- configuration for carriers
- dynamic configuration for WebRTC endpoints
- SIP infrastructure services also require uncontested access to resource, so VMs need to be pinned.
Sytel’s approach to provisioning is to utilise our own orchestration infrastructure, making it possible for service providers to grow their stack without this pain. This works with plain vanilla VMs, AMIs (Amazon Machine Images) or Microsoft Azure Windows VMs that have been prepared by automatically deploying and configuring both tenant application services and media services.
It allows service providers to, for example,
- increase the capacity of a media server cluster
- add new edge gateways without manual configuration
Tenant configuration, similarly, allows new tenants to be provisioned using either shared or exclusive estate, and without landlord administrators ever having to resort to using an operating system console.
A key benefit of doing your own orchestration is savings in the total cost of platform ownership, as:
- it has a smaller overall footprint, by avoiding the indirection overhead of standard orchestration tools and containers
- more importantly, it gives rise to load-based scheduling of media services.
Consider this example:
A service provider may have peak load of, say, 10,000 media server channels. In the Sytel stack, this equates to 11 media servers and 6 edge gateways in a redundant configuration. If these are run 24×7 (as in a typical infrastructure) you are paying for 17 dedicated VMs running full-time.
With Sytel’s provisioning model, servers can be brought online only when there is demand, meaning that for large parts of the day, only the minimum redundant configuration of 4 servers will be required.
This typically equates to a 60% reduction in compute cost over running the full capacity of the media services 24*7.