An article on SDxCentral.com points out a few major issues facing Service Providers when it comes to NFV and the operational complexities involved. It focuses most attention on the maintenance of VNFs and how the software model will be very different than the traditional, hardware-based model Service Providers are used to.
I have to take exception with comments about VNF support from vendors in the following excerpt from the article:
“Often, when service providers ask incumbent suppliers for VNFs, suppliers merely produce virtualized versions of existing boxes, writes Aloke Tusnial, VP of global sales SDN/NFV with Netcracker, in a corporate blog posting. “But now the risks of implementing VNFs and ensuring their orchestration with the rest of the network comprised of both legacy hardware and virtualized software fall entirely on the shoulders of service providers,” he writes.”
Really? Vendors will virtualize their devices and throw it over the wall for you to fend for yourself? This is one everyone needs to take with one of those huge salt blocks that ranchers will put out for their livestock…not just a grain. The sales spin is very strong in this, which means it is just plain wrong. Vendors I have worked with, and it is a fair number of them by now, are extremely involved in the support of their VNFs, including how they integrate into your network.
If you experience the issues stated in this article from your supplier, you need a new supplier. Period.
Now let’s talk about the other things it also talks about, like cultural issues.
There is absolutely a need for cultural evolution as NFV is rolled out. There is a collision of network engineering and IT worlds happening that I have seen cause untold delays in accomplishing anything while companies figure out who should own which piece of the puzzle. Who owns the service? Who owns the hardware involved in the infrastructure? It is servers, so should IT own it? Those servers are hosting network functions, so should Engineering own it? Those engineers are doing IT-like things, so should they work for me (IT) or you (Engineering)? Should we form an entirely new organization that is a hybrid IT/Engineering group?
Organizational challenges abound in this emerging space. Technological challenges do as well, but those are actually the easy parts of this, believe it or not, and have the easiest answers. If you lack the technical expertise in house to accomplish your goals it is a simple thing to bring in an integrator to help you with implementation, training, knowledge transfer, and R&D efforts. Culture has to be fixed by the people within it…not so easy. There is consulting help that can be applied here, but the bigger, generalized consulting shops don’t know the answer to this any more than you do. Some smaller, specialized companies in this space will be of much more help.
Additional complexity is also introduced when you add onto this the integrations with northbound support systems, as well as the introduction of new support systems such as NFV Orchestrators, VNF Managers, Virtual Infrastructure Managers, etc. One of the missing layers in most company’s strategies to address all of this is a layer that can consume all of that southbound functionality those new tools bring, all of the OSS/BSS capabilities that already exist, and present the Operations team with the right tools to do their day to day jobs.
Within most companies Operations already has a nightmare list of systems to log into and swivel chair between from the legacy network in place today. The answer to NFV success is not to add more things to that list. Our goal at Itential, and something we don’t see a lot of vendors focusing on, is automated operations. It will never be an area that can be 100% automated, but the dynamic nature of NFV requires the move to as much operational automation as possible. Legacy OSS can’t do it. Loosely coupled components from various vendors in the NFV space can’t do it. This operational automation layer has to be put in place, whether built in house or using something like Itential to accelerate that activity.
Tags: No Tags Available