What is the success or failure of SDX?

SDN and SDS have been proposed for many years, but now they have basically faded and are no longer sought after by academic technology and commercial capital. Now, we can see what SDX has become, what results it has achieved, and what goals it has not achieved.

The initial architectures and goals of SDN and SDS are relatively consistent. In terms of architecture, both advocate separation of the control plane and the data plane, centralized control, and standard open north-south control interfaces. In terms of design goals, both want to directly face applications through standards so that applications can obtain more accurate resources and QoS guarantees. However, today, there are both successful aspects and failed areas. Here we briefly summarize them:

(1) Overall, SDX is successful in its architectural design, but it has failed in achieving its goals. Both SDN and SDS have seen the emergence of a large number of controllers, including open source and from various product vendors, which can be described as a hundred flowers blooming and a hundred schools of thought contending. However, in terms of design goals such as providing resources and QoS directly to applications, it has basically failed because all SDN or SDS controllers do not provide a standard northbound interface. Even if there are some standard definitions, they cannot meet the requirements of abstract modeling and direct docking for ever-changing applications. Ultimately, the software or apps of SDN and SDS have become network cloud services that automatically configure network or storage features and capabilities, cloud platforms, etc. This can be clearly seen in the architecture of OpenDaylight.

(2) SDX is undoubtedly a huge success in terms of automated configuration of network equipment and storage equipment. It has rich southbound capabilities and has formed multiple standards. Based on the needs of cloud computing/operator NFVI and other fields, SDX has greatly met the needs of configuration automation and greatly increased the accuracy of configuration. The automation capabilities of SDX have improved customers' new service deployment capabilities, troubleshooting capabilities, and innovation capabilities. Some vendors' SDX controllers can simultaneously connect to equipment from multiple vendors, thereby achieving unified and centralized management of customer site equipment and improving customer maintenance ease. However, there are many southbound standards for SDX, and each network vendor has its own considerations in SDN or storage vendors in SDS. They are afraid that their friendly vendors will control the customer interface entrance, so they basically provide their own controllers, and the commercial friendliness is greatly reduced compared to heterogeneous equipment.

(3) Many people believe that the centralized control of SDX will result in a single point of failure. Such analysts have completely failed to understand the centralized content of SDX and have confused the architectural design with the technical concept. The centralized control of SDX is a technical concept. Compared with traditional devices that control themselves, clusters are formed by in-band interactions between devices through cluster signaling. The single point of failure mentioned by these analysts refers to the design of the SDX controller system. Obviously, architects with certain system design experience will think of multi-resident clusters or active-standby high-availability designs. Innovators have even designed distributed controllers (such as Dragonflow and ovn). Therefore, the technical concept and system design of the controller are successful. However, there are many controllers in the industry, including open source and those from various manufacturers, as mentioned above, and the northbound is also different. This also results in the inability of ever-changing applications to directly connect to the controller, which also affects the achievement of SDN design goals.

(4) The initial application scenarios of SDX were not very clear, and the design goals were too ambitious. This was also the reason why SDN was a bit like a blind man touching an elephant when it was first discussed, leaving beginners confused. This was where SDX failed. However, soon, with the development of cloud computing, cloud network services and cloud storage services became the largest application scenarios of SDX. With the rapid development of today's hardware and software integrated products, SDX will continue to provide corresponding brilliant support.

From the overall development history of SDX, we can see that every new technology will go through a process of being discussed/pursued, then being applied after maturity, and finally being neglected. SDX, especially in the network field, was a hot spot that had been highly anticipated for a long time without any major technological highlights, but was eventually strangled by equipment vendors and fled to the cloud computing field. We can only hope that cloud computing can join hands with SDX to fight back against equipment vendors one day.

Therefore, SDX’s biggest failure is losing to LDE (Leader Defined Everything), and its greatest success is seizing several application scenarios and being able to develop continuously.