What is cloud-native automation and why is it important for telcos?

Automation. It’s not something most of us think about often, and that’s the whole idea. But automation plays a critical role in the IT world, especially for those who remember when software had to be updated manually.

That importance takes on an added urgency when you consider next-generation telecommunications networks, as a cloud architecture brings with it layers of complexity that make automation a necessity. Telecommunications networks require much higher levels of reliability—known as five nines for the 99.999% uptime expected of them. Automation helps eliminate human errors that can cause outages while allowing for more frequent software updates to occur.

The real-time communications in a telco network also generate a lot of data—several orders of magnitude more than most applications. It’s not just a case of more data, though, but a case of more things generating that data. Where a traditional telco network may have several distinct elements—e.g., a session border controller, core routing engine, and call server—a cloud-native network will often divide those three elements into hundreds of containers. For larger cloud networks, microservices-based network functions may be stored in tens of thousands of pods or containers. Asking a human being (or even a team of human beings) to manage all those pods and containers is a recipe for disaster.

What is the impact on network manageability in a cloud architecture

To be clear, I’m not suggesting that the cloud is the villain here. There are so many ways that the cloud improves telecommunications, from ensuring higher availability to lowering costs. But it’s a very different way of doing things than in the past. Ten years ago, many telco operators were still using physical network appliances that were managed individually as standalone devices. If your session border controller was acting up, someone on the IT team could walk over to it and give it a good boost or a solid push. As telcos moved to virtualized environments, a lot of that functionality moved to the software layer, but you still had that standardized server to work around. With containers and Kubernetes, there’s nothing physical to fix. They’re abstract rather than physical entities, which has its upside and downside: there is no physical device to fail, but you now have data coming from thousands of different places.

The benefits of cloud-native network automation

A cloud-native automation platform can aggregate and analyze vast amounts of data to help telco network administrators troubleshoot, fix, and optimize their networks. Instead of having to sift through stacks of spreadsheets, network analysts receive targeted alerts through automation tools that provide actionable data and, in many cases, can resolve the issue without human intervention before a problem even occurs. And that’s not all automation can do. By providing more visibility into the telco network at a granular level, cloud-native automation can help telcos optimize their networks for high performance/availability and even suggest new services that can be created based on user patterns.

With cloud-native automation, operators have more control over changes because they can direct APIs to the container level. This provides an almost-surgical precision to the updates which can be made in the network. If a pod goes down, Kubernetes can simply spin up another pod. If workload demand increases, Kubernetes can spin up more pods automatically. And all of this Kubernetes activity can be managed and orchestrated by Helm for additional automation and efficiency. This new efficiency also allows telco operators to update and improve their services faster and more frequently, which supports the continuous integration/continuous delivery (CI/CD) approach that has become synonymous with operational agility.

What to look for in a cloud-native automation solution

Up to this point in the blog, I’ve presented automation as a universal good, but the fact is there are different kinds of automation and not all of them are equally good, particularly when talking about telco clouds. For example, automation that treats only a subset of the network provides limited value because you end up having to manage multiple automation tools that deliver a smaller part of the big picture. Also, automation tools that don’t integrate with legacy network equipment (e.g., physical appliances, VNFs) have limited benefits because they only apply to part of the network.

What you really want in an automation tool is expansive reach that unifies network observability and can “connect the dots” when it comes to troubleshooting and service orchestration. With virtualization, network elements became increasingly abstracted, resulting in abstracted reporting and alerting data. This abstraction makes it much harder for human beings to pinpoint specific issues; for example, a problem that manifests in one network element such as a session border controller may actually have its source in another element such as a call server. With a cloud-native architecture, problems can now be identified at the pod or container level, making it easier to find and fix problems in the network without impacting other network operations.

Is your automation solution truly cloud-native?

In a previous blog, we talked about cloud-washing: the false claim of cloud-native solutions that really aren’t. Automation, it turns out, is just as susceptible to cloud-washing as other technologies. To help you spot the difference, here are a few things to look out for:

• A cloud-native solution will support declarative automation (i.e., automating cloud resources based on a declared network state or condition), while a cloud-washed solution will not
• A cloud-native solution will support the Helm charts that are so instrumental to running Kubernetes clusters, while a cloud-washed solution will not
• In a cloud-washed solution, the API support may be missing important interfaces to applications such  as Ansible Tower and GitHub or DevOps systems which will be found in a cloud-native solution

At Ribbon, we built our automation solutions around a cloud-native architecture from day one because we knew that’s where the future was headed. But you don’t need a cloud-native network to benefit from our automation solutions. We have customers that use our automation tools to manage virtualized networks and physical appliances. When those customers move to a cloud architecture, the transition for them will be completely seamless.

Automation can benefit your network wherever you are in your cloud journey. It’s important, however, to choose an automation solution that understands how your network operates. To that end, we developed a tool known as LEAP (Learning-Enabled Automation Program) that provides an AI-powered call flow detection, test generator, test executor, and test auditor through an automation platform. With LEAP, we can ensure that your network automation is built on dynamic data set collection from the actual network and live traffic, versus a static test suite of how you imagine you network runs (or ran years ago).

So, now that you know more about cloud-native network automation, the choice is yours. You can keep managing your network using a manual approach, or you can hand that work off to a cloud-native automation solution and boost your productivity.