Features and Analysis

How does Agile apply to NFV and SDN?

In this two-part series IBM’s Charlie Hale looks at why adopting virtualization technology means changing not only the network but also the business. This article examines how operators can use Agile methodologies for network functions virtualization (NFV) and software-defined networking (SDN), and the role for DevOps. Part 1 focused on how service design and creation must change and why communications service providers need to embrace Agile.

When implementing NFV and SDN, communications service providers (CSPs) are essentially moving to software-based network services and software-based innovation models to compose new services out of network software components. Network service creation and design can be treated like software development when managing the process.

Delivering working software to the customer early and continuously is directly applicable to new network services that can be created with NFV and SDN. Operators can create new services quickly through automation in cloud environments compared to setting up physical devices. This also allows testing of new vendors and features. Depending upon the service being created, lines of business and network service creators work together on an iterative basis with new services created and changed often to suit requirements.

The importance of DevOps

DevOps, which brings together development and operations, is important in this transition and is a key factor with NFV and SDN. It creates a tighter creation, testing, deployment and operational lifecycle.  NFV and SDN allow for automation which can bring the service designers (the developers) closer to operations by allowing immediate deployment through orchestration tooling.

In a TM Forum Insights Research report called NFV: Bridging the chasm, which was published in 2016,  shows that a large majority of CSPs believe DevOps is very important for network operations.

One of the important pieces related to DevOps in a network service is managing the testing (and requirements) in an automated fashion. New service requirements should be established and managed against customers’ expectations and feedback. As services are continuously updated, automated testing is essential to ensure new features do not create problems. Using DevOps practices, service providers can stand up services in a sandbox environment with test automation around it, to both validate and do regression testing.

Bringing Agile and DevOps concepts together for network services (Agile Network DevOps) describes the intent to shorten the network service development lifecycle by managing it with Agile principles and a DevOps methodology. Some of the practices such as quick iterations, adapting to changing requirements and failing fast are in direct conflict with rigid change management and legacy approaches to delivering network services, and may not be applicable to all services. But as CSPs look to bring new services based on NFV and SDN to market, adopting Agile Network DevOps will be imperative to shortening the time to market.

How does Agile Network DevOps work?

Agile Network DevOps involves bringing all stakeholders together frequently to interact throughout the lifecycle of a service. It involves managing customers’ requirements and feedback from early on in a collaborative environment, where the requirements are understood by everyone and functionality is delivered iteratively on a regular basis.

This means new services are deployed and small pieces of functionality are delivered and tested sooner and evaluated sooner. Early feedback is reviewed to address evolving needs and requirements of the customer sooner in the service lifecycle.

Service deployment and test environment creation can be automated, so creating sandbox environments and regression testing is much faster than the traditional approach which would involve ordering new hardware, racks and power, and running new cabling. Although this is a benefit for virtualized networking in general, it is essential in DevOps.

Managing the collaboration between stakeholders throughout the lifecycle of a new service will also help transform the CSP’s business model. Traditional project management and continuing with groups acting in silos within the telco will not allow for swift innovation.

As suppliers begin to deliver their virtual network functions (VNFs) with continuous delivery, service providers will need to continuously update services to the latest code. The service provider can automate the process of adding a new version of a VNF to the service when the supplier produces an update to the VNF. Automation in this service delivery pipeline as well automated testing will be essential for handling the continuous integration and iterative releases expected in DevOps.

Looking ahead

Agile Network DevOps can help reduce the time it takes to bring new services to market by managing the entire lifecycle. In the future, with standardization around VNF packages and proper metadata describing the virtualized functions, service providers could automatically procure and onboard these virtualized functions.

Imagine a marketplace for VNFs where a service provider’s procurement system could, through an application program interface, procure and acquire a new function based on orders customers place through a self-service portal. The standardization needed for VNF packages is described in TM Forum’s Information Guide Procurement and Onboarding of Virtualization Packages (IG 1141) and has been showcased in two Catalyst proof-of-concept projects: Enabling the digital services marketplace with automated onboarding and Joint Agile Delivery.

Issues related to NFV deployment are being addressed in the Forum’s Zero-touch Orchestration, Operations and Management (ZOOM) project. If you would like to learn more about ZOOM, please contact Barry Graham, or if you are interested in participating in a Catalyst project, contact Jean-Pierre Dufresne.

The author would like to acknowledge and thank Jason Hunt, Dan Popescu, Steve Teitzel, and Craig Farrell for reviewing and offering input to this article.


    About The Author

    Service Management Solutions Architect, IBM

    Leave A Reply

    Back to top