Real-time communications in the cloud: Separating myth from reality

You can learn a lot by studying mythology. Giants, trolls, vengeful gods and fire-breathing animals speak to the fact that the world can be a scary place sometimes. The same could be said about your data centre.

The fear of DDoS attacks, outages and integration issues have kept more than one CIO up at night. But myths are ultimately irrational and have no place in network decision-making.

Take real-time communications (RTC) for example. Instant and secure communications are a basic requirement for enterprises today – whether its real-time voice or video or instant messaging, moving these operations to the cloud is the clear next step to help power your business. An integral component of this virtualisation process is Session Board Controllers (SBCs), which provide security, signaling and media protocol interworking, routing, transcoding and a demarcation point for troubleshooting and service analytics.

Today, there are a lot of myths circulating around the risks and easy rewards of moving RTC into the cloud. In fact, you’re likely to encounter a bestiary of bad advice around RTC in the cloud that looks like something straight out of Bulfinch’s Mythology.

The Cloud-Optimised Kitsune

A tricky shapeshifter by nature, the Cloud-Optimised Kitsune will fox you into believing that you can easily shift RTC functions into the cloud by simply virtualising them. The reality is that virtualisation is not the same as cloud optimisation. Virtual network functions (VNFs) for a SBC need to be optimised specifically to handle load balancing, reliability, scaling, security and service orchestration for RTC in the cloud.

The Threat Kraken

Many fear moving RTC to the cloud will release a wave of monstrous security attacks. And while the need for cloud security isn’t a myth, the reality is RTC security threats are handily mitigated by SBCs, which are designed to be session-aware and implement security features like encryption or opening and closing IP ports that are needed to protect RTC applications - even in the cloud.

The Scalable Performance Unicorn

Often rumoured but rarely seen, the Scalable Performance Unicorn promises unlimited scalability to all cloud applications. For RTC applications, however, scalability hinges on the underlying SBC architecture rather than the cloud architecture. A truly scalable SBC architecture separates the signaling, media and transcoding VNFs and features a microservices architecture to better optimise each function.

The Inherently Redundant Cerberus

Much like the unicorn, the Inherently Redundant Cerberus is the legendary protector of the cloud’s high-availability claims. And while that may be the case for web-based data applications in the cloud, RTC applications require additional redundancy in the underlying SBC architecture to ensure high availability and reliability. Those requirements include unique considerations for low latency and stateful redundancy during failover, such as supporting gratuitous address resolution protocol (ARP) requests instead of floating IP addresses.

The Load Balancing Atlas

The Atlas is a mythical member of the cloud who can shoulder workloads of any weight with ease. In reality, most cloud providers use DNS-based load balancing or a SIP-aware, front-end load balancer to distribute the weight of their workloads evenly. Those methods alone don’t work as well for RTC applications, which require a stateful knowledge of sessions handled by the virtual SBC instances. Instead, an additional layer of load balancing is required that measures resource utilisation and can share that information across clusters of virtual SBC instances.

The Media Transcoding Siren

This siren will sing you a sweet song about the simplicity of media transcoding in the cloud, only to dash your hopes upon the rocks of reality when your transcoding requirements need to scale. Many vendors would have you believe the long-standing myth that scaling media transcoding is as simple as adding more CPUs to the job. But CPUs aren’t the fastest option, nor do they scale well for complex codec types.

GPUs (graphical processing units) are much better suited to media transcoding in the cloud. GPUs offer 4x better performance than CPUs for media transcoding, use less space (and draw less power) and can be parallelised for near-linear scalability.

The Multi-Vendor Hydra

Today’s cloud platforms are often a best-of-breed mix of hypervisors, virtual functions and applications, which can appear to be a multi-headed dragon, especially from the perspective of service orchestration. Fortunately, standard frameworks and open-source solutions for cloud interworking are very real, if still not completely mature. SBCs can mitigate the risk of the Multi-Vendor Hydra through diligent interoperability testing, broad support for industry standards and active partnerships with other leading vendors.

Seeing Is Believing

Despite the myths around RTC in the cloud, whether scary or seductive, the reality is that RTC in the cloud makes sense for most organisations. Both virtual and appliance-based SBCs have a big role to play in real-time, cloud-based communications, particularly around security, signaling interworking and transcoding.

As more telco operators and cloud service providers move to an NFV-based architecture, the ability to quickly deploy, manage and orchestrate SBC functions becomes a core requirement of the cloud.

Forty-six per cent of respondents plan to implement virtual edge gateways and firewalls in the next twelve months, according to the latest research from Heavy Reading, a research firm focused on telecom and network operation sectors. By extension, choosing an SBC that workswithin the idiosyncrasies of real-time cloud communications is equally important.

There are some who would tell you that the cloud-optimised SBC is itself a myth but reality proves otherwise.

Mykola Konrad, Vice President of Product Management and Marketing, Sonus

Image Credit: Chaiyapop Bhumiwat / Shutterstock