Overture Tells a Complete NFV Story

I’ve been critical of the state of NFV in most of my posts, not because I’m opposed to it (I’m a big supporter) but because it’s deserved it.  There is an avalanche of NFV hype and nonsense out there, so much so that it’s rare to be able to say anything that’s not a criticism.  Which is why I’m happy today; I finally have something I can write favorable things about.

Overture Networks isn’t the furthest thing from an expected source of NFV insight that you could find, but it’s certainly not central in the hearts and minds of the NFV aficionados.  They’re a small-ish Carrier Ethernet vendor who recently announced a CPE element that can host virtual functions.  There are probably a half-dozen of these, all of whom assert NFV credentials, but unlike the rest Overture has real substance.  In fact, they may have more substance than NFV giants.

NFV has a lot of moving parts, but the functional heart of NFV is what the ETSI process calls “MANO”, or Management/Orchestration.  It’s MANO’s responsibility to deploy a service based on some form of instructions—call it a “model” or a “descriptor” or whatever.  When a service is ordered or when events dictate runtime changes to configuration of service components, it’s up to MANO to step in and orchestrate resources.  MANO is the most insightful contribution the NFV ISG has made, and MANO concepts are central to every one of NFV’s possible benefits.  Without MANO, NFV-wise, you have notrhing.

The great majority of NFV stories around MANO boil down to having OpenStack support.  OpenStack isn’t even part of MANO in my view, it’s part of the Virtual Infrastructure Manager that rightfully belongs in NFV Infrastructure (NFVI).  You need something above MANO to organize the end-to-end service setup, not just something to stick VNFs somewhere.  It will be a very long time before we have services that have no legacy elements in them (if ever) so you need some flexibility here.  Overture announced that last year with its Ensemble Service Orchestrator.  ESO is based on policies expressed Drools and workflows in BPMN 2.0 (Business Process Model and Notation, an OMG specification).  BPMN policies could be used to define services and service processes in detail, and at a higher level than OpenStack.  Overture, in fact, places OpenStack correctly as a VIM element in their presentation.

ESO gave Overture the distinction of being one of only three industry players that have met my tests for an NFV architecture that can effectively model services at both the functional and structural level.  They also announced a generalized network controller with ESO, so they could deploy on at least some legacy infrastructure.  However, they didn’t have a management story and so they’ve been a sort-of “Ohhhhh” provider rather than a “MAN…Oh” provider up to now.

“Up to now”, because they’ve now released a new capability that blends service definition and deployment with management.  It works in two parts, one of which is a set of advanced analytics applications and the other (the Ensemble Service Intelligence piece) that provides the framework that relates analytics results with resources and services and presents interfaces to management tools and other applications.

From Day One of NFV I’ve been an advocate of creating a repository intermediary between resources and “native” sources of management data and the management and operations tools and applications.  That’s at the heart of Overture’s approach.  ESI is a big-data repository populated by the totality of the resource MIBs (for devices, servers, platforms, and even VNFs) and also by service-to-resource relationships created during deployment.  They extend the basic repository notion with a series of management applications that derive additional intelligence through analytics.  Analytics also provides the service-to-repository correlation necessary to make service management explicit and not just implicit.

In their presentation, Overture includes a service lifecycle process description that builds a service (through a nice drag-and-drop GUI) and then takes it through deployment and management, including autoscaling under load.  This is managed by one of those ESI applications, and the approach demonstrates the value of the repository/analytics approach to management integration.  It appears to me that ESI applications and management data could be used in conjunction with BPMN-described state-event workflows implementing state/event tables in Titan models.  That could allow Overture to integrate management and operations processes into the lifecycle, which would create event-driven management and operations, pretty much the holy grail of OSS/BSS/NMS.

Overture also has a VNF ecosystem, and a trio of service-edge solutions ranging from an Overture-augmented server and a kind of “Dmarc-plus” Overture device to pure software.  Not surprisingly given Overture’s Carrier Ethernet positioning, they integrate these elements into NFV quite well, making the edge and the cloud both elements of NFVI and allowing VNFs to migrate from one place to the other as needed.  They have a decent number of VNFs available, more on the way.

There have been only three vendors who have shown me critical mass in an NFV platform—HP, IBM, and Overture (I think Alcatel-Lucent likely has a good solution but they’ve not provided collateral on the details so I can’t assess it fully).  Overture’s approach doesn’t have the legacy-network integration and OSS/BSS connection maturity offered by HP or the cloud affinity of IBM’s TOSCA-based approach.  But HP and IBM don’t have the same level of resource-to-service management coupling detail as Overture can provide.  What HP and IBM do have is mass, and buyer credibility, though.

Overture’s ESO/ESI adds up to an utterly fascinating NFV implementation, one so complete that you’d think it came from a network giant.  The fact that it doesn’t may be its only real limitation.  Overture has never seemed to push its “NFV strategy” as a general NFV strategy, preferring to see it as an extension of Carrier Ethernet.  They tell a great story to somebody who wants the whole story (their slide deck is fifty slides, the most information anyone has shared with me on NFV), but their positioning still seems to stop short of shouting MANO supremacy from the rooftops.  That I think would be out of their comfort zone.

That raises an interesting point because ordinarily a Carrier Ethernet packaging for VNFs and NFV tools would risk creating a silo, which everyone (including me) opposes.  In this case, you’d have to wonder whether instead of creating a silo, Overture is creating an on-ramp.  An operator with a strong Carrier Ethernet position and early opportunities to augment basic services with VNF-based security and other functional add-ons might conceivably start out with Overture’s ESO/ESI combination and their virtual endpoints and find out they could grow out of that position to broader services in which they’d never have seen Overture as a player.

Of course, an operator who doesn’t want to focus early field trials and deployment on Carrier Ethernet customers might find Overture a lot less appealing, and Overture might not be enthralled by the opportunities these non-Ethernet plays present either.  NFV is a consultative sell at best, and something has to pay for all that effort.  If at the end of the day the operator involved has little use for Overture hardware, will the pot be sweet enough for Overture to hang in?  So if ESO/ESI is an on-ramp, it’s not very well marked.

Somebody could always buy them, of course, and it’s also possible that somebody would step up to establish a partnership with Overture that flows value from small (Overture) to large rather than in the large-to-small direction represented by most of the VNF partnerships today.  Should we think of this as a MANO partnership?  The point is that there is really nothing out there quite like this.  I hate to paraphrase a line from a movie I didn’t even see, but these guys could be contenders.  With some work and positioning it could be a really great story in NFV overall, and in 2015 as I’ve said there are a lot of operators who need some of the stuff that ESO/ESI can provide.  At the least, this may inspire others to step up and tell an NFV story instead of erecting an NFV billboard pointing toward the nearest reporter.  Substance, by the second half of this year, is going to matter a lot, and substance we have here.