Before you go native in the cloud world, there are a few things you should know

The “cloud native” conversation is transitioning from the enterprise data center into the telecommunications world, just in time for a new generation of 5G and AI/ML enabled telecom services. Couched in that conversation are some important nuances about what constitutes a truly cloud-native solution versus a cloud-capable solution. For example, today’s virtualized network functions (VNFs) are capable of being deployed in the cloud, but that doesn’t equate to bringing the full advantages of cloud-native technologies to the customer, such as Kubernetes, microservices, infrastructure as code, and automation. While this may appear just a matter of semantics, in reality the distinction between cloud-capable and cloud-native can spell the difference between success and failure of network transformation initiatives for both enterprises and communications service providers (CSPs).

Let’s take a closer look at what it really means to be cloud native. As I mentioned, at a high level, a cloud-native solution is one that has been specifically architected around cloud technologies such as microservices, containers, Kubernetes, and infrastructure as code. In the case of voice communications, where reliability and real-time transport are critical, there are additional considerations for cloud-native solutions: relocating call state; decoupling signaling and media to scale and manage these independently; providing observability across microservices; and more. Each of these considerations needs to be factored in when re-imagining a physical appliance or VNF into a cloud-native function (CNF) for voice services.

Cloud Native SBC Datasheet

The five key design attributes of a cloud-native solution

Not all network equipment vendors define “cloud native” in exactly the same way. Fortunately, there is some commonality around how cloud technologies like microservices and Kubernetes apply, and this allows CSPs and enterprises to re-use the same cloud skills and tools across a wide variety of CNFs regardless of vendor. Beyond that, we believe that there are five key design attributes that constitute a truly cloud-native solution:

Microservices

The earlier shift from physical appliances to VNFs decoupled the hardware and software, making it possible to scale network elements more efficiently using common-off-the-shelf (COTS) servers and to manage those elements using a single hypervisor. With the shift from VNF to CNF, a further decoupling takes place at the software level. For example, in the case of a session border controller (SBC), services such as signaling, media, and routing would all be decoupled and placed in containers and pods to act as self-standing microservices.

There are several advantages to running network functions as microservices:

• They’re easily re-usable. Once a microservice is created, it can be shared via an API regardless of the underlying programming language.
• You can scale them independently. If more signaling capacity is needed, for example, you can increase the number of signaling pods/containers without needing to scale other services in tandem.
• They minimize disruption. Microservices reduce the “blast radius” when components fail because only the microservice is impacted rather than all network function services.

Statelessness

The majority of applications are stateful. Web browsing, for example, records state in order to return to previous pages. Voice communications are also highly stateful. In a cloud-native environment, however, active entities should be stateless so that the application can be moved seamlessly to another resource in the event of a hardware or software failure. Therefore, voice communications applications require the removal of state from the microservice and relocation to a separate entity such as an in-memory database. This not only ensures real-time session continuity in the event of a container or pod failure but also enables the horizontal scaling of real-time applications to meet changing demands.

Infrastructure as Code

A container orchestration platform such as Kubernetes allows IT teams to manage and configure their cloud infrastructure by using machine-readable code instead of manually provisioning and configuring each server or VNF. The result is network infrastructure that can be written, reviewed, and version controlled using well established procedures for a Software Development Life Cycle (SDLC). For example, you could automatically update any portion of the infrastructure—say, for a security update—with reduced risk of impacting other parts of the infrastructure. It enables IT teams to take a DevOps approach to deploying real-time applications such as voice services.

Observability

Historically, in the “service from a box” world, network observability followed a straightforward paradigm. You had a box that generated logs and performance metrics at regular intervals, which you could consult and review the logs and metrics to detect problems or monitor performance. In the cloud-native world, the box has now disappeared, and logs and metrics are tagged to a specific microservice. Furthermore, the components of the microservice are now dynamic and can appear, disappear, or be replaced as necessary based on faults or capacity requirements. This both means more granular data to collect and more complexity in terms of managing it, but it also presents an opportunity in terms of the kinds of real-time insights that can be gleaned from this additional information—for example, detailed insights into the microservices that can be used to create new services or make existing services more efficient at lower cost.

Automation

With microservices, you’re multiplying the number of “things” you need to manage. Naturally, there are human limitations to how many microservices you can manage with manual processes, which brings us to automation. Through automation, network operators can provision, configure, update, and scale in/out potentially millions of microservices components—dramatically cutting down on operational costs—while largely eliminating human error from the equation.

In Conclusion

Although cloud native is just now reaching telecommunications, it has been tested and hardened in the enterprise and web-scale world for years. And, even in the telecommunications industry, underlying cloud-native concepts such as service decoupling have been in use for years. Ribbon, for example, first decoupled the media, signaling, and routing services in its SBCs more than a decade ago. Today, we continue to advance the leading edge with the industry’s only fully cloud-native SBC and our “drop-in” cloud-native IMS core for voice services.

In the next few blogs, we’ll take a closer look at what cloud native means in terms of real-time voice services and how cloud-native solutions improve network observability, scalability, reliability, and manageability.