As part of our presales engagements to deliver cloud-based contact center services (CCaaS), we are often asked ‘Does your architecture support containers?‘ or ‘Do you work with Docker?‘
Now, we all know the customer is always right and the expected answer is ‘Heck Yes!‘ but frankly, we try to avoid containers like the plague. Here’s why:
Containers provide a lightweight OS framework to host a service and provide an indirection layer to map communications and other IO. This makes them really useful for rapid development of microservices. They do, however, have some significant disadvantages for real-life deployment of a heavyweight ACD with all its applications and media processing infrastructure.
These disadvantages aren’t obvious but are particularly relevant to cloud contact centers:
1. Encouraging sloppy programming
When our development team at Sytel writes new services we are forced to consider how something should multiplex, whether and where to keep state information and how the APIs to it are presented.
Containers ‘free’ you from this discipline which encourages sloppy behaviour, leading to unmaintainable code.
2. Vendor lock-In
If you work with containers you will also likely have to work with the orchestration infrastructure that a specific cloud provider gives you, and you will have to integrate with it in order to make sure real-time components multiplex in the right way.
This ties your fortunes to those of a specific cloud infrastructure provider. Now you might say that AWS or Azure is a safe bet now. What happens when pricing models change, or when a new disruptive provider emerges? The only thing that is certain in our industry is change.
Therefore, our approach has been to produce our own orchestration model and enforce API and service design patterns that allow services to be multiplexed on one host or on many. We can deploy our model to any of the major public cloud providers and can scale up and down, but without being tied to the provider’s toolset.
3. Performance
Containers and a general microservice design allow developers to abdicate responsibility for performant code.
As well as this, the total compute cost of all the indirection delivered by the container when hosting a service is significantly higher than the cost of properly designed services hosted on a standard VM.
These costs will be hidden in the per-user subscription fees for a cloud contact center service or in calling rate costs, but they will be there.
So, we write our own tight, efficient code to meet the challenges inherent in a cloud architecture. It is best for our solution, and best for our partners and customers. If you disagree, we’d love to hear from you.
Postscript
We recognise that the situation, like everything in IT, is constantly evolving. So don’t rule out the possibility that, at some point in the future, we will write a blog saying “We embrace containers!”
