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, 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.”