"If we can build complex systems from simple components with precise functionality."
. . . and Gabriel's follow-up comments/question.
I believe the short answer is "yes" but requires some advance, well thought out architecture or platform work.
If the simple components (VNF modules) are interconnected in such a way as to be "tightly coupled", then we may find the same problems and challenges in upgrading or enhancing the total system as we do today with hardware+software tightly coupled integrated systems (i.e. monolithic).
I don't believe the hardest issues to be faced with SDN/NFV will be mostly about "thick/heavy" or "thin" modules. I think it will be about a how to do modularity supporting upgrades (changing modules) or additions/deletions dynamically (system isn't disrupted when any module is changed or added/deleted).
Making complex software systems out of modular components has been done for awhile now in the IT world. But to accomplish that in such a fashion as to avoid the concern's Jeff raises requires putting in place a software architecture, from day one, that supports dynamically changing (upgrading, adding, deleting, moving, etc.) software modules without disrupting the whole system.
For example, Open Daylight uses Java/OSGi modularity to achieve these goals. And web services platforms like Weblogic and Glassfish have similar dynamic modularity capabilities. By defining the "rules of the game" for modularity day one, developers then have a structured methodology for making dynamic, modular, large scale, complex systems out of simple components.
Those are just some examples of how it can be done. But those examples are for a "single system" (i.e. multiple modules but typically operating on the same VM or address space). With NFV, the challenge expands because VNFs will be deployed across different VMs, OS instances and/or physical hardware in different geographic locations as well.
In my mind, that is the more challenging aspect of NFV than whether to make a particular VNF "thick" or "thin". In fact, the advantage of a well-thought out, day-one modularity platform is that the developer(s) of the system don't necessarily have to get it just right the first time around. A thick VNF can be implemented and then as behavior and performance is analyzed, if it makes sense, it can be broken down into multiple thinner VNFs later on (or vice versa).
And the more interesting and exciting end game, is the potential ability to add new VNFs in the future that no one has yet conceived of. And the larger system can then discover the VNF, determine valid interconnect and then activate into the behavior of the larger system.
Network AssuranceI do see the benefits for network simplification and service provisioning in SDN/NFV.
But I still have doubts about network assurance. How would it work since we would be "centralizing the intelligence" in the networks?
Nowadays, the network is resilient to failures due to protocols that run in the box. It is completely autonomous from the any centralized controller. In that respect, when there is an outage the network itself can restore the services using the protocols in those boxes.
When you remove such intelligence from the network boxes, if there is a network outage and let's say the box looses the communication to the centralized intelligence (namely SDN controller), how would these networks be resilient?
Re: Why SDN & NFV MatterThanks for the response. Some thoughts...
Not sure what you mean by "thin" or "fit". I think of VNF as heavy and lightweight. The more functions the heavier it is. Thinking in terms of UNIX processes, a thread would be lightweight, a process would be heavy and a VM would be very heavy. I don't think VMs are the answer, instead I want things as lightweight as possible with simple gozinta's and gozoutas's. It makes them much easier to replace in the long term.
I think of simpler in terms of adding new funtionality. Today we need to build hardware or monolithic software to make a change. When we can replace a single lightweight VNF it reduces the complexity of the overall ecosystem to handle the integration and regression testing. That would be a good thing.
It changes the paradigm from the silicon cycle to the software agility cycle. A completely different way of thinking about adding features.
I'd be interested in people's thoughts on how application (VNF) design changes in view of these two statements:
"NFV allows the decomposition of network functions in discrete software components."
"If we can build complex systems from simple components with precise functionality."
One of the areas I'm looking at (for Heavy Reading) is the idea of the "Thin" or "Fit" VNF. Candidly, I don't have a good definition yet, but it is a more substantial change than stripping the unnecessary software modules from existing applications (e.g. chassis managers) and porting them to VMs.
Quite how this makes things simpler is not entirely clear either...
To your comment . . .
"If we can build complex systems from simple components with precise functionality."
. . . and Gabriel's follow-up comments/question.
I believe the short answer is "yes" but requires some advance, well thought out architecture or platform work.
If the simple components (VNF modules) are interconnected in such a way as to be "tightly coupled", then we may find the same problems and challenges in upgrading or enhancing the total system as we do today with hardware+software tightly coupled integrated systems (i.e. monolithic).
I don't believe the hardest issues to be faced with SDN/NFV will be mostly about "thick/heavy" or "thin" modules. I think it will be about a how to do modularity supporting upgrades (changing modules) or additions/deletions dynamically (system isn't disrupted when any module is changed or added/deleted).
Making complex software systems out of modular components has been done for awhile now in the IT world. But to accomplish that in such a fashion as to avoid the concern's Jeff raises requires putting in place a software architecture, from day one, that supports dynamically changing (upgrading, adding, deleting, moving, etc.) software modules without disrupting the whole system.
For example, Open Daylight uses Java/OSGi modularity to achieve these goals. And web services platforms like Weblogic and Glassfish have similar dynamic modularity capabilities. By defining the "rules of the game" for modularity day one, developers then have a structured methodology for making dynamic, modular, large scale, complex systems out of simple components.
Those are just some examples of how it can be done. But those examples are for a "single system" (i.e. multiple modules but typically operating on the same VM or address space). With NFV, the challenge expands because VNFs will be deployed across different VMs, OS instances and/or physical hardware in different geographic locations as well.
In my mind, that is the more challenging aspect of NFV than whether to make a particular VNF "thick" or "thin". In fact, the advantage of a well-thought out, day-one modularity platform is that the developer(s) of the system don't necessarily have to get it just right the first time around. A thick VNF can be implemented and then as behavior and performance is analyzed, if it makes sense, it can be broken down into multiple thinner VNFs later on (or vice versa).
And the more interesting and exciting end game, is the potential ability to add new VNFs in the future that no one has yet conceived of. And the larger system can then discover the VNF, determine valid interconnect and then activate into the behavior of the larger system.