The Cloud Native VNF Explosion at MWC18

VNF Onboarding is known to be one of the biggest challenges in the transformation to NFV transformation as noted in one of the recent SDxCentral report: VNF Migration challenges.

Arguably the biggest challenge organizations will face when it comes time to operationalize VNFs is a lack of processes. Many IT organizations are in the throes of managing complex transitions to modern DevOps processes. The typical network service team has no operational processes in place for deploying and managing VNFs. On top of that, add the need to secure those VNFs and make sure they meet compliance mandates and it could be several years into the next decade before VNFs are commonplace.

Current Approaches to VNF Automation -  Challenges and Limitations

To date, the primary approaches to addressing this challenge have only had various degrees of success, these include:

• Homogenizing all VNFs through a common information model:

ETSI and other standardization bodies have tried to “homogenize” all VNFs through a common information model represented by a VNF descriptor. The main challenge with this approach is that it requires a lowest common denominator approach for VNFs which prevents them from showcasing their unique capabilities - and when you start adding unique features to a VNF descriptor the whole idea of normalization just renders itself as not valid anymore. As a result, vendors are not eager to adopt a common information model, as it increases the cost, while not providing much of benefits in return.

• Generic VNFM delegates integration effort to the end user

The other approach (also supported by ETSI) has been to define a generic VNFM for all VNFs, which basically moves the challenge of automating the management of VNFs from the vendor to the end user.  The basic premise behind this approach is  the assumption that you can leverage common information model in the form of a VNF descriptor.  Many customers have tried to deal with this challenge by creating complex on-boarding and certification processes, however these processes still leave the heavy-lifting of automating a huge complexity in the hands of the customer, making the entire on-boarding process still very costly and slow.

• The Cloud Native VNF Approach

The move to a cloud native operational model is expected to disrupt this entire thinking.

The Cloud Native VNF approach places the responsibility of simplifying the operational model of a VNF to the VNF vendors themselves to define an opinionated architecture on what’s required to deliver a cloud native service that supports dynamic services like auto-scaling, healing, upgrades as built-in features.

Many of the new generation network services such as SD-WAN and vCPE were built with this architecture in mind.

The challenge with this over-the-top approach is that these next generation network service providers also took the entire operational challenge of delivering those services through SaaS models, and in many aspects make carriers fairly redundant.

The other challenge is the transformation challenge. Many of the existing VNFs were not built for cloud native environments, and therefore need to undergo a fairly large transformation to fit into the cloud native world, and this has proven challenging.

A Pragmatic Approach to Making Cloud Native Network Functions Possible

Over the past few years we've gone through the experience of trying all of the approaches mentioned above, and realized that none of them have really solved the VNF automation challenge alone.

Another key finding is that the model of taking a VNF which was set to be a standalone virtual appliance and turn it into a cloud native service, with full automation of the entire operational model, cannot be easily achieved without a strong commitment by the VNF vendors.

The attempt to force such a commitment from the end user isn’t good enough, as every end user - whether carriers or enterprises, have its own way to define the rules for certification. The thought that this level of automation can be fulfilled as part of the carrier’s domain is also broken as it will break with every new release of the VNF. That made us realize the right path would be to make sure that VNF are set to be self-managed before they even get to the end user, and that should be the responsibility of the VNF vendor.

That is how we developed a more practical and pragmatic approach to enable the transition to Cloud Native VNF, which is basically a combination of all three approaches that I outlined above - let me explain:

