Orchestration everywhere – now what do we do

The B/OSS industry in general seems to have got a handle on network functions virtualisation (NFV) and the virtual network functions (VNFs), in part thanks to the work that some of have done in collaboration with TM Forum.

The B/OSS industry in general seems to have got a handle on network functions virtualisation (NFV) and the virtual network functions (VNFs), in part thanks to the work that some of have done in collaboration with TM Forum.Thoughts are turning to the actual building of services. The biggest focus is on orchestration, because this remains a seemingly incomprehensible task of managing and controlling all of these moving parts.

There’s orchestration for VNFs, orchestration for physical network elements, orchestration for servers and data centre platforms, orchestration for policies, orchestration for billing - and we haven’t even got to service orchestration yet!

Instead of embedding fixed management and control functionality in individual network and service components, service providers have been insisting that those functions be abstracted into more flexible and agile software elements. But abstraction of vertically integrated functionality to a horizontal approach requires orchestration. We no longer need a network stack in every country or region, but we do need orchestration.

In addition to orchestrating physical and virtual network components, many service providers have begun to orchestrate critical business processes. There is a push to implement a centralized catalogue stack that orchestrates service delivery from the customer to the network by aligning product, service, and resource data into a single source of truth for order management, CRM, and billing. In a data-driven environment, processes can be streamlined and automated because of orchestration. Yet as the number of orchestration points grows, we feel like we’re losing control.

Think globally, act locally

The single biggest challenge for service providers has always been scale.: the number of customers, the number of services, and now the number of unique customer configurations.

Defining, delivering, and managing digital services cannot be done with a global control approach. Volume dictates that operations management moves closer to the customer.

Rather than chopping up the network status to determine customer impact, perhaps we are better served to capture customer status locally and aggregate that to determine the overall network status. Local status and performance is what customers are experiencing, and as that is aggregated engineers can better understand where any problems are coming from and where adjustments need to be made.

The number of events is so great that the sequential collection of customer status from everywhere and reporting a value for a single point in time - even if that occurs every 15 milliseconds or 15 minutes - is insufficient to determine what is happening and how customers are being affected. The status of the network is green, but the phone is ringing off the hook with customer complaints.

The volume is so great that unless events are processed in a distributed manner for each individual, service providers have a hard time determining where a problem occurred and whether it was a one-time or catastrophic event. And they certainly can’t respond in real time.

The question of what to do is a strategic one. We can continue to let this expand organically from the network and try to keep our arms around it – or we can acknowledge that this is a distribution problem and architect an approach that starts with customer orchestration.

The capability and technologies exist to instantiate each customer in its own cocoon of devices, applications, services, and infrastructure. Those customer silos are then managed individually within a multi-tenant environment and status, fault, performance, and billing information is then aggregated to local, regional, country, and global levels.

There will be much more discussion of orchestration and options for managing the growing number of orchestration environments at scale. Indeed, this is set to be a central theme at TM Forum Live in early May. Data-driven system and process architectures are a necessary first step to abstract and manage data that is currently embedded in existing systems, but data-driven is not orchestration. Managing distributed orchestration will be difficult, but it can be done.