In an earlier blog in our ongoing Designing for the Cloud series, we touched on how having your own orchestration model enables you to manage footprint cost by only running as many costly VMs for media processing as you absolutely need.
A cloud-based contact center running the full range of services has many other components that generate large compute and storage demands.
So how does one manage these to minimise footprint cost?
The answer, as ever with Sytel, is software design. Here are our thoughts on the three big costs other than media processing:
-
Audit logging
All services need to generate logging for problem tracing and resolution. The overwhelming majority of cases handled by Sytel’s support team involve diagnosing operational problems caused by external factors, e.g.
- network and carrier issues
- ‘unintended consequences’ of ACD configuration
- outbound inventory management
Without logging across all services, we would not be able to make quick diagnosis of such problems.
The easy thing to do is to dump all this information to a file local to the service. This then creates local storage demand; far better to use a standards-based protocol for logging and have just one VM on the server stack require lots of local storage. This saves some cloud cost.
Having the logging service able to abstract away storage and perform buffering and write optimisation then enables bulk storage solutions such as Amazon S3 storage to be used in a cost-effective manner. This saves a lot more than just concentrating file i/o on one host.
-
Database
Database services are a big part of the cost equation when deploying a functionally rich contact center. Frankly it doesn’t make a great deal of difference whether you use relational databases or NoSQL storage engines – the database engine is going to use lots of memory, disk, and CPU and this will have to be paid for one way or another.
What you can do is minimise the load and number of services within your architecture that communicate directly with database services. A mature cloud platform implements database proxying so that only a handful of services communicate with the database directly, implementing caching so that multiple services do not end up reading the same data, and pipelining writes to minimise contention and maximise throughput.
-
Elastic compute vs pinned resources
Call centers operate in real-time with media servers handling streaming, the ACD making many decisions every second and applications managing the customer, agent and robot dialog. The easiest thing to do is to run everything in a cloud contact center using dedicated resources, so that everything just works. Well, this comes at a cost. A far better approach is to have your core APIs work asynchronously and deal with timeouts by design. This enables most of the contact center application to operate in near-real-time rather than real-time.
Consider an outbound dialer call. This may need to be screened at the point of launch against national and local do-not-call lists, conform to footprint compliance rules and possibly business-specific checks. By having an asynchronous routing API this allows all these services to run using elastic compute resources.
This is just one example; by extending this philosophy to the entirety of the core platform API it is possible to run all line-of-business services using on-demand compute resources rather than ‘always on’ resources.