Embed Size (px)
Citation preview
2
2
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
The Road to Open NFV and ONAP
Network virtualization has gone through several transformation stages during the past few
years. It started with the internet age which provided open network connectivity around the
world. The next wave was during the virtualization stage when physical network devices
underwent a transformation to software appliances, enabling these former physical devices to
instantiate and control every network function through software and API calls.
ETSI NFV specifications provided an invaluable introspection in how NFV impacts Network
Functions and Services.
We are now entering the cloud native stage in which each network device becomes an internet
service that can be offered as a private or public SaaS. Open source has played a big role in
disrupting and reshaping the new cloud stack being primarily driven by the need to allow agile
software delivery through DevOps.
With the move to cloud, we’re seeing the expansion of the same open source disruption into the
Telco/Networking space which is greatly influenced by incumbent players like Cisco, Ericsson,
Juniper and others. A good example of the effect of the open source disruption has been
Blackberry vs. Android, where the use of open source has changed the entire mobile phone
market.
3
3
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
The Open Source Disruption
We are now seeing similar open source initiatives shaping the next generation network
orchestration world.
ONAP (Open Network Automation Platform) is a Linux Foundation project founded by AT&T
and China Mobile that brought together many of the key players in the industry to define the
next generation of network orchestration.
ONAP Founding Platinum Members
Cloudify Pioneering Open Standards through Open
Source NFV
Cloudify have been early adopters and implementers of TOSCA, betting on TOSCA as early as
July 2014, when the spec was still being formulated.
In late 2013, the bold decision was made to rewrite Cloudify from scratch in Python and based
on the TOSCA YAML DSL. This was a move to make Cloudify more natively integrated with other
open source projects, such as OpenStack.
4
4
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
In 2016, project ARIA was launched as an Apache project. The project works to provide a simple,
open-source TOSCA engine with an open governance model through the Apache Software
Foundation. The mission is to provide a simple and lightweight framework to run TOSCA.
Cloudify Journey to drive TOSCA and open standards through open source
Standard Modeling = Automation at Scale
Many view the use of standards as a way to avoid vendor lock-in.
Standards, in the context of automation, also define the degree and layer of automation which is
essentially what impacts the ultimate scale this automation enables. For example, if we have to
start by defining the low-level infrastructure whenever we design a new service, that will
determine where we spend most of our time. Agreeing on a standard model will allow us to
start with less granular building blocks and use the model as a way to describe a fully
operational service, without worrying about the bits needed to install and configure each
individual piece. Standard models exist at different networking layers and technology domains
(e.g. ETSI NFV VNF and NS information models), yet no end-to-end standard model exists, and
that hampers automation, and implicitly, service agility.
TOSCA is currently the most mature modeling language suitable to describe the degree of
automation required for cloud environments. It is simultaneously directionally correct and
under-specified. This makes it less constraining than other standards, and inherently more
future-proof. As a Domain Specific Language (DSL) for deployment and orchestration of cloud
workloads, it is not constrained to a particular frozen technology domain network, but can
support most - thus making it ideal for mitigating the absence of the end-to-end information
model. ETSI NFV has selected TOSCA as the primary DSL to realize its VNF and NS information
models. MEF is using TOSCA as a way to connect disjointed technology domains. Central Office
Re-architected as a Data Center (CORD) is using TOSCA to deploy its services. And TOSCA
5
5
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
adoption in Enterprise/IT confers the long-term opportunity to bridge gaps between the Telco
and IT worlds.
The use of an open governance TOSCA implementation through ARIA will allow us to
collaborate faster in defining and shaping the model through open source methodology.
The Boeing 787 is an example of how standard modeling drives scale
Cloudify Journey to Open NFV and ONAP
The Cloudify journey into Open NFV started even before the term NFV was coined. It started
through a partnership with Alcatel-Lucent’s CloudBand in which Cloudify was used as the core
orchestration engine. And since then we’ve been leading the open source and cloud native
agenda in NFV as noted here: Openness Is the True Path of NFV. At the same time, we are
contributing to ETSI NFV specifications, gradually aligning with the subset that we consider
future-proof that supports this open approach to NFV.
It took the telco industry quite a few years to begin adopting open source as the main strategy
to drive new standards. This led to the birth of new projects such as the Telefonica-led OSM
project, AT&T-led ECOMP, and China Mobile-led Open-O. Cloudify took an active role in Open-
O as a founding member as well as within the ECOMP integration.
In Feb 2017, Open-O and ECOMP merged into a new project—ONAP. It was only natural that
Cloudify would join ONAP as a platinum founding member and be integrated as a core
component into the ONAP stack.
6
6
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
Cloudify Journey to Open NFV and ONAP
Quick Introduction to ONAP
ONAP was designed to provide an open platform for network automation. It covers all the key
aspects that are expected from such platforms. It starts from a designer framework to offer a
full-blown runtime framework that covers the deployment and automation of network services.
The framework consists of a set of microservices that are combined together as outlined in the
diagram below.
ONAP Core Services
7
7
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
Quick Introduction to Cloudify
Cloudify is a model-driven orchestration platform based on TOSCA. It automates the
provisioning, deployment, configuration and remediation of application and network services.
It’s key strength is its ability to orchestrate heterogeneous stacks in highly distributed
environments. In the context of NFV that would include the ability to automate both virtual and
physical network services on bare-metal, OpenStack, and VMware as well as on public clouds
such as AWS and Azure.
Cloudify automates the deployment and management of network services on a hybrid stack and
hybrid cloud environment
Cloudify Collaboration on ONAP
Cloudify has been contributing code to some of the core services in ONAP with the purpose of
enabling a generic cloud automation and management layer, as which Cloudify today serves.
8
8
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
This can be used to run and orchestrate ONAP itself in a multi-cloud environment just at it does
with other apps or orchestrators, like Kubernetes, and alongside other IT applications and
services. In addition, Cloudify provides multi-cloud infrastructure orchestration allowing
ONAP to orchestrate network services in a multi-VIM environment.
Cloudify end to end management for ONAP
Cloudify is integrated within ONAP in the following services:
1. ONAP Operations Manager (OOM) — Cloudify is used to run ONAP and all its services.
In addition to running in a virtualized environment, ONAP can also run as a Kubernetes
service. In this case, Cloudify is used to run the Kubernetes infrastructure and orchestrate
the ONAP services on Kubernetes.
2. ONAP Service Orchestration (SO)—Cloudify is used as the TOSCA-native orchestrator
through ARIA. ARIA is responsible for taking an ONAP TOSCA CSAR package and
executing it through a native workflow engine. It is also responsible for setting the
infrastructure to run services (Similar to OpenStack Heat) on a multi-VIM environment.
3. Data Collection, Analytics and Events (DCAE) — Cloudify is used to run and manage the
DCAE services.
This integration allows operators to leverage Cloudify and ARIA capabilities not just to manage
ONAP as an external service, but also as a service that utilizes Cloudify services as part of ONAP
core services, as outlined in the diagram below.
9
9
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
Zoom into Cloudify integration within ONAP
Below is a more detailed description of the the Cloudify/ARIA integration with the individual
components.
ONAP Operations Manager (OOM)
ONAP Operations Manager is an ONAP tool used to efficiently deploy, manage, operate the
ONAP platform and its components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs and
containers).
With OOM, service providers will have a single dashboard to deploy and un-deploy the ONAP
platform, in part or in total. Operators can view different instances being managed and the state
of each component, monitor actions that have been taken as part of a control loop (e.g., scale
in-out and self-heal), and trigger other control actions like capacity augments across data
centers.
10
10
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
ONAP Operations Manager Architecture
Cloudify Support for OOM
ONAP uses containers and Kubernetes as the platform to run and manage ONAP clusters.
Cloudify support for Kubernetes leverages TOSCA-based multi-cloud infrastructure
orchestration as well as for service orchestration to automate the deployment and management
of ONAP on real-life heterogeneous environments that are comprised of existing network
services and other service elements that do not fit into a single Kubernetes platform.
The Cloudify integration with ONAP leverages the Cloudify Kubernetes blueprint to address the
following aspects in OOM:
Bootstrapping and Managing Kubernetes Clusters in Multi-Cloud Environments
● Multi-Cloud Provisioning - Cloudify sets the network and compute resources needed to
run Kubernetes on bare metal, OpenStack, VMware, AWS, Google Cloud and Azure out
of the box.
● Relationship and Dependency Management - Cloudify understands the Kubernetes
dependency graph and will deploy Kubernetes according to this dependency.
● Monitoring - Cloudify monitors the compute resources for Kubernetes and enables built-
in self-healing and scaling of Kubernetes instances.
11
11
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
● Self-Healing and Scaling - Cloudify provides built-in support to allow self-healing and
scaling of Kubernetes compute resources in case of failure.
Cloudify integration with ONAP Operation Manager (OOM)
Service Orchestration of Kubernetes Microservices across Hybrid Stacks
The Cloudify Kubernetes Plugin provides a means to model the relationship of existing
Kubernetes microservices and connect them with other services such as existing network
services or other services that run outside of ONAP.
Cloudify’s Kubernetes Roadmap includes a Cloudify Provider for Kubernetes that will take the
role of infrastructure provisioner. This enables users to create custom implementations for
underlying routing, storage, and compute services. For example, a pod can be defined with a
load balancer in OpenStack that does not rely on OpenStack floating IPs, but instead on a virtual
IP based on another vendor’s VNF.
The example below shows a TOSCA blueprint which sets the relationship between all the
relevant ONAP microservices.
Example:
12
12
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
Multi-Site Management for ONAP Cloudify can run multiple instances of Kubernetes/ONAP from the same manager.
This is useful when setting Testing, QA, and Production environments, but it’s also useful when
setting up a Kubernetes cluster for a multi-site deployment or even on edge devices.
Supporting Other Containers and Non-Container Based Platforms The container platform landscape is changing rapidly and includes other alternatives to
Kubernetes such as Docker Swarm, as well as non-container based platforms.
The Cloudify plugin approach provides an abstraction layer that decouples the actual service
from the platform on which it will be running. This provides the flexibility for operators to
choose the platform of choice for their service as well as mix and match between services that
run on Kubernetes and Docker Swarm within the same automation flow.
13
13
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
ONAP Service Orchestrator (SO)
ONAP SO provides the highest level of service orchestration in the ONAP architecture. Currently
SO is implemented via BPMN flows that operate on models distributed from SDC that describe
the services and associated VNFs and other resource components. Cloud orchestration is
currently based on Heat templates.
There are two paths for service definitions, coming from the ONAP Service Design and Creation
(SDC). In the first, the SDC provides a CSAR with a TOSCA template that orchestrates cloud
infrastructure resources. In this path, TOSCA serves the same role as Heat. The SDC pushes the
CSAR into the SO database (MariaDB). In the second path, the SDC provides a true modeled
service-level TOSCA template. The SDC pushes the CSAR directly into ARIA. There are two
equivalent paths for instantiation. The VID either commands the BPM engine to create the
previously deployed template, which then calls ARIA to create the infrastructure on the target
cloud, or it commands ARIA directly to execute the top-level service template.
Data Collection, Analytics and Events (DCAE)
The foundation of DCAE is Docker containers which deploy and manage individual network
components. DCAE uses Cloudify blueprints to deploy both supporting components (Config
Registry/Consul, Platform/Docker hosts, CDAP broker, and Platform Services), as well as specific
components to be managed by the Docker host (Dispatcher, Policy Handler, Service Changing
Handler, Inventory, etc). The division of labor is for Cloudify to manage overall orchestration,
while Docker controls application-level configuration and management for DCAE components.
Future releases will begin to make use of Kubernetes to manage the Docker components.
14
14
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
The DCAE Cloudify / TOSCA blueprint that is used to run DCAE
is provided below:
15
15
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
Final Note - What it Means to be Truly Open
“This is the network of the future: open-sourced, future-proofed, highly secure, and
flexible enough to scale up to meet any demand.”
Randall Stephenson, Chairman and CEO, AT&T
Building the Network of the Future: Getting Smarter, Faster, and More Flexible with a
Software Centric Approach, John Donovan and Krish Prabhu
Many players in the NFV space come with conflicting agendas to ONAP because they have a
strong dependency on non-open source business models to drive their main revenue, and
therefore open source is considered by those players more of a disruption than an opportunity
as noted in the post: Where AT&T Leads, Cisco Cannot Follow.
Many of these players also come with a specific bias toward their own hardware or network gear
which puts them in conflict with other network services from other brands, and therefore cannot
really lead to true open NFV, and consequently ONAP, strategy that is ultimately about releasing
the network services lock-in.
In the current open NFV landscape, ONAP is well-positioned to become the leading reference
model for NFV with its already 30M+ strong subscriber-base, being built on TOSCA, and having
the attention of the entire industry. For those that are looking for a more pragmatic approach
(e.g. in ONAP), the hope is that ONAP will rise to the occasion and produce an ONAP
community TOSCA++ originating in SimpleYAML, but enhanced with extensions that are
consistent with TOSCA philosophy, yet serve its approach to VNF and NS design and modeling.
TOSCA currently serves as the dominant DSL for the modeling of cloud applications deployment
and orchestration, and it is also embraced by the Telco world. “Blessed” by standards
communities such as ETSI NFV and MEF, it recently was anointed “lingua franca” by Open
Network Automation Platform (ONAP) – the largest Telco open source project around. Earlier
even than that, it was incorporated into OpenStack under project Tacker. The only Telco open
source project not (yet) embracing TOSCA, but rather staying loyal to YANG, is Open Source
MANO (OSM).
TOSCA, with Cloudify serving as the most advanced implementation to date, will enable the level
of flexibility and evolve-ability today’s (and tomorrow’s) networks require, including zero bias to
specific network service or particular infrastructure and chartering the way to zero-touch
16
16
©
2017 Cloudify Platform Ltd. - reproduction in whole or in part without written permission is prohibited.
operations - the holy grail of managing networks. This, coupled with a strong ecosystem of
leading industry players, of which some are even using Cloudify/TOSCA as their own VNFM -
such as Fortinet, Versa, Juniper, Ruckus, Metaswitch, F5 - will enable a healthy distribution of
telcos, operators, networking vendors and other network service providers move towards an
unbiased standardized service model for NFV transformation. (Read more: The Tenets of
Cloudify).
Enabling NFV as part of the broader cloud and application management challenge and not as
yet another silo, has enabled organizations to adopt a new approach to automating network
services as part of their overall cloud application management strategy through
Cloudify/TOSCA. This enables much stronger network security of applications as these each can
be tied to a private/secured network on the fly, ensuring that the network follows the
application, and not the other way around. This is particularly important as we start to expand
into more distributed deployment models such as edge computing or mobile edge.
Cloudify is excited to see the development and momentum around ONAP, with a long-standing
track record in driving open source, communities, and standards globally. With specific
experience in working with the Open-O and ECOMP communities, as well as tier-1 carriers and
vendors, this collaboration will make it possible to integrate mature and production-ready open
NFV capabilities into ONAP, through code collaboration, delivering the next-generation
networking automation and management of heterogeneous stacks.
