NFV is stumbling forward and entering the second half

The first half of NFV was a bumpy road, and it was not easy. Based on the accumulated experience of NFV in the past few years, the author has thought about and analyzed the key points that determine whether the telecom cloud can steadily climb and truly take root in the second half, and would like to discuss with you. The article is structured as follows:

• Are the promises we made still good now?
• Difficulties emerge, and we move forward with difficulty
• The key to the second half
• Already on the way

[[250152]]

1. Are the promises made in the past still good now?

NFV, or Network Function Virtualization, uses general-purpose hardware such as x86 and virtualization technology to carry out software processing of many functions, thereby reducing the expensive equipment costs of the network. Through software and hardware decoupling and functional abstraction, network equipment functions no longer rely on dedicated hardware, resources can be fully and flexibly shared, and new services can be quickly developed and deployed. Automatic deployment, elastic scaling, fault isolation and self-healing can be performed based on actual business needs.

The concept is tempting, but those beautiful promises that were once made, times have changed, are they still as good as they used to be? Let's take a look one by one.

1. The introduction of NFV can reduce CAPEX and OPEX

The current trials and pilots of operators have verified the feasibility of the overall solution and that the characteristics of individual components in the system meet the requirements. However, the reality is that the levels of implementation by various manufacturers are still uneven. Whether they can truly be agile and flexible in the complex environment of the existing network system remains to be tested in practice.

2. Flexible expansion of the NFVI platform, rapid launch of VNF services, and elastic expansion and contraction

The current pilot test has verified the feasibility of the overall solution and the characteristics of individual components in the system, but the levels of implementation by various manufacturers are still uneven. Whether such agility and flexibility can be truly achieved in the complex environment of the existing network system remains to be tested in practice.

3. The cloud platform can flexibly dispatch and coordinate resources to provide better resource services for upper-level businesses

The current NFV has actually just passed the stage of software and hardware decoupling, and the cloud resource pool is still at the stage of meeting the needs of upper-level business deployment. It has not yet entered the stage of deep integration with the business, providing better resource services, and efficient resource management of the overall cloud platform like the public cloud.

4. Prevent vendor lock-in

Through cloud computing technology, we can run products from multiple vendors on a unified platform in the form of software, which can be replaced at any time, breaking the lock-in of a single supplier. This is our beautiful vision, but vendors will try to avoid the integration of their own VNFs with third-party VNFs for various purposes. Vendors may say that the compatibility is not good and it is very troublesome to integrate, or even say that the connection performance with third parties is not as good as using their own. Because of this, operators have spent a lot of time and energy in recent years to repeatedly conduct cross-vendor docking tests and mature and improve enterprise interface specifications. However, even so, we still cannot avoid the later integration binding. When the integrator hands over the system to us in a turnkey manner, an integrated binding has quietly formed.

The mirage of the past has gradually faded, and the harsh reality has come. No wonder the industry has expressed concerns about the collapse of NFV. This is not groundless worry, and the above facts are cruel. However, any technology has its maturity curve. The author has been stumbling and struggling at the bottom of NFV for more than three years. After the concept emerged, the industry was chasing it, then there was thunder and rain, and everyone waited and watched, and then there were bumps and bumps in the actual implementation practice, until the lukewarm and sluggishness not long ago. However, from the perspective of the new technology maturity curve, this is precisely the accumulation of steady climb in the later period.

Of course, this maturity curve is only a regular analysis. When it comes to the technical development route of NFV, we still need to think and analyze the difficult progress of NFV in the past two years to find the key points for steady progress in the future.

2. Difficulties are prominent and progress is slow

It has been really hard for operators to promote NFV in the past two or three years. People outside the walls always complain that NFV is advancing too slowly and will miss the development window. To be honest, the communication network service level is high and it is a production system related to the national economy and people's livelihood. How can we take it lightly? Therefore, operators have repeatedly verified the solutions to catalyze the maturity of the industry. However, even with such efforts, the following difficulties are still highlighted.

1. Interoperability among vendors constrained by standards is progressing slowly

(1) NFV systems are complex and industry standardization is slow

In fact, standardization has been actively promoted since its development. Many influential international standard organizations have established special working groups to carry out NFV-related research, such as ETSI, IETF, 3GPP SAS, ITU-T SG13, CCSA, etc.; in addition, based on the above standards, a number of NFV-related open source organizations have also been introduced, such as OPNFV, OpenStack, KVM, Open vSwitch, ONOS, OpenDaylight, etc., which provide references for the open source implementation technology of NFV.

However, the NFV system is too complex, with many components and different interests of different participants, which leads to slow progress in standardization.

(2) Large enterprises require manufacturers to use corporate standards to regulate NFV systems, but each manufacturer has a different understanding of the standards, and their implementation capabilities and starting points are also different. They can only be polished and matured through pilot trials, but this requires a lot of time and manpower.

