There’s a growing sense of impatience and frustration with network functions virtualization (NFV) as service providers are not yet seeing the cost savings or agility benefits they were promised five years ago when the network transformation initiative was first launched. The mood change is certainly understandable, but the underlying causes not entirely understood. The reason for the dissatisfaction is that much of the industry is not yet doing NFV right. To realize the full promise of NFV, service providers and vendors need to embrace the principles of cloud native architectures. Simply porting monolithic software codes from existing network appliances onto virtual machines is doing NFV all wrong.
In a recent Light Reading webinar, entitled “NFV done right. How to apply cloud native design principles to network functions virtualization,” Metaswitch CTO Martin Taylor discussed why choosing cloud native design could be the most important deployment decision that operators make.
Cloud native architectures radically reduce the costs of building and operating networks – it’s not about shaving off a few costs here and there. If all we gain with NFV is cost reductions of around 20%-30%, then we might as well continue with the status quo. But if we can achieve an order of magnitude reduction, then that would be real progress and the business case for NFV makes sense.
Likewise with agility, service providers want a dramatic acceleration of pace to be faster at everything – innovation, service deployment, scaling, order turnaround, just to name a few. NFV will be worthwhile only if we can achieve a major difference, not merely modest improvements. Only virtualized networks designed from the ground up for the cloud can deliver these changes.
So how is a cloud native VNF different from a ported VNF? In a nutshell, these are the features that define a cloud native architecture:
- Stateless processing, which makes cloud VNFs fault tolerant and scalable without notional limits
- Microservices, which enables service composability, reusability, efficient scaling and ease of deployment
- Reliance on open source software
- VNFs are written for containers, rather than virtual machines, which reduces overhead
- Easy to orchestrate since VNFs are designed to minimize the amount of configuration needed in each component
When it comes to implementing NFV, the challenges service providers face highlight the need for cloud native virtual network functions (VNFs).
During the Light Reading webinar, we asked the audience of mostly service providers what they considered to be the greatest VNF implementation challenge, ranging from procuring cloud-native VNFs to integrating VNFs into existing systems. Most respondents cited challenges with integrating and managing VNFs: 34.6% said the biggest challenge was “integrating VNFs with OSS and BSS,” while 30.8% said the main challenge was “successfully automating lifecycle management of ported VNFs.”
Meanwhile, 19.2% of audience respondents said the biggest challenge was with “achieving true independence between VNF software and NFV infrastructure” and 15.4% said that the top problem was actually “sourcing cloud-native VNFs that meet all the necessary functional requirements.”
The results were not entirely surprising given that the main challenges tend to stem from not having cloud-native VNFs. It’s all too easy to neglect the difficulty of integrating with OSS and BSS systems, which the transition from physical to virtual functions doesn’t make any easier. Also, we’ve seen just how challenging it is to onboard and successfully lifecycle manage traditional VNFs that were ported from existing appliances. The reason this is so difficult is that the ported VNF software exposes the same management interfaces that it always did when it ran on a dedicated appliance, which is usually a command line interface (CLI), and the lifecycle management operations are performed by people sitting at a console going through a procedure as instructed by a manual. It’s really difficult to automate the lifecycle management of that kind of VNF.
What’s the benefit of microservices?
During the webinar we also asked the audience what they considered to be the key benefits of implementing microservices. 43.6% of respondents said the main benefit was “more rapid innovation through the adoption of DevOps processes,” while 41% said it was the “ability to assemble VNFs to meet specific service needs from available microservices components.” Just 10.3% said the benefit was the “ability to substitute different technologies into the VNF,” while only 5.1% said the main benefit was “maximizing the use of free open source software.”
Clearly, the poll shows that the main driver for adopting microservices is accelerating the speed of innovation, and that open source software was surprisingly not enticing for our audience.
Microservices is one of the ways web-scale companies like Netflix or WhatsApp constantly and incrementally enhance services. Because microservices decompose complex functions into basic building blocks, web-scale service providers can individually evolve each of the components so that the whole system improves over time. Unlike telecom service providers, they don’t have the problem of applying a bunch of changes to a monolithic piece of software and then having to do months of regression testing to prove they didn’t break anything.
How to spot truly cloud native VNFs
There are a lot of claims about cloud native products in the market now. Metaswitch is one of the first and few network software providers that has really embraced the design principles in our VNFs. Take a look at our Clearwater vIMS and Perimeta vSBC to see what cloud native VNFs really look like. But if you’re not sure, here are some tell-tale signs for bogus cloud native claims:
- Product is offered in multiple VM sizes: it scales up not scales out
- 1+1 active-standby redundancy, rather than N+k redundancy
- Monolithic software design with no open APIs between components
- 1-to-1 mapping between blades and VMs
- Initial configuration via CLI and multiple commands needed to deploy
These features indicate that the VNF is not cloud native and will not help service providers to do NFV right. To fully realize significant cost savings and massively accelerated agility from NFV, service providers need VNFs that are written for the cloud, can be implemented on containers, scale out (not up), are highly portable, easy to orchestrate, and employ microservices. Cloud native is NFV done right.