CI/CD in telecom 5G part 2: Does CI/CD impact telecom operations?
Kevin: It would seem that such a drastic evolution would have a significant impact on network operations. How does continuous software delivery and deployment affect the network operator's relationship with their software suppliers and vendors?
Hemant: In the standard microservice code model that underpins cloud-native software, every time a common code software component is improved, it will change all network systems that use that standard code. This approach can bring lightning-fast agility and innovation but leaves today's legacy bi-annual software test and validate processes entirely unfit for purpose. The CI/CD philosophy means that software is developed, delivered, tested, accepted, and brought into operation incrementally at a far higher cadence than previously in a traditional service provider environment. Further, it creates a significant software development volume that needs validation on an increasingly dynamic network. This approach implies that continuous software validation and continuous testing must accompany continuous software delivery and deployment. These requirements demand a new agile way of working between the network operator, its software suppliers, and vendors. Essentially, the merging of Dev and Ops as in the IT world is now a must for the telecom context where the 'Dev' from vendors needs to seamlessly merge and receive feedback from the 'Ops' on the operator side of the firewall. This evolution requires a transformation on both the vendor side as well as the operator side.
The telecom CI/CD philosophy means that software is developed, delivered, tested, accepted and brought into operation incrementally at a far higher cadence than previously in a traditional service provider environment. Further, it creates a significant software development volume that needs validation on an increasingly dynamic network.
- Hemant Patil is the Consulting Manager for 5G, Cloud & Networks
Vendors will have to move to a newer customer engagement model coalescing between commercial, technology, and software delivery operations. For their part, operators will need to adopt a well-defined test and accept strategy to govern the people & process, enabling the continuous software deployment and validation.
Kevin: What about network security? How does the operator ensure data is secure in a continuously changing environment?
Gareth: As mentioned in our first article, transparent digital configuration and policy, the automation of security testing, and smaller changes per software release are all likely to increase network security and availability. However, this is not just about tools and assets. It's about collaboration.
Network automation is an agile way of working that allows development (perhaps engineering in an operator), security, and operations to take shared responsibility for the network's stability, security, and resilience. Accomplishing agility means finding many ways to collaborate and communicate transparently and breaking down internal barriers to create a more cross-functional way of working. There are many ways of doing this, such as breaking down the silos through specialist secondment into other teams or forming integrated cross-functional teams. Transparency can be improved through shared issue tracking tools and inviting each other to meetings. What's essential is the shared responsibility of all the issues, clear clarity, and crucially clear feedback from operations and security to engineering and development. This change is fundamental because, in an "immutable" future, operations will not be changing sub-optimal or incorrect configuration but will request engineering or development to make changes in the digital assets that program the network. Making manual changes to an automated and orchestrated network is likely to lead to service consistency and network integrity problems.
Figure: DevSecOps
Kevin: In your consulting experience with CSPs worldwide, what has been the number one concern for them as they prepare for 5G? Are the CSPs prepared to make this journey?
Hemant: Telecom operators are bound to hit an "air gap" in adopting the continuous software for their 5G Core. This barrier is an apparent separation of priorities and concerns between the various software lifecycle stakeholders in an operator and its multiple suppliers (telecom vendors). Based on our experience with early adopter CSPs, we have found that these service providers often continue with their existing operations approach. Even during NFV transformation, the process was siloed across domains and led to disparate operational strategies. Without the necessary changes to the operating model, the 5GC evolution will only increase the overall cost and complexity of managing the network and increase the total time to market for new services. This result is explicitly the opposite of 5G network expectations. The organizational challenges to the successful introduction of the software continuous integration and deployment include:
- The challenge of agile iteration across vendor/service provider organizational boundaries.
- Legacy waterfall software development lifecycles (SDLC) that encourage sequential change in at least two separate engineering and operations (Dev and Ops) domain silos.
- Several substantial test teams deploying and testing software in project-centric test environments.
- Defining a consistent rollout methodology and requirement model for cloud-native applications;
- Unknown development metrics and KPIs like team velocity; and
- Lack of end-to-end (E2E) service traceability (e.g., the requirement to customer acceptance of service).
Related
CI/CD In Telecom 5G (Part 1): What Is Telco CI/CD?
CI/CD in telecom 5G part 3: What is the telecom CI/CD journey?
Read more about continuous integration and continuous deployment (CI/CD)