Many of the existing network functions, such as routers, firewalls, load balancers and such, have undergone the initial transition from a physical appliance to a virtual appliance. That transition required mostly performance optimization to accommodate the additional I/O overhead of the hypervisor and some configuration changes to accommodate the fact that a VM can be more dynamic in nature. This shift to NFV, which is basically a cloud-based data center, has revolutionized the way network functions can be delivered. The transition to a cloud native world is considered far more disruptive as it touches changes in both the architecture, to accommodate hyper-scale and multi-tenancy, as well as the business model, which needs to be more consumption based, rather than fixed. This talk will dive into the main requirements that differentiate a cloud native network function from the traditional network function, and, after making the leap from non-virtualized to virtualized network functions, what is then required to achieve cloud native capabilities, along with the challenges and benefits of this transition.

1. How Cloud Native VNFs
Deployed On OpenStack
Will Change The Telecom
Industry
Arthur Berezin
Dir. Product Management, Cloudify

2. [arthur@cloudify] # whoami
▪ Active OpenStacker Since Essex (2012)
▪ Dir. of Product Management, Cloudify
▪ Apache ARIA-TOSCA Project Lead
▪ Project Open-O TSC > now ONAP

3. Introducing Cloudify
■ Pure-Play MANO based
on TOSCA
○ Technology agnostic
○ Fits into any architecture
■ Full automation of
service lifecycle
■ No vendor lock-in, enabling
best of breed approach
Leveraging web-scale best
practices to orchestrate network
services in Telco environments

4. • NFV 1.0 Transformation
• NFV 2.0 Cloud Native
• OpenStack’s Role

5. Service Provider Traditional Networks
• Physical Appliance
• Vendor Driven
• 18+ months of on-boarding
• Static
• Costly

6. Physical to Virtual
[Network Function Virtualization]
• Commodity Hardware
• Commodity or custom Operating system
• Minimal Software Change

7. Physical to Virtual
[Network Function Virtualization]
• VM Appliance
• Virtualization Packaging
• Hours/Days to Deploy
• Same Management
• High HW Consumption

8. http://www.lightreading.com/nfv/nfv-mano/telcos-clamoring-for-cloud-native-vnfs/a/d-id/724093

9. Cloud Native Disruption
• Fully automatic
• Hardware Efficiency
• Commodity Costs

10. Cloud Native Disruption
● Hyper Scalable
● Architected to Expect Failure
● Operations Driven On-boarding
● Underlay and Overlay Networks
● Cloud Native Pricing Model

11. Cloud Native VNFs - Versa
Self Managed

12. Cloud Native VNFs - Ruckus Wireless
SaaS Managed

13. A Blueprint of
Cloud Native VNF

14. Cloud Native VNF
● Software Defined
● Application, Management and Provisioning
● Design for DevOps
● Configuration as code
● Built-in automation of the provisioning and configuration
● Continuous deployment
● Monitoring
● Avoid proprietary monitoring
● Use best of breed open-source monitoring framework

15. Cloud Native VNF
● Multi Tenancy
○ Share the same VNF between multiple users
○ Have separate VNF per (IaaS) tenant
● Multi Cloud (VIM) Support
○ Operators have different cloud flavour and preferences
○ Be ready to support the common platform to maximize your
market reach

16. The Cloud Native Journey with OpenStack
● De Facto standard VIM
● Highly customizable Private Cloud
● Making OpenStack Cloud Native
● Rich Ecosystem of Vendors and Plugins
● Overlay and Underlay Integration
● Expand the native capabilities

17. Leverage OpenStack
Use OpenStack’s Native Services for Cloud Native VNFs
Neutron
Designate FWaaS
Magnum Kuryr Kolla
Virtrage
LBaaS

18. VNF Orchestration and Management
Provision
ConfigureMonitor
Manage
Orchestration
Engine
VNFs Hybrid Cloud/Stack
Self-healing
Auto-scaling
Monitoring
Policy Management
Security and Multi-Tenancy

19. Cloud Native High Performance Stack
Provision
ConfigureMonitor
Manage
Orchestration
Engine
VNFs High Performance Stack
Self-healing
Auto-scaling
Monitoring
Policy Management
Security and Multi-Tenancy
Bare Metal Cloud
Intel EPA
Enabled
Canonical Clear Containers

20. Embeddable Orchestration
Operator Service Orchestrator
Multi-Tenancy
Management
Service
Composition
Lifecycle
Management
Consistent
Infrastructure
/Tenant
Management
Virtual Appliance
Physical Appliance
Micro Services
Cloud Native VNF
Embedded Orchestrator

21. Open Source Embeddable Orchestration
● OEMable
● White Labeling
● Lightweight
● Open Source
● Open Governance
● Extensible/Customizable
● Portable Between OSes & Clouds

22. Open Source Embeddable Orchestration
● TOSCA Deployment Orchestration
● Development Framework
● Lightweight
● Support for major platforms:
○ OpenStack, VMWare,
Kubernetes,Docker Swarm
● Full Lifecycle Management
● Uses ARIA as Orchestration Engine
● Advanced Management:
○ Self-Healing, Self-Scaling
○ Policy Management
○ Monitoring
○ Multi-Tenancy
○ Portal
○ Security

23. Standardization Efforts
Standards Open Source

24. Model Driven Cloud Native Orchestration
Multi Cloud Infrastructure Orchestration
● Automation of compute, storage, network
● Auto scale, Heal
● Consistent management and monitoring
Non
Containerised
Model Driven (TOSCA)
Service Orchestration
Orchestration of services
across platform domains.
Modeling is done Independent
of the Container platform.
(“Where”) and Independent of
how the service is
Orchestrated. (“How”)
Infrastructure Portability
Provision containers platform
across clouds and manage their
resource availability and
capacity
Service
Orchestration
Infrastructure
Orchestration
Container
Platforms

25. Hybrid Containerized Cloud Native
https://github.com/dfilppi/posts/wiki/Hybrid-CME-Post

26. Are You Ready To Be Cloud Native?
● Can you package your VNF as an Image/Container?
● Can your VNF be driven by API or external script?
● Can you boot/configure your VNF using Cloud-Init
● Does the setup of your VNF assume manual
operations during setup process?

27. The only constant is change
Where Do I Go From Here?
_Academy_
FREE NFV Labs ON Demand
Via Cloudify Academy

28. Thank You
www.CLOUDIFY.co