At this year’s MWC, for the first time, I began seeing tangible examples of properly designed NFV orchestration. They were tangible in the sense that real NFV suppliers were solving real customer (CSP) needs. They were further tangible in that the hand-waiving component was significantly reduced. They were “properly designed” in the sense that they met most of Appledore Research’s best practices for orchestration and automation available here.
Appledore Research have been advocating for higher levels of automation, especially proper closed-loop NF and Service lifecycle automation, for almost two years now. The economics, as documented in our 2016 research are clear: automation is not only essential for close reduction, it is also essential to achieve an improved customer experience, and to meet the practical realities of maintaining a dynamic, cloud-based network. Humans are simply too few and too slow. This is a business imperative first, a technical one second.
Let’s begin with one of the most fundamental issues, and why. NFV and service orchestration cannot be “TOSCA loaded workflows”. Many orchestration products essentially put NFV models in from of existing fulfillment workflow engines. Furthermore, many defined specific VNF configurations – in some cases explicit images, rather than a true map of independently managed services. Both of these are poor design practices with huge costs agility and capability repercussions. Most importantly they make it vastly more complicated and maintenance intensive to operate an auto-correcting control loop. For those who want to learn more, Appledore Research plans to publish a major report on intent based modeling and automation later this year.
At MWC this year I put very specific questions to many MANO and VNF suppliers and got consistently encouraging answers. Among the most interesting discussions as with Nati Shalom of Cloudify, a product that has always supported cloud-native principles, and appears to be gaining momentum as one of the “go to” solutions for independent NFV vendors and especially for those that also need a simple way to integrate smoothly to ONAP (a topic that deserves its own blog or two — watch this space). At this year’s MWC Cloudify showed partnerships with Metaswitch, Fortinet, Affirmed Networks, OSOCs, VMware, 6Wind and Versa among others. Cloudify’s philosophy is very consistent with true cloud-native operations: the VNF supplier must define a decomposed architecture, and the operations to instantiate, grow, heal and configure this VNF — and in many cases to deliver that capability in the form of an “embedded” VNF-M that can execute that logic. This approach also takes the burden off the 600+ global SPs from having to perform this learning and engineering 600 times over – probably at a lower overall level of sophistication. The efforts of the supplier are shared across all – lowering up-front effort, increasing re-use, and reducing ongoing integration and testing efforts (its all in the package).
I am looking forward to upcoming similar discussions with HPE, Ribbon and NOKIA, all of whom claim to have true, parametric, intent-based, model-native orchestration. Watch for upcoming blogs and for profiles on their efforts, as well as synopses in our living MANO Supplier Roundup framework report, first published last month, and regularly updated to reflect this dynamic market.