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.”
Source: https://blog.dialogic.com/blog/scaling-in-the-cloud
Publish Date: December 17, 2019 |
| 2.) |  CallGuard, ChatGuard, Securing payments for on-premise or remote agents for telephone, IVR, web, mobile, Chat and Chatbot. A patented technology that is flexible way to take secure, PCI DSS compliant payments via live agents over the telephone, web, Chat, Chatbot, or IVR. No sensitive data enters the contact centre environment so, agents do not see, hear, store or record any card or personal details. CallGuard can be deployed in various ways to fit the way your contact centre works. The solution can de-scope all, or parts, of your contact centre from the scope of PCI DSS compliance and works just as well for on-premise or home/remote working agents. ChatGuard makes payments in Chat PCI DSS compliant and... (read more)    |
| Scaling in the Cloud – Avoid Flying Too Close to the Sun | December 17, 2019 |
| SD-WAN’s Relationship with UCaaS | December 12, 2019 |
| Hearing and Seeing the Difference in UC Platforms | November 7, 2019 |
| Microservices Architecture – What is it, and why should I care? | October 31, 2019 |
| Panning for “Killer Apps” in the Gold Rush of 5G | February 14, 2019 |
| The Dialogic BUZZ UC Platform Swiss Army Knife | October 24, 2018 |
| DialogicONE - IoT Solutions | October 22, 2018 |
| Dialogic PowerMedia MRF – A Solution You Can Depend On | September 25, 2018 |
| Enabling WebRTC with the Dialogic PowerVille Load Balancer | July 16, 2018 |
| Telecom Meets Digital: The Importance of Establishing Controls | May 24, 2018 |
LOGIN WITH YOUR CONTACTCENTERWORLD.COM ACCOUNT
I am checking out all the amazing and daily updated content on ContactCenterWorld.com and networking with professionals worldwide
Send To Friends Post On My Wall