21
The only constant is change The only constant is change The Road to Cloud Native VNFs

The Road to Cloud Native VNFs

Embed Size (px)

Citation preview

Page 1: The Road to  Cloud Native VNFs

The only constant is changeThe only constant is change

The Road to Cloud Native VNFs

Page 2: The Road to  Cloud Native VNFs

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

Page 3: The Road to  Cloud Native VNFs

The only constant is change

About Cloudify

Member of Network Functions

Virtualisation ISG (NFV)

Standards Organizations Open Source Projects

Page 4: The Road to  Cloud Native VNFs

The only constant is change

Traditional Network Function

Page 5: The Road to  Cloud Native VNFs

The only constant is change

From Physical Appliance to Virtual Appliance

Mostly involved performance optimization and packaging

Physical Appliance

Virtual Appliance

Page 6: The Road to  Cloud Native VNFs

The only constant is change

The Rise of Cloud Native NFV

Page 7: The Road to  Cloud Native VNFs

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

Page 8: The Road to  Cloud Native VNFs

The only constant is change

Cloud Native VNFs (Versa)

Self-Managed

Page 9: The Road to  Cloud Native VNFs

The only constant is change

Cloud Native VNF Example (Ruckus)

SaaS Managed

Page 10: The Road to  Cloud Native VNFs

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

Page 11: The Road to  Cloud Native VNFs

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

Page 12: The Road to  Cloud Native VNFs

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

Page 13: The Road to  Cloud Native VNFs

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

Page 14: The Road to  Cloud Native VNFs

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)

Page 15: The Road to  Cloud Native VNFs

The only constant is change

Characteristics of Embeddable Orchestration

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

Page 16: The Road to  Cloud Native VNFs

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

Page 17: The Road to  Cloud Native VNFs

The only constant is change

Standardization EffortState of the Union Open-O/ OSM Common Modeling Effort

Page 18: The Road to  Cloud Native VNFs

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

Page 19: The Road to  Cloud Native VNFs

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?

Page 20: The Road to  Cloud Native VNFs

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

Page 21: The Road to  Cloud Native VNFs

The only constant is changeThe only constant is change

Thanks!Questions?

Find out more on getcloudify.org