(3) Demand is changing too fast, and these standards and requirements need to continue to evolve and mature. As a result, operators are too busy formulating and revising them, and manufacturers are too busy adapting them.

2. We hope to give full play to the advantages of the cloud, make the cloud platform's capabilities service-oriented, flexibly allocate resources, and improve overall resource efficiency. However, the current industry is still in the early stages of software and hardware decoupling.

(1) The design of most network elements is still at the stage of directly porting the software on traditional telecommunications equipment to virtual machine images, and is not designed and used in a cloud-based manner.

(2) The cloud platform does not fully integrate business needs, provide rich cloud services, and flexibly manage resource scheduling. It also cannot optimize and improve the overall resource utilization efficiency based on the operating business conditions through effective means.

3. The operation and maintenance mode has changed, the operation and maintenance difficulty has increased, and I don’t know how to deal with it

Compared with the traditional model that focuses on equipment operation and maintenance, the telecom cloud is a platform-level system that involves many components. How to effectively divide the operation and maintenance work, how to effectively monitor, how to analyze and locate operation and maintenance problems through collaboration, and even how to predict problems are all considerable challenges. In these aspects, there is currently no clear solution or definition.

All of this has delayed the large-scale launch of NFV, and has caused the industry to have doubts about the maturity of NFV, leading to pessimistic views that NFV will fail. So what exactly is the problem?

• Does the operator not need a flexible network? No
• Is there a technical bottleneck that is difficult to overcome? No
• Is it because the industry ecosystem does not support it? No

Given the operator needs, technical solutions, and industry ecosystem, what exactly causes these difficulties?

The answer lies in the implementation model of NFV, which solves the problem of the last kilometer in the construction and use of NFV. Never underestimate this last kilometer. Many good concepts have been stuck in the dilemma of much ado about nothing for a long time because they did not solve the last kilometer. They have been unable to advance, or even missed the opportunity and were eliminated.

So what is the implementation model of telecom cloud, and how to solve the above problems? I personally believe that this is the key to NFV's victory in the second half, and it determines whether telecom cloud can steadily climb and truly take root.

3. The key to the second half

NFV transforms the communication network from horizontal device connections to vertical layered system construction. The traditional construction and use model for CT equipment must be transformed into the construction and use model for IT cloud systems. In this transformation, if the traditional model of relying solely on manufacturers to provide products and services is still used for implementation, the above problems will inevitably arise, making the construction of NFV difficult and the advantages of NFV will ultimately be greatly reduced.

So what is the implementation model of NFV? In other words, how to find effective methods to ensure the rapid implementation of NFV and give full play to the advantages of cloud computing? This needs to be discussed one by one from the difficulties mentioned above.

1. NFV system components are complex, so in the early stage, we need to strengthen docking and adaptation work, and cannot rely entirely on specifications and standards. Instead, we need to standardize and make integration transparent, improve the efficiency of solving integration problems, and accelerate implementation.

The traditional model starts with case-by-case project construction. The vendor's products are guaranteed to be integrated and connected through standards, specifications and technical requirements, and the integrator provides integration services in a turnkey manner. However, for complex systems, many systemic problems such as adaptation and tuning that arise during integration or later use are not easily covered by the early technical requirements. One consideration is to open the black box of integration work, standardize the integration process, standardize the integration design, standardize the integration connection, etc., extract some of the key system design, connection verification or system verification work, and process them on a centralized platform in advance. In addition, it can also be continuously guaranteed during the implementation and later use of NFV system integration, which ensures the efficiency of system integration construction. In addition, after standardization, it naturally evolves to automation, helping us to efficiently discover problems that cannot be touched by specifications and standards, quickly iterate specifications and standard requirements, and accelerate the introduction of new services and new technologies. In short, this achieves transparency and efficiency in the integration process, rather than inefficiently verifying the system in a black box and slowly improving specifications and standards.

2. Build an IT-based integrated verification model to quickly build on the advantages of cloud computing and improve the quality of NFV system implementation

Taking advantage of cloud computing is essentially to promote the cloud design of network element services and improve the construction and resource use of cloud platforms. The development history of cloud computing proves that this process is not achieved overnight, but requires continuous iterative optimization and effective linkage of development/integration/use. However, the traditional construction and use model is actually a way of purchasing products and services, which is difficult to achieve. Therefore, it seems powerless when dealing with the cloud model. This is why we work so hard, but the results are not satisfactory.

Since NFV components are currently provided by manufacturers, one consideration is for operators to build a mechanism to interact with manufacturers, introduce the DEVOP model in the IT field, and work with partners to combine the product development evolution of manufacturers and the integration verification of operators into a system. To promote the rapid iterative evolution of NFV components, the following is a preliminary idea of ​​this process.

