Many of the existing network functions, such as routers, firewalls, load balancers and such, haves gone through the first transition from a physical appliance to a virtual appliance. Where 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 transition 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 a business model that 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, as well as what is required to achieve cloud-native capabilities, along with the challenges and benefits of this transition. Nati will discuss the primary characteristics that are expected from a Cloud Native VNF: - Self-Management - Multi-Tenancy - Being Software Defined He will also show how open source cloud orchestration tools can make this transition seamless and ensure full lifecycle management of your VNF.

1. The only constant is changeThe only constant is change
The Road to
Cloud Native VNFs

2. The only constant is change
Introduction
• Open Source advocate for the past 10 years.
• Actively involved with OpenStack since its
inception.
• CTO & Founder GigaSpaces
The leading Hybrid Cloud
Orchestration by
OpenStack users

3. The only constant is change
About Cloudify
Member of
Network Functions
Virtualisation ISG (NFV)
Standards Organizations Open Source Projects

4. The only constant is change
Traditional Network Function

5. The only constant is change
From Physical Appliance to Virtual Appliance
Mostly involved
performance
optimization and
packaging
Physical
Appliance
Virtual
Appliance

6. The only constant is change
The Rise of Cloud Native NFV

7. The only constant is change
The Cloud Native Disruption
Physical
Appliance
Virtual
Appliance
Cloud
Native
Mostly involved
performance
optimization and
packaging
Disruption -
Changes in the
architecture,
delivery model
and biz model

8. The only constant is change
Cloud Native VNFs (Versa)
Self-Managed

9. The only constant is change
Cloud Native VNF Example (Ruckus)
SaaS Managed

10. The only constant is change
Recipe for Cloud Native VNF
● Software Defined
• Including the 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
● Containers
• Package your software in containers
• Support multiple containers

11. The only constant is change
Other Considerations
● 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

12. The only constant is change
Generic VNF Orchestration (G-VNFM)
Provision
ConfigureMonitor
Manage
Orchestration EngineVNF Hybrid Cloud/Stack
- Self-healing
- Auto-scaling
- Monitoring
- Policy Management
- Security and Multi-Tenancy

13. The only constant is change
Cloud Native on High Performance Stack
(Coming Soon)
Bare Metal Cloud
Intel EPA
Enabled
Provision
ConfigureMonitor
Manage
- Self-healing
- Auto-scaling
- Monitoring
- Policy Management
- Security and Multi-Tenancy
Orchestration EngineVNF High Performance
Containers
Canonical Clear Containers

14. The only constant is change
Generic (Operator) Orchestration
Virtual Appliance
Service
Composition
Physical Appliance
Micro Services
Lifecycle
Management
Consistent
Infrastructure
/Tenant
Management
Multi Tenant
Orchestrator
Cloud Native VNF
Embedded
Orchestrator
Embedded VNFM / Operator Orchestration (NFVO)

15. The only constant is change
Characteristics of Embeddable Orchestration
● OEMable
● White Labeling
● Lightweight
● Open Source
● Open Governance
● Extensible/Customizable
● Portable Between OSes & Clouds

16. The only constant is change
Cloudify Embeddable Orchestration
VNF providers should consider ARIA to gain TOSCA support,
automation of deployment and configuration across multiple
clouds such as OpenStack, VMware, (or any other cloud), as
well as portability between different container-based
architectures such as Docker Swarm or Kubernetes.
Cloudify includes ARIA as its orchestration engine, so by
definition, it inherits all of its capabilities in addition to the
capabilities that are provided by Cloudify Manager.
VNF providers should consider Cloudify in cases where they
would want to gain more advanced management, ongoing
automation and security such as:
- Self-healing
- Auto-scaling
- Monitoring
- Policy Management
- Security and Multi-Tenancy

17. The only constant is change
Standardization Effort
State of the Union Open-O/ OSM Common Modeling Effort

18. The only constant is change
Live Demos
KVM ESXI
Netconf/YANG
Heat
Netconf/YANG
Service Chaining in a World with No Standard Best of Breed vCPE
TOSCA
TOSCA

19. The only constant is change
Are You Ready to be Cloud Native?
Prerequisites
● 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
intervention during the setup process?

20. The only constant is change
Where Do I Go From Here?
Academy
● Free NFV Lab On Demand
Through the Cloudify Academy
● Special Consulting and Support Package
for Cloud Native VNF

21. The only constant is changeThe only constant is change
Thanks!
Questions?
Find out more on getcloudify.org