CI/CD In Telecom 5G (Part 1): What Is Telco CI/CD?

(This article is Part 1 of a three-part series on the impact of continuous integration and continuous deployment (CI/CD) on communications service providers and the telecommunications industry. "Part 1: What Is Telco CI/CD?" describes the framework as it applies specifically to communications service providers. "Part 2: Does CI/CD Impact Telco Operations?" addresses the operational impacts of CI/CD, and "Part 3: What Is The Telco CI/CD Journey?" outlines the path forward for operators embarking on this vital journey.)

Composable infrastructures have become essential to modern enterprises. This operational model also enables the sustainable implementation of information technology (IT) software, infrastructure, and security features into production safely and quickly. Generally referred to as 'continuous integration' and 'continuous deployment' (CI/CD), the automated development, delivery, and deployment of software using this framework is essential for the telecom industry's digital value chain.

The telecommunications industry now regards CI/CD as a critical step of a service provider's fifth-generation (5G) core deployment journey. The broad adoption of this framework by communications service providers (CSPs) is why I was so excited to have the opportunity to interview two of the most innovative voices on CI/CD in telecom.

Hemant Patil is the Consulting Manager for 5G, Cloud & Networks at Ericsson and leads the 5G Core (5GC) & Cloud Networks sub-practices, supporting CSP asset creation and industrialization within CSP network evolution strategy formulation. Gareth Price is a member of Ericsson Consulting's leadership team and a Cloud and Core transformation consulting specialist. He has led cloud and core strategy and transformation planning projects in Europe, Asia, and Latin America. I used my interview opportunity with Hemant and Gareth to validate some of the recommendations I offered in "Click to Transform."

Kevin: Gareth and Hemant, thank you for letting me discuss CI/CD in the telecom industry with you. Ericsson is a global leader in designing, manufacturing, and deploying 5G telecommunications hardware and systems. How does that relate to software and CI/CD? An industry observer may not see those topics as being connected.

Gareth: With 5G, the telecoms network takes on an important new role as the pervasive fabric for connected industry and society.  This role supports various devices, applications, and customers operating in a virtually isolated environment on the same physical network. Even more importantly, such this fabric must exhibit the robust resilience of critical national infrastructures.

For a network to robustly deliver agility, granularity is critical. This granularity defines the smallest part of the system that can be tailored and allocated to a customer or service while implementing the slightest possible network change. The cloud computing IT consumption model provides that granularity of hardware services. Cloud-native technology gives us the granularity of software. 5G architecture provides granular network tenancy, and CI/CD gives us granularity of change.

Telecoms CI/CD is about the automation of the telecom software lifecycle. We can add network capabilities much more often without making the engineering or operational support more complicated with automation. We can choose how much of the network to change, allowing us to gradually migrate to new software while reducing the risk of change. While the more frequent changes would appear to raise an outage's risk, operational research suggests the opposite is true. In complex interconnected systems, change complexity grows exponentially with the size of change. Smaller, frequent changes get more value to customers more quickly without the non-linear risk. However, the higher granularity of network software composition, higher frequency of update, and higher customization of network services increases the total test burden – that's where CI/CD is critical to 5G's success. The delivery of more customer value more quickly with fewer risks demands automation.

Kevin: With that as a starting point, what should be top of mind for CSPs when preparing for 5G Core integration and deployment?

Hemant: From experience so far, operators should consider some of the differences between deploying and operating a 5GC network versus previous network generations. The 5G Core deployment marks the introduction of two complementary IT architectures: cloud-native technology and service-based architectures. The benefits and features of this evolution include a:

• More significant software decomposition and a simplified software lifecycle;
• Greater agnosticism between applications and infrastructure paired with improved application resilience; and
• Broader use of automation and service delivery orchestration.

While all of these are welcomed, deploying cloud-native 5GC creates new network operational and management challenges for CSPs, requiring intentional operational transformation. Some implications resulting from these differences are:

• Increased frequency of updates to test infrastructure and test cases;
• Incremental delivery and deployment that also requires incremental security and operations;
• A cultural shift to the DevSecOps model that aims to bake security into the rapid-release cycles that are typical of modern CI/CD processes; and
• The deployment of cloud-native technology, microservices, and service-based architectures that drive increasingly higher levels of automation.

The largest consideration is that the 5G Core, the testing infrastructure, and the test cases will be changing continuously "during the implementation." In other words, if the plan is to deploy 5G core over six months, all the software will be incrementally evolving and maturing during that period. Traditionally operators have used a" waterfall" project management model that follows a deliver, deploy, test, validate, and freeze process until ready for "go-live." However, the reality is that with 5G Core, the testing infrastructure and use cases are updated every 3-4 weeks (or less). So the implementation project needs to be agile, with testing continuous and incremental. Freezes probably don't make sense in this model. This model is a very different way of working.

The second-largest consideration is how this change to incremental delivery and deployment maps to operations and security. This mapping is why it's essential to plan for DevSecOps; otherwise, software, digital configuration, and policy will "stack-up" unable to be released (made live) because it can't be released as quickly it can be deployed.

 (This article is sponsored by Ericsson Digital)