Based on the overall integration process of NFV, the NFV software component development/integration/verification are combined to form a closed-loop process. Due to space limitations, the technical details will not be expanded here.

With such a platform, we can quickly integrate and verify with manufacturers, and quickly carry out regression verification if any problems arise in production. In this way, the adaptation issues of various network elements, cloud improvements, and various technological evolutions of the cloud platform can be fully verified and iterated.

3. For complex systems, effective solutions to operation and maintenance problems require the integration of construction/operation and maintenance to ensure implementation

Building a new type of integration that integrates construction, operation, and maintenance will closely combine the roles of on-site construction and technical research and verification. One operation and maintenance model is to build an integrated verification center to link local construction with the integrated verification center to help quickly analyze and locate, accelerate technical verification of operation and maintenance issues, and accumulate them to form an operation and maintenance knowledge base and capabilities. Due to space limitations, I will not elaborate on this here.

In the above work, we can see that operators can no longer stay out of the matter like buying products and services, but must deeply enter their own systems, control their own systems, replace the old-fashioned transactions between customers and suppliers, and form a win-win partnership. In terms of specific operations, the main thing is to improve the controllability of NFV implementation, use the products and services provided by manufacturers to lead the design, construction, operation, maintenance and evolution of the platform in terms of technology, that is, to form a new implementation model.

4. Looking at international practices, everyone is also moving in these two directions in terms of implementation models, emphasizing control of the system and industrial cooperation

(1) AT&T’s History

In the AT&T Vision 2020 transformation plan, AT&T Chairman and CEO Randall Stephenson said: "By 2020, I hope AT&T will become a technology company. We will manage all digital businesses through cloud computing, including mobile phones, cable, satellite TV and massive data, just like Google and Amazon." In fact, this has made clear its ideas for IT transformation and autonomous transformation. Judging from the various signals released to the outside world in recent years, it is indeed moving in this direction.

When the cloud strategy of Domain2.0 was first proposed, ATT and IBM started cooperation in cloud computing and big data. In 2015, the AIC cloud architecture was formed, and the open source cloud architecture based on openstack was built. In-depth cooperation was carried out with the then IT integrator Mirantis. After AIC1.O/ACI2.O/AIC3.O, it evolved to the NC cloud architecture in 2018. Relying on its own strength, it built a container-based cloud platform continuous integration development system (DEVOPS), and open-sourced the architecture into the AIRSHIP project. From the perspective of workflow, AIRSHIP includes the continuous integration development of the cloud platform based on containers, as well as integrated deployment and system testing.

Frankly speaking, although the success or failure of AT&T's practice is still uncertain, it does have a technical team of several hundred people and has strong control over the entire NFV system.

(2) Swisscom’s practice

After looking at the big companies, let's look at Swisscom. Their construction of NFV is not a transformation of the entire communication network, but starting from the TV business, building Media Cloud to carry current and future entertainment-related network services. On the one hand, they chose HP as a partner to provide cloud platforms and integrated solutions, responsible for system integration in the production environment; on the other hand, they built their own laboratory to conduct compatibility, performance, reliability and other tests on the platform and business. In addition, they worked with partners to conduct practical verification of technology evolution in terms of the containerization evolution of the platform and the construction of a hybrid cloud based on public cloud and telecom cloud.

4. Already on the way

Using NFV to reconstruct the traditional CT architecture means that CT must accept IT technology and IT thinking. Therefore, we see a series of IT technologies such as X86 general-purpose servers, OpenStack cloud platforms, and microservice business design being widely used in CT. As NFV enters the second half and is rapidly implemented on a large scale, it has become the focus of attention. At this time, an important IT construction model has gradually entered our field of vision, that is, the thinking and technical system of rapid iteration and rapid evolution. The foundation of this system is controllable technical capabilities and a partnership-based industrial ecosystem.

It is already past 2 a.m. as I write this. I am bent over my desk and thinking back on my years of experience in NFV. I feel a lot of emotion. Although I have complained a lot and was once deeply trapped in various technical details and felt frustrated, I also deeply appreciate the progress made by NFV. I can see that the industry has transitioned from passive resistance to gradual acceptance in terms of thinking. Technically, most of the problems have been solved, from being completely unable to connect. Enterprise standard interfaces have been gradually refined and improved, the definition of integrated content and integration processes has been created from scratch, and the integration design has been gradually standardized. The exploration of automation to improve integration efficiency is also in full swing. Although it is still a long way from our ideal cloud, and although it is still bumpy to implement, NFV is already feasible. At the same time, operators have been working hard on controllable models, accumulating bit by bit.

As we enter the second half, as long as we combine control and industry cooperation in the process of telecom cloud construction, use and evolution, and establish a rapid iteration model of integration, operation and maintenance, we will be able to build NFV on a large scale. Will anyone still discuss the fall and exit of NFV at that time?