The term “orchestration” is used frequently in discussions about Network Functions Virtualization (NFV).  What does orchestration mean for the cloud data center?  What additional requirements are imposed by NFV?

Orchestration 101

Let’s start with a basic definition of orchestration.  I looked at the Flexiant, IBM and SearchCloud sites.  There is some variation, but the common themes are:

•    Automation

•    Provisioning

•    Coordination and Management of Physical and Virtual resources

•    Within the datacenter

What additional requirements do we get when we add NFV to the mix?

Not Just the Cloud Data Center

The first difference is span of control.  Traditional orchestration solutions are focused on resources within the data center.  Carrier NFV will be used to build carrier services across the network, and orchestration must support those additional network elements and requirements.

Orchestration in the data center is simplified by the homogeneous nature of the physical and virtual element.  Adding the hodgepodge of metro equipment to the mix makes the problem harder.  I saw a great tweet on this point the other day from Gabriel Brown (@Gabeuk) that said “NFV is pretty much akin to rebuilding your house while you’re living in it.”  I believe that the network is going to evolve, so we can’t scrap the old stuff and start over. We have to solve this problem.

Resources Have Variable Cost and Variable Value

In a data center, the resources are all equivalent.  The available interconnect bandwidth is high, and the corresponding latency is low.  There is usually a large pool of each type of resource, so the cost of any given resource is low and uniform.  These facts simplify the selection and assignment of resources.

With NFV we may be adding resources in a central office, point of presence or even at the customer site.  The resources in these sites will necessarily be limited, so their cost is high relative to those in the data center.  However, their proximity to the customer means that their value may be relatively high for some applications.  Why?  Two reasons:

• The proximity means that the latency is lower, which may be important for some applications or services.

• Likewise the required bandwidth may be lower because of the removal of the need to take traffic back and forth.

Orchestration for NFV must take into account the variable costs and values of resources and optimize the use of these elements versus the requirements for the given service.

Lifecycle and Work Flow

There is some tie-in of data center orchestration into other systems, but these are often standalone scripts.  In contrast, orchestration for NFV must tie into higher-level systems.  As shown in the figure at the right, the orchestration may need to tie into the service provider’s OSS systems for operation, policies and/or billing.  The orchestrator may instead need to tie into an intermediate level of network applications or higher-level service orchestration.  In either case, the need for open APIs is clear.

Service Elasticity

One of the great benefits of cloud applications is that they are horizontally scalable or “elastic”.  Services built using NFV must also be elastic, and this means the components must be built accordingly.  They can’t be simple re-compilations of the software to run on a server instead of an appliance.

An appliance has a fixed size and capacity, and its software is designed and optimized for that capacity. In moving from an appliance to a virtual environment, the software needs to be decomposed, analyzed and recomposed to achieve elasticity.

Another reason for the success of cloud services is the on-demand, pay as you go model.  Operators want this same benefit from services built using NFV.  When moving from an appliance to a virtualized implementation the supplier also needs to revisit their licensing model in order for the overall service to meet its goals.

For more on these aspects of NFV, please see the blogs here and here by Overture’s Ramesh Nagarajan.

Orchestrator Multi-Tenancy

First, it is important to distinguish between multi-tenancy and virtualization.  From Wikipedia: Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client-organizations (tenants).

Compare this with virtualization where components are abstracted enabling each customer application to appear to run on a separate physical machine.

While the isolation and encapsulation of virtualization is important for NFV, it may be a drawback for orchestration.  For orchestration, multi-tenancy simplifies system design and integration into higher level systems, while providing and enforcing the needed separation between the various users (tenants) of the orchestrated services.

Comparison of Cloud Data Center and Carrier Class Orchestration

The table below shows a summary of the contrasts discussed in this blog.