White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue

Navigation

Page 118 of 144

Understanding OPNFV 118 Some developers refactor cloud hosted VNFs to make them more cloud friendly, or "cloud optimized". A non-disruptive way to approach this effort is to take easily separable aspects of the monolithic application and convert them into services accessible via REST APIs. The VNF state may then be moved to a dedicated service, so the rest of the app becomes stateless. Making these changes allows for greater velocity in software development and the ability to perform cloud-centric operations such as scale-out, scale-in and self-healing. While converting an existing VNF to be fully cloud native may be overly burdensome, all new VNFs should be written exclusively as cloud native if possible. (We have already covered cloud native application patterns in Chapter 2.) By using a cloud native architecture, developers and users can get much higher velocity in innovation and a high degree of flexibility in VNF orchestration and lifecycle management. In an enterprise end-user study conducted by Mirantis and Intel, the move to cloud native programming showed an average increase of iterations/year from 6 to 24 (4x increase) and a typical increase in the number of user stories/iteration of 20- 60%. Enterprise cloud native apps are not the same as cloud native VNFs, but these benefits should generally apply to NFV as well. Ultimately, there is no right or wrong architecture choice for existing VNFs (new VNFs should be designed as cloud native). The chart below shows VNF app architecture trade-offs. Trade-offs between VNF Architectures VNF Onboarding The next major topic to consider when integrating VNFs into OPNFV scenarios is VNF onboarding. A VNF by itself is not very useful; the MANO layer needs associated metadata and

Articles in this issue

view archives of White Papers - Understanding OPNFV