In Greek mythology, Icarus and Daedalus attempt to escape from the island of Crete by constructing wings that were held on using wax. Although Daedalus had warned Icarus not to fly too close to the sun, Icarus did not heed the warning, the wax melted, and Icarus perished. To be an "Icarus" or to "fly too close to the sun" is to fail or be destroyed because of lack of caution or excessive ambition.
For any service provider, moving out of the data center and into the cloud can bring an extensive return on investment – optimizing costs by only paying for what you use has saved some service providers thousands and thousands of dollars each year. If you were perhaps on the fence about the potential cloud return on investment, AWS makes it a point to advertise this savings-promised-land to users whenever possible:
As many in our space will contend, telecom resides in a niche and operates under a different set of (perhaps self-inflicted) rules compared to those web apps that are thriving in the cloud. Telecom apps were born in darkness and molded by the place known as ‘on-prem’ with no thought to the possibility of cloud computing. In contrast, the web apps of today were born in the cloud and built to limitlessly scale (a la web-scale).
Theory is fun and scaling real-time communications in theory is simple – components are generic and square Lego-like building blocks that can get scaled up vertically (adding more power to the engine) and/or horizontally (adding more engines to the pool cluster). Scaling ‘just’ happens with more resources being added when needed and removed when done.
Unfortunately, while simple in theory, the reality is not as simple. There are a lot of factors to be considered while scaling. The ‘real’ in real-time communications leaves very little room for error with its somewhat unpredictability. It’s a delicate balance of optimizing costs while expecting the unexpected, where usage spikes can leave customers without service.
Furthermore, there is the concept that not all scaling components are created equal – some components, and even functions of those components, need more resources to do their job. For example, the media server component is responsible for many functions, including conferencing, recording, transcoding, and playing IVR prompts – but each those functions scales very differently. The processing requirements for transcoding, for example, is much different than an IVR play.
While there are many considerations, but one final topic for discussion is the concept that scaling of components needs to be service-aware, meaning that components need to have some level of insight as to the type of instance on which they are running. For example, AWS advertises the most significant cost savings can be achieved using its Spot Instances. The adverse effect of using the spot instance type is that it can be taken-away/terminated with only a 2-minute notice. This is plenty of time if proper planning has been done to accommodate the resource being taken away, but perhaps not ideal for some real-time communication functions (i.e., recording). On the flip side, leveraging the disposability of spot instances could be to a solution’s advantage for scaling in. For example, if a conferencing service is using a mix of on-demand and spot instances, the routing algorithm can recognize and route based on the component’s instance type, simplifying a scale-in event.
Here’s the point – don’t be an “Icarus” when it comes to leaving the “island of Crete” (also known as the on-prem data center) for the cloud. Designing telecom real-time communication services that are cloud-scalable is hard and while optimizing costs is possible, it requires thought and not “flying too close to the sun.”
Publish Date: December 17, 2019 5:00 AM
|1.)||Call Center Studio|
Call Center Studio
Call Center Studio is the world’s first call center built on Google and is one of the most secure and stable systems with some of the industry’s best reporting. It is one of the most full-featured enterprise grade systems (with the most calling features, one of the best call distribution, outbound dialing features and integrations—including IVR, AI Speech Recognition, blended inbound/outbound calling and includes Google’s new Dialogflow and Speech API. Call Center Studio is the absolute easiest to use (with a 10 minute setup), and is the price performance leader with lower equipment cost and less setup time.
PH: +1 512-872-7565
Megacall provides a fully customised Virtual Switchboard software for all companies (including IVR service). No matter the size of your business, our services adapt to the needs of each client.
Are you looking for a more effective way to communicate with your customers? Discover the advantages of using the IVR and how it can help in your communications.
PH: +34 952 667 511
MightyCall's IVR that will increase your business’s efficiency at a fraction of the cost of a secretary. Your auto-attendant is designed to:
- Greet callers
- Deliver necessary information
- Forward calls to the appropriate extension
- Take human error out of the system
PH: +1 (888) 256-8312
|Scaling in the Cloud – Avoid Flying Too Close to the Sun||December 17, 2019 5:00 AM|
|SD-WAN’s Relationship with UCaaS||December 12, 2019 5:00 AM|
|Hearing and Seeing the Difference in UC Platforms||November 7, 2019 5:00 AM|
|Microservices Architecture – What is it, and why should I care?||October 31, 2019 5:00 AM|
|Panning for “Killer Apps” in the Gold Rush of 5G||February 14, 2019 5:00 AM|
|The Dialogic BUZZ UC Platform Swiss Army Knife||October 24, 2018 5:00 AM|
|DialogicONE - IoT Solutions||October 22, 2018 5:00 AM|
|Dialogic PowerMedia MRF – A Solution You Can Depend On||September 25, 2018 5:00 AM|
|Enabling WebRTC with the Dialogic PowerVille Load Balancer||July 16, 2018 5:00 AM|
|Telecom Meets Digital: The Importance of Establishing Controls||May 24, 2018 5:00 AM|