Proximus Implements Automation and Self-Service Load Balancing for Telco Cloud

Industry

Telco / Service Provider

Environment

Telco Cloud on Red Hat OpenStack and OpenShift

Problem

• Meet time to market considerations for infrastructure

• Want to eliminate proprietary appliances

• Operational complexity of “per-box configurations” for load balancing

Why Avi

• Central orchestration and automation

• Speed of deployment and rapid scale

• Powerful analytics and opportunity to deliver self-service

Results

• Ability to spin up new load balancers in 15 to 30 mins

• Time savings due to LB automation with integration with OpenStack

• Repeatable deployments with great API support

“One of the charming things about the Avi Controller-based architecture is that you define your config centrally and the instantiation happens in the backend and all the resources get managed automatically. It was of big interest to us.”

Dieter Pollet, Cloud Architect

“One of the obvious differences with Avi is the speed of deployment. If a customer comes and wants to have a load balancer, we have a controller ready that is integrated with OpenStack and can spin-up load balancing within fifteen minutes or half hour.”

Wouter Van Dyck, Cloud Architect

BACKGROUND

Proximus is the largest of Belgium’s three mobile telecommunications companies and is a part of the Proximus Group and delivers several Telco services including Pay-TV, landline, mobile, and broadband services. The Telco Cloud is Proximus’ preferred platform for hosting Telco services. The platform is a key building block for Proximus’ NFV (Network Function Virtualization) strategy and runs a scalable, virtualized IMS core on the Red Hat OpenStack Platform. Telco Cloud also includes container-based workloads implemented in the Red Hat OpenShift Container Platform.

Cloud Architects, Dieter Pollet and Wouter Van Dyck have been associated with Proximus for many years and lead DevOps efforts for the Telco Cloud environment with the design and deployment of scalable and automated local and global load balancing services.

CHALLENGES

The Telco Cloud project started with the intent to create a completely API-driven infrastructure. Initially, the team planned to use their appliance-based load balancing solution and issued an RFQ for everything except for DNS and Load Balancing due to time-to-market considerations. However, as they started to implement services in the virtual environment, they started seeing the limitations of the old way of delivering load balancing services. The concept of the Telco Cloud was built around eliminating the need for proprietary appliances and instead use commodity hardware. Dieter says, “The team wanted to do everything in software”, adding, “like physical appliances, the virtual editions of our current load balancer required ‘per-box’ configurations for each load balancer making it difficult to operate and automate in the Telco Cloud environment.”

SOLUTION – CLOUD-NATIVE LOAD BALANCING WITH VMWARE (AVI)

The Proximus team first met Avi Networks prior to the company’s acquisition by VMware at an industry tradeshow. With the goal to support a fully virtualized environment built on OpenStack, the team needed a load balancing solution that supported the cloud-native, DevOps operating model of Telco Cloud. The API-based infrastructure with a virtualized IMS core and EPC (4G packet core) needed scalable load balancing services. A portion of the applications on the OpenStack platform were also architected as microservices apps and were deployed on the Red Hat OpenShift Container Platform. Since they were dealing with Telco applications with direct customer access, the team was bound by high availability and uptime requirements. Wouter says “Service interruptions due to upgrades or other reasons outside of our twice-a-year maintenance window were simply not allowed.”

The Proximus’ team’s conversations with Avi led to an extensive POC. The team specifically tested Avi’s capabilities OpenShift as well as the ECMP scale out capabilities of the Avi platform. Dieter says, “Two key observations from the PoC convinced us that Avi was the right option. On the one hand, it was cloud-native and flexible to deploy. Secondly, we received really good support and feedback from the Avi engineers.”

With Avi, the fact that the load balancers could scale out both horizontally and vertically made a big difference for the team. Dieter adds, “this would have been more top heavy and harder to do with our previous load balancer.”

CENTRAL ORCHESTRATION:

Unlike the challenge of managing individual instances of the load balancers Dieter says, “One of the charming things about the Avi Controller-based architecture is that you define your config centrally and the instantiation happens in the backend and all the resources get managed automatically. It was of big interest to us.”

SPEED OF DEPLOYMENT AND SCALE

With the DevOps environment of Telco Cloud, the speed of standing up the infrastructure for applications was an important consideration. Wouter describes Avi’s capabilities saying, “One of the obvious differences with Avi is the speed of deployment. If a customer comes and wants to have a load balancer, we have a controller ready that is integrated with OpenStack and can spin-up load balancing within fifteen minutes or half hour. The integration and automation with OpenStack save us a lot of time. In addition, the good API model of the platform allow us to do Ansible scripting to deploy repeatably in different environments. This is something that the appliance vendors did not have, and it was a game changer.”

ANALYTICS AND SELF-SERVICE

“With Avi, we were able to give read-only access to the powerful logs and analytics to our internal customers,” says Dieter. He describes how the self-service capabilities in the platform enabled app owners to quickly identify whether the challenge was with the network or application. With the visibility provided by the platform, they could get answers for themselves in just a few mins without sending email requests or submitting a trouble ticket. The alternative with their previous load balancer would have required sending the syslog to an external system to analyze the data. TCP dumps were a last resort due to the production environment and because one couldn’t look at historical data with TCP dumps.

NEXT STEPS

As a best practice for load balancing, Wouter and Dieter are strong believers in considering orchestration right from the beginning. They also note that often each application is unique and one-size-fits-all approach to load balancing isn’t the best approach. In the Proximus Telco Cloud environment there is a lot of interest in hybrid cloud and in the next couple of years, certain workloads and apps will be migrated to public cloud.