1. Embedded VNFM   - provide a lightweight, open-source software orchestration package that can be embedded and white labeled as part of a VNF vendor’s software package, taking care of all the generic aspects of the transformation to cloud native architecture, such as full automation of the deployment and configuration process, as well as automation of day-2 operation such as upgrades, healing, scaling and any other dynamic services required by cloud native environments.
2. Simplify the transformation to Cloud Native - The approach that we took was to support pure cloud native architecture through extensive support for Kubernetes, while at the same time also supporting virtual appliances, thus allowing a mix of virtual appliances alongside microservices managed within the same automation framework. This significantly reduces the transformation challenges as it doesn’t force a complete rewrite, and allows a more gradual transition to pure cloud native architecture while at the same time providing closed loop automation of the entire hybrid stack.  
3. Just enough standards - Focus on interoperability and integration between existing VNF information models rather than forcing a common information model. This is done through a specific universal configuration management of VNFs. The universal configuration management makes it possible to manage the configuration of a large variety of VNFs through a combination of a simple configuration data structure based on TOSCA. This takes care of the configuration properties that need to be set as part of the automation process, and does not require that this serve as the entire data model of each VNF.  In addition, another important aspect is being able to push updates through integration with existing protocols and formats that are already supported by the VNF, including YANG, XML, REST, JSON, Ansible over Netconf, Telnet.
4. Collaboration with carriers to deliver an open network management platform (namely though ONAP) - In order to make this entire process fully operational we are working on one end with many VNF vendors directly to provide cloud native functionality, while at the same time contributing the same principles and even software as part the ONAP project’s Service Orchestrator and Operational Management components.
5. Multi-cloud support - Most of the end users run on their own VMware or OpenStack data center and are now starting to expand into public clouds. VNF vendors require multi-cloud support for different reasons. Multi-cloud allows VNF vendors to fit naturally into their customer’s environment, and thus expand their target market. Having the infrastructure abstracted from the VNF service provides a greater degree of flexibility.

All this combined makes the transformation of  VNFs themselves to cloud native more practical. It also makes the entire end-to-end automation of the operator network services more consistent and cloud native.

Cloud Native VNF Explosion at MWC18

I first started to experiment with the idea of Cloud Native VNFs during a meetup in late 2016. This work was largely inspired by extensive work with VNF vendors such as Metaswitch, Athonet, Versa and Brocade. We then launched a Cloud Native VNF partner program and have also partnered with VMware and Intel to deliver the first VNF on boarding hackathon during MWC17 and this is where it became clear to me that we were onto something that could finally solve the VNF automation challenge.

Around the same time we joined ONAP which ended up adopting both TOSCA and Kubernetes as part of its cloud native strategy which brought even stronger support and validation to this approach.

Having said that, nothing prepared me for what we’re experiencing in MWC18. Over the past few weeks we’ve been notified by our VNF, infrastructure and technology integrator partners that they will be demonstrating their integration with Cloudify during the event.

This is a good opportunity to list where you can see Cloudify in action at the very noisy MWC event:

• Fortinet - Cloudify and Fortinet have been partnering closely through the Fortinet Fabric Ready partner program.  Cloudify has built a solution with Fortinet to deliver TOSCA-based security orchestration for their best of breed security appliances.  Cloudify makes it possible to deliver dynamic services for all Fortinet VNFs across any cloud environment.  
  • Visit the Fortinet booth - Hall 7 Stand N91 - at MWC to catch Cloudify in action delivering presentations daily on The Benefits TOSCA-Based Security Orchestration
  • Watch the recent webinar with Fortinet
  • Read the Solution Brief
• 6Wind - You can visit the 6Wind booth - Hall 5 Booth 5B85 - to see a demo of Cloudify Manager serving as the VNF Manager and NFV Orchestrator functions for the 6WIND vRouter. 6WIND's virtual appliances are instantiated on OpenStack, and OSPF routing and IPsec VPN tunnels are configured, deployed and orchestrated by Cloudify with TOSCA based templates. The solution is then monitored by Grafana out of the box or any other pluggable monitoring platform of choice.
• NetNumber - NetNumber recently announced the integration of their TITAN platform with Cloudify to orchestrate the deployment as well as on-boarding, service chaining, and management of its various VNFs and specifically their signaling systems. With Cloudify as the VNF Manager (VNFM), the TITAN Master is deployed onto OpenStack and then automatically on-boards the TITAN Edge nodes and connects them to the Master. Cloudify then also automates scaling or healing of the nodes as needed based on metrics with policy management.  This demo will also be available at the Netnumber booth - Hall 7 Stand 7D81.
• Metaswitch and Cloudify have been partnering on a community level for a number of years, and have recently moved to a business engagement where Metaswitch has selected Cloudify and will OEM Cloudify’s virtual network functions management (VNFM) capabilities in delivery of its own VoLTE TAS, vSBC and vIMS VNFs.
• ASOCS - Using Cloudify’s open source automation manager, Cyrus will be fully automated and orchestrated in accordance with ONAP.  Using Cloudify’s open source automation manager, Cyrus will be fully automated and orchestrated in accordance with ONAP. Cloudify Manager detects a policy in the blueprint that meets the condition, and automatically triggers a healing workflow. If Cloudify Manager detects an overload of resources, then it automatically triggers a scaling workflow and adds more capacity. Meet ASOCS at Hall 2 Stand 2E50 and see the demo here.

We are also starting to see VNF vendors using the integration with Cloudify not just as a means to transform their VNFs to fit into virtual and cloud environments, but as a means to extend their offering to their customers by turning their VNFs into a full-blown cloud native service that combines multiple network services as a solution, such as we have seen with MetaSwitch and Fortinet.

Other VNF vendors such as F5, Athonet, Cataleya IMS, Mavenir vEPC, Versa, Affirmed already support or are in the process of adding support for Cloudify as part of their VNF offering.

This also adds to other VNF support that was led by our customers which include Cisco CSR, Juniper CPE and Palo Alto firewall.

Cloudify & VMware

In this demo VMware will be showcasing a Distributed VoLTE Core Deployment with Kubernetes scenario demonstrating full deployment of a VoLTE core using Cloudify to deploy Metaswitch IMS + Affirmed EPC + Ixia test + Hawkeye monitoring in multiple instances for MVNO topologies.

In addition to that, VMware & Intel will be hosting an open VNF on-boarding hands-on technical session. Cloudify will participate in this session on Tuesday, February 27th, at 2:00 PM (CET) in the Dell/VMware booth in Hall 3, Stand 3K10.

Cloudify Solution Partners

Other solution partners have chosen Cloudify as the open platform to be able to build upon to deliver turnkey solutions to their customers. Such partners include our partners in Asia - Aptira, NTT Data, and in Europe such as Kapsch and Amartus  As well as global partners such as Tech Mahindra and ATOS.

• Tech Mahindra will be demonstrating ONAP running on Kubernetes using Cloudify.  Visit them at: Hall 2.1 Stand 2.1C19Ex, Hall 2.1 Stand 2.1C14Ex, Hall 2.1 Stand 2.1C23Ex, Hall 2.1 Stand 2.1C21Ex
• HCL will demo an orchestrated deployment of multi-slice core network (vEPC) on a distributed NFV Telco Cloud scenario using Cloudify. The Mobile terminals (UE) will be able to connect to different network slices based on required service capabilities making use of two different clouds (VIMs) with following characteristics: Main cloud: OpenStack Liberty based (OPNFV Brahmaputra), and Edge cloud: Openstack Ocata based (Openstack Kolla project tag 4.0.3).  Find them at Hall 2 Stand 2H40.
• Kapsch & Advantech will be leveraging Cloudify to supply the orchestration of both CPE-based and cloud-based central management for the CarrierCom and uCPE use case on white boxes.
• We have also been seeing exciting projects made possible through excellent partnerships in APAC including our co-members of the LFN & OpenStack communities, Aptira, as well as Lumina, who have been working with us to deliver carrier-grade orchestration projects with some of the largest service providers. Find us at any of our partners' booths to see this integration in action.

Final Notes

For me, the most exciting part of this is that most of this development occurred organically and was driven by the VNF vendors or customers themselves which demonstrates the power of open source.

The fact that Cloudify is open, and built to be lightweight and embeddable, both from a footprint perspective (Cloudify fits into a single container or VM) as well as through the support of a white label user interface, makes the integration effort with existing VNFs fairly simple and has proven to be a strong differentiator for Cloudify versus other orchestrators in the space.

In addition, being the leading TOSCA orchestration platform that is already integrated with ONAP and Kubernetes, on top of the support of a wide variety of cloud providers such as VMware, OpenStack, AWS, Azure, GCP allows VNF vendors to check mark all these features into their product through the embedded VNF integration.

Over the past year we also added extensive support to simplify the configuration of a large variety of VNFs out of the box, and without the need to write custom integration code through a generic configuration plugin. This makes the effort of VNF on boarding and even complex service chaining of multiple VNFs pretty close to a “lego play”, where you can easily create a composition of VNFs through a reusable blueprint configuration.

This shows the difference between taking the pragmatic approach to just enough standards to the attempt to harmonize all the VNFs through a common information model.

By focusing on enabling automation through interoperability with existing VNFs, and at the same time making a smoother transformation to the cloud native world possible we achieve a faster transformation to NFV and at a significantly lower cost.

Indeed we've seen major success with this approach with service providers such as Proximus selecting Cloudify as their key orchestration. Two other service providers won the Layer 123 award for integration work Cloudify is proud to be a part of:  Telstra for Culture and Diversity and  Partner for Best vCPE/uCPE, and we expect to see others joining this success shortly.

SD-Core